emergency triage system for 911 calls
2024 / Product Design, Fullstack
A majority of 911 calls are non critical. When truly critical emergencies appear, the bottleneck are the non-emergency calls.
Dispatch AI started from a spontaneous trip with 3 friends at the Berkeley AI Hackathon (during my hackathon splurge in freshman year). Post-hackathon, we decided to take this project further and launched a venture with Berkeley SkyDeck.
I designed V1 of Dispatch in under 36 hours at a hackathon and built out the broader platform afterwards.
- + full design system
- + full emergency response platform: incident monitoring, call handling, data analysis, and logging
- + database management system: new data processing pipeline for real-time call handling
- + event forecasting model: custom-trained model on historic call data
the operational loop
The system has two separate agents: the human operator handles emergency calls, while the AI agent manages non-emergency intake.
I designed Dispatch on a continuous operational loop that decides which agent should take over at each point. Each session is logged to inform future decisions.
01 live incident monitoring
Surface live language translation, script recommendations, and evolving call context in a single operational view trained on past emergency records.
02 dispatching units
Select and dispatch units directly on-platform, using pre-structured emergency procedures to reduce on-the-fly decision friction.
03 resolving alerts
Calls often function as fragmented alerts. I consolidated alerts, details, and checklists into a single pane so operators can act from one place.
04 customizable modules
Dispatchers typically navigate across multiple rigid systems. This version allows them to turn modules on or off depending on the stage of operations and the data they need in that moment.
05 pathfinding
Operators can monitor first-responder routes using live Google Maps data, review traffic between waypoints, and recommend changes as the situation evolves.
06 historic call data
Instead of relying on thousand-page archives, previous calls are stored in a central searchable database with configurable access and visibility rules.
07 forecast future call volumes
Historic volume data becomes a forward-looking tool, helping dispatch centers anticipate spikes and prepare staffing ahead of time.
the problem
The grim reality of dispatch centers: 82% are understaffed, with the average wait time of Oakland PD being 62 seconds. 90% of these calls are non-emergency, creating a system where dispatchers are overwhelmed with routine calls while critical emergencies wait.
This constant pressure takes a severe toll on dispatchers' mental health and operational efficiency.
"We get a lot of non-emergency calls that distract us from critical calls."- LAPD Deputy Chief
"I feel chronically anxious and stressed, which has impacted my mental health."- Dispatcher
at ground 0
We had the opportunity to speak directly with LAPD staff and observed common trends across dispatch centers. Through our research, we identified three key pain points that affect dispatchers daily.
user archetype
The archetypical user sits on two ends of the spectrum:
- Veteran dispatchers with decades of tenure
- New-hires with no habitual reflexes toward dispatch ops
However, both parties are overwhelmed by the amount of data they need to consume on a daily basis. This surfaces most when reading off manual instruction scripts during emergencies.
current workflow
There are 3 primary decision points in a call. Currently, this work is entirely manual: dispatchers type into tiny textboxes and read off scripts. The process is inefficient and error-prone.
the root node
Poorly documented calls are the root cause of distress. The symptoms include slower response times, operator stress from repetitive calls, and manual, inflexible response procedures.
The opportunity, therefore, is offloading documentation to a more accurate and efficient agent to free up time for dispatchers to focus on critical calls.
big picture: communication flow
The communication workflow moves through a chain of command from the caller to the dispatcher, incident commander, unit commander, and first responders. That information also has to overcome physical barriers: sensor systems, GPS, wifi signals, and bluetooth.
This helped me understand where each window, module, and task belonged inside the broader communications workflow.
the tradeoff between accuracy & speed
Response time is the immediate thing holding dispatchers back, but forgoing accuracy for speed could be more costly. This informed the decision to migrate the database and model to a less accurate but faster system that could deliver responses rapidly.
I benchmarked 3 models, Mistral, GPT-4, and a custom-trained model, to see whether there were significant differences in performance. While the larger models were marginally more accurate, they were 230% slower than the lighter-weight model we ultimately chose.
incorporating user feedback
Early exploration for letting operators share feedback progressively during a live call without interrupting the workflow.
drag & drop configuration
The workflow needed to flex to different scenarios. Drag and drop lets users surface the information they need on the fly without constantly entering the config panel.
appendix
design system
Custom-built branding and component library, referenced from NATO symbology and color guidelines.
food for thought
- Over-optimized UX can be a disease. Humans are wired to crave familiarity, and even slight deviations can cause a net reduction in user experience. We kept the long transcripts instead of truncating them because that was the long-standing structure dispatchers were already used to engaging with.
- Trust in human intuition. It is better to forgo accuracy for speed than the other way around. It is better to correct wrong information than to falsely expect perfect answers in a life-or-death situation.