Multi-site alert triage

Multi-site alert triage

Multi-site security operations · Alert triage

Multi-site security operations · Alert triage

Summary

A concept redesign of the operator console for a multi-site physical
security platform, where a small team monitors dozens of locations
through AI-detected events.

The core problem isn't showing alerts — it's helping an operator decide which of forty locations deserves attention right now, and doing it without letting speed-ups quietly cause real-world consequences.

Built as a working HTML prototype so the density, grouping andedge cases could be tested rather than assumed.

Client:

Self-initiated case study

Service:

Multi-site security operations · Alert triage

Date:

2026

The Challenge

An operator watching 40+ sites gets a continuous stream of automated
events, most of which are routine. Two failure modes matter:

Missing the one that counts. A chronological list treats a forced door
and a delivery truck triggering motion as equals. Under load, everything becomes noise.

Acting too fast on the wrong thing. Every mechanism that speeds an operator up — grouping, bulk actions, defaults — is also a mechanism for making a mistake at scale. Escalation contacts real people at a real site.

The brief was to reduce triage load. The harder constraint was doing it without making errors cheaper to make.

The Solution

Location-first, not event-first The unit of attention is a place, not a signal. An operator asks "what's happening at Newark", not "what was the 47th event". Events roll up into the location that owns them.

Four severity tiers, split by required response Critical, Warning, Unknown/Offline, Normal. Offline is deliberately its own tier rather than a warning — an unreachable camera isn't a low severity event, it's an absence of information.

Shared-cause grouping — with a guaranteed way out Five sites dropping at once is one ISP outage, not five incidents.

Grouping them is correct. But every grouped location keeps its own "Escalate individually" action, because a shared cause doesn't guarantee a shared response.

Honest confidence labelling AI-inferred events show a confidence score and detection source (97% · door sensor + video). Deterministic events show "system event" instead of a fabricated percentage. Uniform confidence framing would be easier to design and less trustworthy to use.

The Impact

Design outcomes (concept validated on prototype, not in production)

  • Bulk actions cover the safe operations only. Assign, reassign, mute and dismiss are batchable; escalation is not — an action with real-world consequences shouldn't be one click away for five sites at once.

  • Grouping never removes the individual. Shared-cause groups always expose per-location escalation, so aggregation can't hide a site that genuinely differs.

  • Confidence is labelled honestly. AI-inferred events carry a confidence score and detection source; deterministic events are marked as system events rather than given a fake percentage.

  • Stress-tested in a live HTML prototype with a continuous simulated event stream to check that the layout holds under density.



Launch Interactive Prototype ↗

Create a free website with Framer, the website builder loved by startups, designers and agencies.