Pre-event critical systems readiness monitor
Problem
Whether the ground is actually ready to open its gates is assembled from memory on the morning of an event: a call to the electrician about the floodlights, a text to the access control contractor about the turnstiles, a walk past the generator to see if the fuel light is on. Nobody holds all of it in one place, so a fault picked up at eight in the morning by a facilities technician can sit in a personal messaging thread until someone happens to ask. The first time a venue operations director learns a turnstile bank is down is sometimes when a queue has already formed outside it.
Product idea
The product is a single board per venue listing the systems that would stop an event opening on time: floodlights, turnstile and access control, public address, emergency generator, pitch irrigation, catering power. Each system has a named owner who sets its status from a phone: ready, in progress, or faulted. The board carries a countdown to gates-open and a rules engine so each system's threshold is set independently, for instance an alert to the facilities manager if turnstiles are still faulted ninety minutes out. It does not dispatch a contractor or log a repair; that stays in the maintenance system. It only tells the right person, early enough, that something is not ready.
Who it is for
Facilities managers, venue operations directors and the named system owners, electricians, access control contractors, ground staff, who set status. Sponsored by the venue operations director who currently assembles readiness by phone call each event morning.
Possible first version
A configurable per-venue checklist of critical systems, each with a named owner and a status set from a phone. A countdown to a set gates-open or kick-off time. Threshold rules per system that trigger an SMS or email alert to a named person once a system stays faulted inside its window. A single board view for the venue operations director. Version one has no feed from the building management system or any contractor's system: status is entered by the named owner, not pulled automatically.
- Build classification
- Workflow application
- Rough effort
- 3-5 week first release
- Roles involved
- Facilities manager, Venue operations director, Maintenance supervisor
- Relevant to
- Venue & stadium operator, Professional club, Federation / governing body
- Systems in play
- Building management systems, Messaging apps, Maintenance and work-order systems
- Product framing
- Monitor
Questions we get asked
What do we need to have in place before this is useful?
The board is only as good as the list of systems and owners behind it. Before the first event, someone has to agree the critical systems list per venue, name an owner for each, and set the threshold each alert should fire at. That is a half-day workshop, not a data migration. Without it, the board sits empty and nobody sets a status.
Does this replace our building management system?
No. Where a venue has a building management system reporting genuine plant faults, that system still holds the sensor-level detail and the fault history. This board is a roll-up: a single screen showing whether the systems that matter for opening are ready, built from the status a named person sets rather than raw telemetry. Feeding it from the building management system automatically is a later step, not part of version one.
Our system owners already get a phone call when something is wrong. Why would they update a status field too?
Because the phone call only reaches the venue operations director if the right person happens to make it, and it leaves no record for the next event. Setting a status takes seconds and the alternative, being the person whose fault sat unreported past its threshold, is a stronger incentive than most staff apps manage. If owners will not maintain it, the board is worth stopping rather than persisting with a display nobody trusts.
What happens if a fault appears after gates have opened?
The board is built around the run-up to an event, not live incident management during one. Once gates are open, a fault becomes an operational incident that needs a different response than a threshold alert to a named person: phone calls, radios, the existing matchday control room process. The board's job ends when the countdown reaches zero; it is not a substitute for how the ground already handles something breaking mid-event.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Venue, facility & ground operations
- Facility booking conflict and capacity monitorA monitor that checks the shared booking calendar for overlapping bookings and capacity mismatches, and alerts a named coordinator before the clash reaches the day itself.
- Life-safety equipment inspection and evidence logA mobile tool that ties fire extinguishers, emergency lighting and fire doors to scheduled checks, so a safety certificate audit can be answered from records instead of a paper folder.
- Maintenance request intake and auto-routing queueA structured intake form that turns phone calls, texts and corridor mentions about broken things into an assigned, escalating queue, so nothing depends on someone remembering to mention it twice.