// INSIGHTS
Incident Detection and Escalation That Actually Reaches Someone
6 min read
Most incident systems fail after detection, not before it. The camera saw the fall. The panic button fired. The alert went to a WhatsApp group with 47 members, at 9:40 pm, during a headline set, and nobody owned it. Eleven minutes later a steward found the person on foot. The detection worked perfectly. The system still failed. Escalation is the engineering problem, and it is mostly about ownership, timers and redundant channels rather than models.
Fusion first, then a ladder
A single signal is a weak basis for waking someone up at 2 am. Video analytics flag a person on the ground, but so does a person sitting down against a wall. A crowd density threshold trips, but so does a queue for a popular stall. A panic button is pressed, but pockets press buttons too. Fusing signals raises confidence and cuts noise. A density threshold breach plus a flow reversal at the same portal within 60 seconds is a materially different event from either alone. A fall detection plus a nearby panic trigger is close to certain.
Once an incident is raised, it enters an escalation ladder. Tier one is the named on-duty owner for that zone, contacted on their primary channel. If no acknowledgement within a set interval, typically 45 to 60 seconds, tier two fires: the zone supervisor plus the control room lead, on two channels simultaneously. If that also lapses, tier three reaches the event safety officer and the medical lead, and the incident is announced on the primary radio channel by the control room operator.
Acknowledgement is the whole mechanism. An alert that cannot be acknowledged cannot be escalated, because the system has no way to know it was missed. Every notification carries a one-tap acknowledgement, and every acknowledgement records who, when and on which device. The metric that matters is mean time to acknowledge, not mean time to detect.
Targets we design against
Components of the escalation layer
Multi-signal correlation
Video analytics, density thresholds, door and gate sensors, and physical panic triggers feed one correlation engine. Confidence rises when independent signals agree in time and place.
Acknowledge-or-escalate logic
Every alert has a timer and a named owner. Silence is treated as failure and moves the incident up automatically. Nothing waits for a human to notice that nothing happened.
Channel redundancy
Push notification first, then SMS, then an automated voice call. Data networks saturate at large gatherings. GSM voice usually survives longer than mobile data.
Immutable incident timeline
Every trigger, notification, acknowledgement and note is timestamped in one record. This is what the post-event review and any regulatory enquiry actually needs.
Building it for a specific event
Define incident types and owners
Medical, crowd pressure, fire, unattended object, lost person, security breach. Each gets a named role owner per zone per shift. If a type has no owner, it does not get an alert.
Wire and place the triggers
Panic buttons at stewarding posts and medical points, analytics zones on the cameras that support them, and sensor inputs where they exist. Placement is decided on the ground, not on a drawing.
Rehearse with unannounced drills
We run at least two live drills before doors open, including one with the primary data network deliberately disabled. Drills find broken phone numbers and unstaffed roles. Nothing else does.
Measure and adjust
After each event day we report mean time to acknowledge per tier and per zone, plus the false positive rate per detector, and retune before the next day.
What usually goes wrong
The WhatsApp group is the single most common failure mode in Indian event operations. It feels like coverage because everyone can see the message. In practice diffusion of responsibility means a group of 47 has a lower response probability than a direct message to one named person. Group chats also have no acknowledgement state, no escalation, no audit trail, and they scroll. The second failure is alarm fatigue. A detector with a 20 percent false positive rate trains the recipient to ignore it, and the training is permanent. It is better to run three well-tuned detectors than twelve noisy ones. The third is network collapse: at 40,000-plus attendees, mobile data at the site is frequently unusable at exactly the moment an incident occurs, which is why we insist on a GSM voice or SMS path and on a control room with wired or radio connectivity independent of the public network.
Be honest about detection limits too. Audio-based gunshot and scream detection performs badly in live music environments and we do not recommend it there. Fall detection in dense crowds is heavily occluded and will miss events. Aggression and intent detection has weak validation and demonstrable demographic bias, and acting on it means dispatching security toward a person because a model guessed, with the errors concentrated in some groups more than others. Our position is that automated detection is a supplement to stewards and panic triggers, never a replacement, and that the human-initiated path must be the fastest path in the system. Under the DPDP Act, incident records that contain identifiable footage need a stated purpose, a retention limit and access control, and should not quietly become a general-purpose archive.
Common questions
What can you detect reliably, and what can you not?
Reliable: line crossing, unattended object in a static zone, camera tamper, density and flow thresholds, and any human-pressed panic trigger. Unreliable in event conditions: fall detection in dense crowds, audio event detection near live music, and anything claiming to infer intent or emotion. We will tell you which category each requested detector falls into.
What happens if the internet goes down mid-event?
The correlation engine runs on a local edge node at the venue, so detection and local alerting continue without any external connectivity. Delivery falls back to SMS and automated voice over GSM, and the control room retains its radio path. Cloud sync catches up when the link returns.
Do we need to buy new hardware for this?
Often less than expected. Existing cameras, radios and any installed panic buttons can usually be integrated. The typical new spend is an edge node per venue and additional panic triggers at stewarding positions, which are inexpensive relative to the response improvement.
Fix the last mile, not just the detector
Share your incident types and staffing plan and we will map an escalation ladder with named owners and measurable acknowledgement targets.
