Computer Aided Dispatch Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping a full CAD replacement go wrong so often?

Because the complaint and the cause are different things. Directors call about screens, change orders and a decade of accumulated frustration, and the specification that follows replaces the dispatch core. The core is the part with the hardest non functional requirements in public safety software: continuous operation, redundancy across sites, a failover you have actually tested with dispatchers on the floor, a documented degraded mode when the network is gone, criminal justice information security controls, and a support rotation with a human who answers at 3am on a holiday.

Building that is possible. Owning it for ten years on a public agency's staffing and budget cycle is a different question, and it is the one that sinks projects. A CAD you own but cannot maintain is worse than a product you complain about, because the complaint at least has a phone number attached.

For most centers the correct first project is the layer around the existing system. Get a real time feed of your own incident and unit data into a database you control, and everything the vendor quotes as a change order becomes work you schedule yourself: dashboards for the deputy chief, unit hour utilisation and response time analysis without waiting on a report writer, station alerting, records prefill, an automatic aid bridge, a public incident feed. That runs $90,000 to $220,000 over 3 to 6 months and removes most of the pain that made you consider a replacement. It also makes the eventual procurement decision an informed one.

What goes wrong when you migrate run cards, GIS and the status model?

Run cards are the item everyone assumes is data and everyone discovers is folklore. The written cards describe a response plan that was current several reorganisations ago, and the actual plan lives in the difference between what the card says and what dispatchers do. Migrate the cards without capturing that difference and you have built a system that recommends what the paperwork says rather than what the department wants.

GIS is the schedule risk. Address points, road centerlines and response boundaries have to be authoritative, and most jurisdictions discover theirs are not once something starts routing against them. Annexations were never reflected, apartment complexes have one point for four hundred units, and two agencies disagree about where a boundary runs. That is months of work in another department's queue, not yours.

The status model is the quiet one. Every agency defines available, responding, on scene and out of service slightly differently, and cross staffed apparatus break naive models entirely, because one crew can be an engine or a medic but never both simultaneously.

Fix all three the same way: validate against reality before building against it. Sit with dispatchers and record every override for two weeks, because each one is a run card that is wrong. Route test the GIS data against a month of historical incidents before the project depends on it. And model crews and apparatus as separate objects from the first schema, since retrofitting that separation later touches everything.

Why do the records, ePCR and station alerting interfaces break after launch?

Because each interface is a relationship with another vendor rather than a piece of software you control, and their release schedules are not yours. The common failure is partial rather than total: the ePCR interface carries half the fields, so medics still retype patient demographics, and the records interface carries the incident but not the narrative, so officers do the same. Nobody logs this as an outage because the interface technically works.

Station alerting breaks on hardware. It is a physical system with tones, lights and door controls, and its integration is closer to industrial control than to a web API. Timing matters, and a delay that would be invisible in business software is a delay in getting a crew out of the door.

The fixes start before the contract. Ask any developer what they have integrated by name, meaning specific station alerting hardware, a specific records system, a specific ePCR, a specific logging recorder, because public safety interfaces are not generic APIs and the difference between a vendor with a documented interface and one with a database you can read is months of work. Then require a field level mapping document for each interface as a deliverable, so partial coverage is visible at design time rather than discovered by a medic. And monitor each interface for staleness rather than for errors, because these fail by going quiet.

What happens when degraded mode and failover are not covered?

This is the requirement that separates a CAD from an application, and it is the one most often deferred. A network drop between the dispatch floor and the server room during a working incident is not a hypothetical. It happens, and what matters is what the room does in the ninety seconds afterwards.

• Degraded mode has to be designed, meaning local caching, a defined set of operations that still work, and a written procedure the dispatcher follows without needing to improvise.
• Reconciliation has to be designed too, because the work done during the outage must merge back without duplicating incidents or losing timestamps.
• Failover has to be tested with dispatchers on the floor, not demonstrated in a maintenance window, because the failure mode you care about is human as much as technical.
• Redundancy across sites is a design constraint from day one rather than a line item added later, since it shapes how state is held.
• Criminal justice information security requirements apply to the system, the hosting environment and every person with access, covering authentication, audit logging, encryption and personnel screening, and they are engineering scope rather than a checklist at the end.

Confirm current specifics with your state systems officer, because interpretation and audit practice vary. A developer who talks about uptime percentages rather than degraded mode has built business software.

Should you build custom or stay with the vendor you have?

Stay if you are a single agency center under roughly 50,000 calls for service a year. The economics are not close. CentralSquare, Tyler New World, Motorola PremierOne, Mark43 and Hexagon OnCall carry certification, redundancy and support obligations that a custom build has to replicate at your cost, and your energy is better spent on the interfaces and the data feed.

Stay if your state or region operates a shared CAD you can join, because interoperability with neighbours is usually worth more than a perfect fit. And stay if you cannot commit to permanent technical staff, which is a staffing decision rather than a software one and should be made honestly.

Build the core when you are a large consolidated or regional center, your deployment model has already defeated two procurement attempts, you have or can hire real engineering capacity, and you can fund a decade rather than a project. Build the surround layer in almost every other case, immediately, because it is cheap relative to the pain. Judge the products on specifics rather than screens: deployment logic that matches your agency, the ability to get a live stream of your own data, and how automatic aid across separate systems is handled.

How do hidden costs get into the quote?

Five items drive the overrun. The number of agencies, because their status models and run cards always differ and reconciling them is a political process before it is a technical one. The interface list, since each one is a separate negotiation with a separate vendor on their timeline. GIS data quality, which is usually another department's work and outside your control. Redundancy architecture, which is not a line item but a constraint that shapes the whole design. And cutover, which for a CAD means running parallel and training every dispatcher on every shift to muscle memory, measured in months rather than weeks.

Make them visible by asking for each interface as its own line with the counterparty named, GIS validation as a named prerequisite with an owner outside your project, and the cutover plan with shift coverage costed. Then ask what happens after go live: a CAD carries a permanent engineering commitment, and a proposal that ends at launch has priced half the programme.

What separates a build that works from one that fails here?

The working ones start with data rather than screens. A real time copy of incidents and unit status in a database the agency controls, then dashboards, then interfaces, then, if it is still justified, the core. That order means every step delivers something usable and the expensive decision is made with evidence rather than frustration.

The working ones also model deployment as the agency describes it: crews and apparatus separate, cross staffing representable, move up rules expressible in the language chiefs actually use, and a keyboard first interface, because experienced dispatchers work in muscle memory and two extra clicks per transaction costs seconds on every call.

The failing ones share one shape. The core was replaced first, the interface set was assumed to be a later phase, and the center discovered during cutover that half its integrations did not exist yet. The second shape is a project with no answer to who supports it at 3am in year four.

The test before signing is to ask what happens when the network between the dispatch floor and the server room drops mid incident, and listen for degraded mode, local caching, reconciliation and the written procedure. Then ask them to model unit status for cross staffed apparatus on a whiteboard. Both answers are quick to give if the person has done this work and impossible to fake if they have not.