What you will learn
- How call intake becomes a structured incident record
- How unit recommendation balances distance, capability, and availability
- What AVL tracking and status updates give a dispatcher during an incident
- How multi-agency incidents are coordinated without duplicate dispatch
- What the incident record must contain for review afterwards
What the project is
Dispatch is a decision under time pressure. A caller reports a fire, a medical emergency, or a road crash, often panicked, often unsure of the location. The dispatcher must extract the address, the nature of the emergency, and the risks, such as a trapped person or a hazardous material, then choose units: which fire station, which ambulance, which police unit, based on distance, capability, and current availability. The dispatch system structures that decision: it holds the incident, shows available units on a map, recommends the closest suitable ones, and records every assignment and status change with a timestamp.
The record matters as much as the speed. After an incident, the timestamps answer the questions that always follow: when was the call received, when were units dispatched, when did they arrive. A system that dispatches fast but records poorly will fail the review that follows a bad outcome, and a system that records perfectly but slows the dispatcher will be bypassed during a busy shift. The design tension between speed and record-keeping runs through this whole guide.
Core features
Dispatcher speed is the feature. Every screen, recommendation, and status update must survive a busy shift with multiple incidents open at once.
- Call intake with structured fields: location, incident type, caller details, and risk flags, with address validation and mapping.
- Unit recommendation by distance, capability, and availability, showing the reasoning so a dispatcher can override it knowingly.
- AVL tracking of units on a map, with status updates: available, dispatched, en route, on scene, and clear.
- Incident timeline recording every call, assignment, status change, and message, timestamped and immutable.
- Multi-agency incident handling, so fire, medical, and police units share one incident rather than three parallel ones.
- Pre-plans and hazard flags for addresses with known risks, such as hazardous materials storage or access difficulties.
- Reporting: response times, unit utilisation, and incident volumes, by type, area, and time of day.
How it is built
Build with dispatchers, in the dispatch room, not from a specification. A dispatch system designed without watching a busy shift will be redesigned during the first busy shift, under pressure.
- Dispatch study: observe shifts, list incident types, and learn which decisions dispatchers make by judgement and which the system can support.
- Incident and unit model: define incident types, priorities, unit capabilities, and status flows, with dispatcher input at every step.
- Core build: intake, recommendation, AVL, and timeline, tested in a training environment with realistic call volumes.
- Multi-agency and pre-plan features: shared incidents and hazard flags, tested in joint exercises before live use.
- Live rollout: parallel running with the old system for a period, then cutover with extra staffing, and response-time measurement from day one.
Tech considerations
Reliability and speed outrank novelty. The system must answer during the incident it is managing, when load is highest and patience is lowest.
- Mapping and AVL integration with unit GPS, updated frequently enough that a dispatcher trusts the map.
- High-availability hosting with failover, because a dispatch system that goes down during a major incident is a crisis on top of a crisis.
- Telephony integration for call handling, caller location where available, and call recording linked to the incident.
- Immutable incident timelines, so the record of what was decided and when cannot be edited after the fact.
- Role-based access for dispatchers, supervisors, and reviewers, with audit trails on every record change.
Challenges to plan for
Dispatch systems fail on location errors, recommendation distrust, and the busy-shift test. All three are discovered in the dispatch room, not in testing.
- Location errors: a caller who does not know their address, or a system that pins the wrong building, sends units to the wrong place.
- Recommendation distrust: a system that recommends a distant unit while a closer one sits unassigned, for a reason nobody explained, will be ignored.
- Busy-shift overload: a system that works with one incident open collapses when ten are open, which is exactly when it is needed most.
- Multi-agency friction: agencies with different radios, procedures, and systems share incidents badly unless the shared record is designed for it.
Who it is for, and honest limits
This fits dispatch centres, combined emergency services, and fire and rescue services running their own dispatch. It fits less well for a small volunteer brigade with one station and a handful of calls a week, where a phone tree and a radio may honestly be enough.
It does not replace dispatcher judgement. It structures the decision and records it. If staffing is the problem, software will make the shortage more visible, but the fix is recruitment and training, not a faster screen.
Frequently asked questions
How does unit recommendation work?
The system ranks available units by distance, capability match for the incident type, and current status, and shows the ranking to the dispatcher, who can accept or override it. The override and its reason are recorded, because the review afterwards needs to see the judgement, not just the outcome.
What is AVL?
Automatic vehicle location: GPS tracking of emergency vehicles, shown on the dispatcher's map. It lets dispatchers see which units are actually nearest, rather than relying on station locations or memory.
Can it handle multi-agency incidents?
Yes, where agencies agree to share an incident record. Fire, medical, and police units are assigned to the same incident with their own statuses, so coordination happens in one record instead of three phone calls.
What if the system goes down?
There must be a fallback: paper incident cards, radio procedures, and a recovery plan that restores the system without losing the incidents handled during the outage. The fallback should be drilled, not just documented.
How are response times measured?
From call receipt to dispatch, dispatch to arrival, and arrival to close, per incident and in aggregate. Stage timings show where delays happen, which a single total time hides.