Where Should the Alert Go? Routing Decides Response Time

Most video analytics projects are specified around detection accuracy and delivered with almost no thought about delivery. Yet the measure that matters operationally is time-to-eyes: how long between something happening and a person who can act having looked at it. Routing decides that, and routing is a choice about channels, people and hours rather than about models.

The channels, honestly compared

For most Omani sites WhatsApp is the honest answer for anything urgent, for one unglamorous reason: it is already on every phone and it is already read. A channel people check because of their own habits beats a purpose-built app that requires a behaviour change, and security tooling that depends on a behaviour change tends to lose.

The snapshot is the whole message

An alert saying "motion detected in Zone 3" forces the recipient to open a system, log in, find the camera and scrub back — which at 03:00 means they will not. The same alert with a still image attached is usually resolved in the notification itself: it is a cat, or it is a person, and the guard is moving before they have opened anything.

This single design choice does more for response time than any improvement in detection. It also changes the economics of false alarms, because a false alarm that is dismissed in two seconds from a preview costs almost nothing, while one that requires a five-minute investigation is what teaches people to ignore alerts.

Acknowledgement and escalation

Sending an alert is not the same as knowing it was received. Without an acknowledgement step there is no difference between a guard who checked and cleared an alert and a guard who was asleep, and the difference matters both for the incident and for the review afterwards.

Escalation follows from that: if nobody acknowledges within a defined interval, the alert goes to a second recipient, then a third. This is what turns a notification into a process, and it is the part most deployments never configure — usually because the first question it forces is uncomfortable, namely who is actually accountable at 03:00 on a Friday.

Broadcasting to a group of ten does not solve it. A group alert with no named owner produces diffusion of responsibility: everybody sees it, everybody assumes somebody nearer is dealing with it. One named recipient with a timed fallback outperforms a busy group every time.

The routing table has to follow the roster

Recipients configured once, at installation, describe a shift pattern that has since changed. People leave, phones change, contractors rotate, and nobody updates the alert list because it is invisible until it fails. A year in, a meaningful share of alerts are going to numbers that no longer belong to anyone at the site.

Two practices prevent this. Route to a role rather than a person — "night supervisor" resolved from a roster, not a hardcoded number — so a staff change updates one place. And send a scheduled test alert weekly to whoever is on duty, requiring acknowledgement, because a routing failure you discover during a test is an administrative task and one you discover during an incident is a different conversation entirely.