← All work

        Envoy/Emergency & threat intelligence platform/Real-time systems
      

Turning broadcast alerts into a state-driven operational system

Admins running a live incident couldn't answer the one question that mattered: who needs help right now. I led the transformation of Envoy's Emergency Messaging from a one-way broadcast tool into a state-driven coordination platform, cutting incident resolution time 20–30% and lifting response visibility 40–60%.

Admin incident view switching between Responses and Roll call, showing need help, safe, read, delivered and failed-to-reach counts — The admin view during a live incident. Responses and Roll call are two reads on one state, not two separate tools.

60-second read

Problem

Admins could send an emergency alert but could not see who had responded or who still needed help.

System decision

Model the incident as explicit state so web and mobile always read the same situation.

My contribution

Led the change from one-way broadcast to a coordination platform across web and mobile, then signal ingestion.

Impact

Resolution time down 20 to 30%. Response visibility up 40 to 60%.

01 · Shipped

Not a redesign of screens, a redesign of the operating model. Live in production across Web and Mobile for enterprise, multi-location accounts.

40–60%

increase in response visibility

20–30%

reduction in incident resolution time

3

phases shipped, broadcast → threat intelligence

02 · The problem

Emergency Messaging could send. It could not coordinate. An admin fired an alert into the dark and then worked the phones, with no view of who had responded, who hadn't, or who had answered and still needed help. Across multi-location enterprise accounts, that gap widened with every office added.

“I sent it. I have no idea who's okay.”

“Leadership wants a status. I'm reading a spreadsheet.”

Not a niche problem

41% of security, workplace, facilities and IT managers said safeguarding the workplace had gotten harder in the previous 12 months.

74% of 1,000 workers surveyed had avoided going in to work because of a threat, from severe weather to security incidents.

Envoy security & workplace safety research

03 · What failed

First pass

Without explicit state modeling, Web and Mobile could disagree about the same incident: an admin's dashboard and an employee's phone showing different states from ordinary network latency. In a live emergency that isn't a cosmetic bug. It's the system lying to someone.

What replaced it

A single deterministic state machine, so every surface reads the same incident the same way, always.

              Draft
              →
              Active
              →
              Escalated
              →
              Resolved
              →
              Archived
            

System architecture: weather API and crime data feed into the incident engine state machine, threat processing and event bus, feeding web admin and mobile employee clients — The system-level view I designed against. One incident engine owns state; every client reads from it. Event ordering, state reconciliation, and latency tolerance were design problems here, not just engineering ones.

04 · What I cut

A dense, high-information grid showing every incident signal at once. I chose hierarchical aggregation instead: how many affected, how many responded, who needs help, with density on demand. Under real operational pressure, more data on screen isn't more clarity.

05 · Where I overrode the AI

I used AI to generate raw material: realistic emergency scenarios, before/after comparisons, and the edge cases most teams only find in production. It reframed flat requirements as operational scenarios worth arguing with.

What shipped, what got cut, and how the interface read under pressure came from product constraints and operational clarity, not from what the model produced.

The model's framing

The problem as a sequence: more steps, fewer steps. Clean, and wrong.

The actual failure mode

Ambiguous state, not step count. I rebuilt the model around explicit incident states, the thing AI never proposed, because it wasn't in the data I gave it. That shift, not any single screen, fixed cross-surface consistency.

06 · Platform evolution

Shipped in three phases, each one earning the next. The endpoint was never a better alert. It was a system that sees a threat before an admin has to.

Phase 1

Broadcast Roll Call

Basic alert plus yes/no response tracking. One-way, and blind to who actually needed help.

Phase 2

Structured Coordination

Explicit lifecycle modeling and two-way communication, so an admin could act on a non-response.

Phase 3

Proactive Threat Intelligence

Location-aware signal ingestion (weather and environmental risk), surfacing incidents before anyone reports one.

Add an alert modal with source, threat type, severity, radius, notify targets and delivery methods — Phase 3. Admins define the threat criteria that generate incidents: source, severity, radius, and who gets told.

