Stadium and Arena Event Day Software: Why the Incident Log You Keep Decides the Liability Case Two Years Later

Why event day operations software is really a liability records system

Twenty two minutes before kick off, a steward on radio reports a crush developing at a turnstile bank because two coaches arrived together and the away allocation queue has folded back on itself. The control room logs it. Somebody upstairs decides to open a reserve gate. Nine minutes later a supporter is taken to the medical room with a suspected broken wrist. An ejection happens at the same time in a different block, and both go over the same radio channel to the same two people writing on the same incident sheet.

Two years later, a solicitor's letter arrives. The question is not whether your staff acted reasonably. The question is what you can prove about the gate opening time, who authorised it, what the steward reported before it, how many stewards were on that zone against the safety certificate requirement, and whether the medical call was logged as a timestamp or written up after the match from memory. The answers usually live in a spreadsheet, a radio log nobody transcribed, a WhatsApp group, and the memory of a safety officer who has since left.

That is what venue operations software actually is. It is not a dashboard for the control room. It is the evidence record for a regulated operation where the difference between a defensible position and an expensive one is whether the timestamps were captured at the moment or reconstructed afterwards.

Problem 1: the log is written after the fact, and afterwards is worthless

Control rooms run on radio. Radio is fast, which is why it works, and unrecorded, which is why it fails. The standard pattern is a supervisor writing entries into a shared document while simultaneously talking to two zone managers, so the entries that get written are the ones that happened during a quiet minute. The entries that matter, the cluster of events during the busy fifteen minutes around ingress, are the ones written up later.

24/7 Software does incident management competently and is a real product with real venue deployments. Where it strains is in the shape of your specific operation: your zone map, your escalation ladder, your safety certificate conditions, the agencies you use and how their staff are counted, the local authority's expectations for what a report looks like. Momentus Technologies sits more on the booking and event scheduling side of the building than the control room floor. Both leave you configuring your operation into somebody else's model of a venue.

What a custom build does: the log entry is created at the point of the radio call by the person taking the call, in two taps, with the zone, the type and the timestamp captured automatically. Everything else, the narrative, the outcome, the linked photos from the camera operator, gets attached afterwards to a record whose creation time is already fixed. That single change, capturing the timestamp at the moment and enriching later, is the difference between an evidence record and a summary. It is also the change that stewards will actually adopt, because it costs them nothing during the incident.

Problem 2: your staffing on the night has to reconcile to your safety certificate

Your certificate sets conditions. Certain zones require a minimum number of qualified stewards, certain roles require specific training or licensing, and capacity in a section may be conditional on a fire exit being staffed. On the night, three agencies send bodies, some do not turn up, and a zone manager moves people around to cover the gaps. By kick off the actual deployment does not match the plan, and nobody produces a document proving what it did match.

What a custom build does: the deployment plan is a structured object, the sign in at the briefing point updates it in real time, and the control room sees a live view of which zones are below their required count and which staff hold expired qualifications. When a zone manager moves four stewards from the west concourse to the away turnstiles, that redeployment is a recorded decision with a time and an author, and the reconciliation between required and actual is produced automatically at the end of the night. Agencies get invoiced against actual attendance rather than against what they claim they sent, which in our experience is the finding that pays for the project within a season.

Problem 3: ejections and medical calls are two different legal records

An ejection has to hold identity where identity was captured, the reason, the block and seat, the stewards involved, whether police were engaged, whether a banning process follows, and how the person left the building. A medical call has to hold a clinical record with a completely different confidentiality boundary. Most venue logs treat both as an incident with a free text description, which means either your medical records sit somewhere too many people can read them, or your ejection records are too thin to support a ban.

What a custom build does: separate record types with separate fields, separate retention rules and separate access control, both hanging off the same incident timeline so the control room still sees one picture of the night. The medical record is visible to the medical lead and the safety officer, not to the steward supervisor. The ejection record carries through to the banning workflow with the evidence attached, and to the ticketing system so the account behind that seat is flagged for the next fixture. That link between an ejection and a ticket account is the one most venues never close, and it is why the same person is back in the ground three weeks later.

Problem 4: the post event report is rebuilt by hand every single time

The safety advisory group wants a report. So does the insurer, occasionally the police, and internally the head of operations who wants to know why concourse queue times spiked in the second half. Today somebody spends a day after every event copying incident rows into a document, counting ejections, and writing a narrative from the radio log they half remember.

What a custom build does: the report generates from the record, because the record was captured properly during the event. Ejection counts by block, medical calls by type and response time, gate open and close times, capacity against certificate, staffing variance, and the full chronological log. Then the interesting part, which is the same report across a season: which turnstile banks consistently run late, which blocks generate ejections against which fixtures, whether the reserve gate procedure has been used four times this season without ever being reviewed. Venues rarely see this because nobody assembles a season out of twenty five reconstructed reports.

What this costs and how long it takes

A first event day release, meaning the control room log, mobile incident capture for supervisors, zone and escalation configuration, ejection and medical record types with proper access control, and post event reporting, runs $80,000 to $190,000 and ships in 14 to 20 weeks. A full venue operations platform adding live staffing deployment and sign in, agency reconciliation, integration with access control and ticketing, camera system references, banning workflow and season analytics runs $250,000 to $550,000 phased over 9 to 15 months.

What pushes cost up in venues specifically: integration with access control and turnstile counting hardware, because every installation is its own conversation with an installer who may or may not want to help. Integration with the ticketing platform, which is what makes ejections and bans stick. Multi venue rollouts, because a second stadium is a different zone map, a different certificate, different agencies and often a different local authority. And connectivity, since a concourse in a concrete bowl on a full house is a genuinely hostile network environment, which means the mobile capture has to work offline and reconcile afterwards. Do not let anyone skip that requirement.

Build versus buy, and when buying is the right call

Buy if you are a small or medium venue running occasional events with one safety supervisor. 24/7 Software or a well configured incident module inside an existing facilities tool will do the job, and the effort of a custom build will exceed the value you get from it. If your event calendar and room bookings are the actual pain rather than crowd safety, Momentus Technologies is aimed at that problem and aimed well.

Build when you operate under a safety certificate with real conditions, when you deploy several hundred contracted stewards across multiple agencies, when you run more than one venue and want one operating standard across them, or when you have been through an incident review and discovered that your records could not answer the questions asked. Our position is that the third and fourth of those are the ones that decide it. The value is not efficiency in the control room. It is that two years later you can produce a timeline nobody can pick apart.

How to choose a developer for venue operations software

Ask them to describe what happens when a steward reports something on radio and the network in that concourse is saturated. If the answer does not include offline capture with a device side timestamp and later reconciliation, they have not built for a full stadium and your evidence will have gaps exactly where the crowd was densest.

Ask how they separate medical records from general incidents. If both are the same record type with a category field, your clinical data is readable by every supervisor and you have created a data protection problem to solve a logging problem.

Ask what they have integrated on the access control side. Turnstile counts, gate states and ticket scans come from specific systems from specific installers, and someone who has done it will name the vendor and the interface rather than saying they do integrations.

Ask who owns the code, the hosting accounts and the incident data, and settle it in writing before kickoff. Your incident history is disclosable evidence and it needs to be somewhere you control for as long as your retention policy says. At Digital Heroes the client owns the repository and the data from the first commit.