Stadium Operations Software Problems: The 7 That Undo Your Incident Record, and How to Avoid Them

Why does the control room log keep getting scoped as a dashboard?

Almost every venue operations project starts with the wrong brief. The requirement gets written as a live picture of the event: zone status tiles, crowd counts, a map, a feed of what is happening. That is a genuinely useful screen and it is not what the system is for. The system is a liability records engine that happens to have a dashboard on top.

The reason this matters is timing. A dashboard is built for the person watching now, so the design optimises for display. An evidence record is built for a solicitor reading in two years, so the design optimises for capture at the moment of the radio call, with the narrative, the photographs and the outcome attached afterwards to a record whose creation time is already fixed. Those two priorities produce different software. Venues that scope the dashboard get a control room with better situational awareness and the same evidential gap they had before.

The fix is a design rule that survives the whole project: nothing is a record until it has a device side timestamp, and everything else is enrichment. Two taps during the incident to capture zone, type and time. Everything else later. If a supervisor has to complete a form to create an entry, the entries that matter will be the ones from the quiet minutes, because during the busy fifteen minutes around ingress nobody is filling in forms.

What goes wrong with zone maps, certificate conditions and staffing data?

The configuration data in a venue build is harder than the software, and it is the part most projects underestimate. Your zone map exists, usually as a drawing produced for the safety certificate, and it does not match the way the control room talks. Stewards refer to areas by names that predate the last stand redevelopment. Two zones share a turnstile bank. The away allocation moves between blocks depending on the competition.

The certificate conditions are worse, because they are prose. A condition sets a minimum number of qualified stewards on a zone, or makes a section's capacity dependent on a fire exit being staffed, or attaches a requirement to a specific competition. Turning those into rules a system can check is a joint exercise between your safety officer and the developer, and it always surfaces conditions nobody had operationalised because they had simply been complied with by habit.

Then there is the staffing data. Multiple agencies supply stewards, each with its own list, its own qualification records and its own idea of who was sent. Reconciling those into one roster with valid qualifications is a real piece of work and it is where the project's financial return usually sits, because agencies get invoiced against actual attendance rather than against their own claim. Budget for this properly. A build that treats zone maps, certificate conditions and agency rosters as configuration to be filled in later will go live with a half configured venue and lose the room in the first fixture.

Why do access control, ticketing and radio integrations break after launch?

Three integrations matter in a venue and all three fail differently. Access control and turnstile counting is hardware, installed by a contractor who may still hold the maintenance agreement and has no particular reason to help you extract counts. Interfaces vary by installation rather than by product, and a system that works at one stand can behave differently at another because the panels were fitted in different years.

Ticketing is the integration that makes ejections and bans stick, and it is usually the one that gets deferred. Without it, an ejection is a description in a log rather than a flag on an account, which is why the same individual walks back into the ground three fixtures later. Ticketing platforms also change under you, since a migration to a new provider is a commercial decision made without reference to your incident system.

Radio does not integrate at all in most venues, which is fine, but the consequence has to be designed for rather than ignored. If the primary capture path is a supervisor's phone, then a concrete bowl on a full house is a hostile network environment and the mobile client must write locally with a device side timestamp and reconcile later. Any developer who treats that as an edge case has not worked a full stadium. The fix across all three is the same discipline: name the vendor and the interface in the contract, test at the actual installation rather than in a lab, and monitor each feed with an alert when it stops.

What happens when medical confidentiality and banning are not covered?

This is the gap that turns a logging project into a data protection problem. A medical call and an ejection are both incidents in the control room's eyes and they are two completely different legal records. A medical record carries clinical detail and a confidentiality boundary that does not include the steward supervisor. An ejection record needs identity where identity was captured, the reason, the block and seat, the stewards involved, whether police were engaged and how the person left the building, because that is what a ban has to stand on.

Most venue logs treat both as an incident with a category field and a free text description. The result is one of two failures, and usually both. Clinical information becomes readable by everyone with a supervisor login, which is a breach waiting to be reported. And the ejection record is too thin to support a banning decision, so the ban either does not happen or happens without evidence that would survive challenge.

The fix is separate record types with separate fields, separate retention periods and separate access rules, both hanging off one incident timeline so the control room still sees a single picture of the night. The medical lead and the safety officer see the clinical record. The supervisor sees that a medical call occurred and its response time. On the ejection side, the record has to carry through to a banning workflow with the evidence attached and to the ticketing system so the account behind that seat is flagged. That last link is the one most venues never close.

Should you build custom or configure what you already own?

A lot of venues should not build this. If you run occasional events with one safety supervisor and a paper log book, a shared incident form and a disciplined radio protocol will serve you better than software, and the effort of a custom project will exceed anything you get back. Software does not create control room discipline, it records it.

If your operation is reasonably conventional, look hard at 24/7 Software before commissioning anything. It is a real incident management product with real venue deployments and configuring it will be quicker and cheaper than a build. If your genuine pain is the event calendar, room bookings and how the building is scheduled rather than crowd safety on the night, Momentus Technologies is aimed at that problem and aimed well, and buying the wrong category of product is a more common mistake than buying the wrong product.

Build when you operate under a safety certificate with real named conditions, when you deploy several hundred contracted stewards across multiple agencies, when you run more than one venue and want a single operating standard across them, or, most decisively, when you have already been through an incident review and found that your records could not answer the questions asked. The last one settles it. The value is not control room efficiency, it is being able to produce a timeline nobody can pick apart.

How do hidden costs get into the quote?

The first hidden cost is per venue configuration. A second stadium is a different zone map, a different certificate, different agencies and often a different local authority with its own reporting expectations. That is configuration and training rather than a rebuild, but it is not free, and quotes that price a multi venue rollout as one deployment are wrong by a factor.

The second is access control integration. Every installation is its own conversation with the installer, so a line item that says access control integration without naming the vendor and the specific stand is an estimate rather than a price. Ask for it per installation.

The third is offline capability, which is sometimes quietly excluded because it is genuinely harder to build and test. Local write, device side timestamps, conflict handling on reconnect and a test plan that involves an actual full house are real engineering. If the quote is suspiciously light, this is usually what is missing. The fourth is parallel running. Expect two or three fixtures where the paper log continues alongside the system, because that is what surfaces the escalation rules and zone quirks nobody wrote down, and somebody has to be paid to be in the control room for those.

What separates a build that works from one that fails here?

Ask a prospective developer what happens when a steward reports something on radio and the concourse network is saturated. If the answer does not include local capture with a device side timestamp and later reconciliation, your evidence will have gaps exactly where the crowd was densest, which is precisely where a claim will focus.

Ask how they separate clinical records from general incidents. If both are the same record type with a category field, they have created a data protection problem while solving a logging one. Ask what they have integrated on the access control side, by vendor name and by installation. Ask how an ejection reaches the ticketing platform, because that is the difference between a ban and a note.

Then judge the project after launch on two things rather than on features. First, whether the post event report generates from the record instead of being reassembled by hand the following morning, because that is the test of whether capture actually happened during the event. Second, whether you can now see a season rather than twenty five separate nights: which turnstile banks consistently run late, which blocks generate ejections against which fixtures, how often the reserve gate procedure has been used without review. Venues almost never see that, and it is the operational return that sits on top of the evidential one. Settle code, hosting and data ownership in writing before kickoff. Incident records are disclosable evidence and belong somewhere you control for the whole of your retention period. At Digital Heroes the client owns the repository and the data from the first commit.