Weather alerts map with severity-coded regions and a wind advisory detail panel, plus the mobile equivalent — The same signal on web and mobile. Severity is encoded in the map, and the detail panel answers what, where, when, and impact before an admin decides to notify.

07 · In use

Recipient flow across four phones: lock screen notification, status prompt with I'm safe and I need help, call sheet, and the resulting chat thread — The recipient path. Status is required before chat or call unlocks. An ambiguous “read but unanswered” state is the one thing an admin can't act on, so the interface refuses to produce it.

Four phone screens showing no-response reminder, I'm safe thread, I need help thread, and two-way coordination with the emergency response team — Two-way coordination in the same thread. “No response” is an explicit, actionable state with an automatic reminder. A person who answered “I need help” gets a different conversation from one who answered “I'm safe.”

Admin live message view with emergency takeover banner and response breakdown by need help, safe, read, delivered, failed to reach — Admin during a live incident: aggregate first, roster on demand.

Admin opening a chat with an individual recipient from the response roster — One click from a row to a conversation, without leaving the incident.

08 · Response

Measured across enterprise, multi-location accounts after rollout.

Admin confusion in live incidents ↓ 25–35%

Mis-sent / mis-resolved incidents ↓ 20%

Manual admin follow-up ↓ 30%

Cross-platform inconsistencies ↓ 20%

Time to situational assessment ↓ 20–30%

Safety tooling used pre-emergency ↑ 35%

09 · Where the framework went

The three-phase model wasn't a slide. It became the shape of the roadmap, and eventually the shape of a product line.

Nov 2023

Phase 1 ships

Emergency notifications launch inside the Envoy Workplace Platform: SMS, push, and email, drawing on real-time workplace data so a message reaches whoever is actually onsite that day.

↳ Broadcast & roll call

Nov 2025

Phase 2 arrives in full

Six updates land together: Control Center check-in filtering, two-way chat with a designated local response team, interactive emergency roll call, custom preset responses for safe / need help, attachments, and kiosk takeovers.

↳ Structured coordination

Aug 2026

Phase 3 becomes the product

Envoy Response launches as a named product line: threat intelligence and incident management, with a global threat dashboard across sites. Threat detection & response is now a top-level product in Envoy's platform nav.

↳ Proactive threat intelligence

The shipped product, 2026

Envoy's screens · evidence, not my design work

Envoy's own framing today: “Emergency response that doesn't stop at the alert.” Three questions drive the product: who's at risk, have they been notified, are they safe. That is the state model, stated as a value proposition.

Envoy Response threat intelligence dashboard: a critical warehouse fire with an impact radius on the map and a panel listing 181 impacted people across onsite, travelers and homes, with a Create incident button — A threat resolves to a population (181 impacted, split into onsite, travelers, and homes), and then to a button marked *Create incident*. Signal becomes incident becomes coordination: the three phases, in one screen.

The same model extended past the building: a traveling executive, her itinerary, and the threats near her. Presence stopped meaning “checked in at an office.”

The line Envoy leads with now, “many systems alert everyone on a list; Envoy shows you who's actually impacted”, is the state-modeling argument from Phase 1, sold as the differentiator.

“Envoy helps us quickly understand what's happening, communicate with confidence, and make sure the right people receive the right information before a situation escalates.”
Senior Director of Security, Minnesota Twins

I designed the framework and the Phase 1 and 2 surfaces. What I'd point to is not that I shipped every one of these. It's that the sequence held. State modeling first, coordination second, signal ingestion third. Each phase was buildable because the one before it had already made the incident an explicit object rather than a message.

10 · Takeaways

01 Model system state before designing interface.

02 Deterministic behavior reduces ambiguity under pressure.

03 Signal integration must be architected early, not bolted on.

04 Information hierarchy is an operational safety concern.

In an emergency, ambiguity is the enemy. The system has to agree with itself before it can help anyone else.

Next case study → Back to all work