A PSAP director evaluating dispatch alerting systems is in a specific and uncomfortable position. They know their current system well enough to catalog its failures. They know what the vendors will say. And they know that the wrong choice will live in their communications center for the next 15 years, through staffing changes, technology shifts, and calls that go sideways at the worst possible moment.
The evaluation process is where that decision gets made well or badly. Vendors who get to define the evaluation criteria will define them in ways that favor their system. Directors who define the criteria themselves, before the vendor conversations start, end up with a system that fits their actual operational requirements rather than a demo that looked good in a hotel conference room.
This is a working checklist for that evaluation. Six categories, specific questions, and the answers that should give you confidence versus the ones that should give you pause.
Category 1: CAD Integration
CAD integration is the foundation of a dispatch alerting system. Without it, the manual steps that create delay and variability in the current workflow remain in place. With it, the alert becomes a byproduct of the call intake process rather than a separate manual task.
Questions to ask and document:
- Which CAD platforms has this system been validated against, and can you provide reference sites running our specific CAD version?
- What is the integration method: API, serial interface, network socket, or middleware layer?
- What data fields pass between CAD and the alerting system, and in which direction?
- What is the system's behavior when CAD goes offline or returns from an outage?
- How long has the integration with our CAD platform been in production, and what is the failure history?
A vendor who can answer these questions with documentation and a reference contact is a vendor whose integration has been tested under real conditions. A vendor who answers them with general statements about compatibility is a vendor whose integration may work in controlled conditions and fail under load.
The integrated CAD dispatch alerting guide covers what a properly integrated system looks like in practice, including the specific workflow changes it produces at the console.
Category 2: Automated Voice Dispatch Capability
AVD removes the manual broadcast from the dispatcher's critical path. The call is processed, the announcement fires automatically, and units receive consistent details simultaneously. The dispatcher's attention stays on the reporting party and the incoming call queue rather than on keying a radio.
Questions to ask and document:
- Does the system include native AVD, or is it a third-party add-on that requires a separate integration and support relationship?
- How is the AVD announcement generated: text-to-speech from CAD data fields, pre-recorded audio, or a hybrid?
- What is the announcement format, and can it be customized to match the department's standard call information sequence?
- What happens to the AVD announcement if the CAD data is incomplete or contains an error?
- Can dispatchers override, edit, or suppress an AVD announcement in real time if needed?
The override question matters. A system that can't be corrected mid-transmission when a dispatcher catches an error before the announcement completes is a system that will eventually broadcast wrong information to responding units. The capability needs to be there, and it needs to be fast.
The future of automated dispatch voice systems covers where AVD technology is heading, including AI-assisted voice quality and integration with mobile notification platforms.
Category 3: Redundancy Architecture
A dispatch alerting system that fails during a mass casualty incident or a major storm event is a system that fails when it matters most. Redundancy is the category most vendors address in their marketing and most buyers underinvestigate in their evaluation.
Questions to ask and document:
- What are the primary and secondary alert paths, and are they physically independent of each other?
- What triggers automatic failover to the backup path, and how long does the switchover take?
- Does failover require any dispatcher action, or is it fully automatic?
- What is the system's behavior during a complete network outage at the dispatch center?
- Has automatic failover been tested under production conditions, and can you provide documentation of a real failover event?
That last question separates systems with documented redundancy from systems with theoretical redundancy. A vendor who can produce a log of an actual failover event, with timestamps and recovery details, has a system that has been tested under real conditions. A vendor who can only describe how the failover is designed to work has a system that may perform differently when the conditions that trigger it are also the conditions that stress everything else.
The full architecture of redundant dispatch alerting is covered in the building redundancy into dispatch alerting infrastructure article, including the specific failure modes that single-path systems expose during real incidents.
Category 4: Alert Confirmation and System Visibility
Dispatchers operating a manual alerting system have no reliable way to know whether the alert reached its destination until a unit acknowledges over the radio. If the alert failed silently, the first indication is an absence that has to be noticed, diagnosed, and corrected in real time while everything else at the console continues.
Questions to ask and document:
- Does the system display real-time confirmation status at the dispatch console showing which stations received the alert?
- How quickly does confirmation status update after an alert fires?
- Does the system generate an alert or flag when a station fails to confirm receipt?
- What does the system health monitoring interface look like, and who has access to it?
- Is alert confirmation data logged and retrievable for post-incident review and NFPA 1225 compliance documentation?
The compliance documentation question is worth pressing. NFPA 1225 requires health monitoring of emergency communications systems, and that monitoring has to be documented. A system that shows you confirmation status in real time but doesn't log it produces no compliance record. Both capabilities need to be present.
Category 5: Dispatcher Workload and Console Experience
The people who will live with this system every shift for the next 15 years are your dispatchers. Their experience at the console matters operationally and for retention. A system that reduces cognitive load under high call volume is a different daily reality from one that adds steps or introduces new points of confusion.
Questions to ask and document:
- How many manual steps does the system require per call, from CAD receipt to alert confirmation?
- Can we see the system running under a simulated high-volume scenario rather than a single-call demo?
- What does the training timeline look like for a dispatcher who has never used the system?
- What is the error recovery process when a dispatcher makes a mistake mid-dispatch?
- Can we speak with dispatchers currently using the system rather than only speaking with supervisors or department leadership?
That last request is the most useful one. A dispatcher who uses the system on a busy overnight shift will tell you things that don't appear in any vendor presentation. Ask for a reference that includes line-level dispatcher access, and pay attention to what they say about the system on high-volume nights.
Category 6: Support Model and Long-Term Viability
A dispatch alerting system that goes down at 3 AM on a holiday weekend needs a support path that doesn't depend on business hours, vendor geography, or the availability of a specific technician. The support model is the category most likely to be glossed over during a vendor evaluation and most likely to matter in year three of a contract.
Questions to ask and document:
- What is the documented response time commitment for a critical outage, and is it contractually enforceable?
- Is remote system access available for diagnostics and in some cases resolution, or does every service event require on-site presence?
- What is the firmware update cadence, and can updates be applied remotely?
- What is the vendor's financial stability and ownership history over the past five years?
- What happens to support and software updates if the vendor is acquired or discontinues the product line?
The last two questions are ones most directors don't ask and some vendors don't want to answer. A system procured from a company that gets acquired two years into the contract is a system whose support model, update cadence, and product roadmap may change without notice. The vendor's stability is part of the evaluation.
How to Run the Evaluation
The checklist above produces the most useful results when it's distributed to vendors in writing before the formal demonstration, with a request for documented answers rather than verbal responses during the demo. Vendors who provide thorough written documentation before the meeting have systems built with scrutiny in mind. Vendors who prefer to answer everything verbally during a live demonstration are creating conditions where comparisons are harder to make.
After written responses are received, a structured demonstration using a scenario drawn from your PSAP's actual call patterns is more informative than a vendor-scripted walkthrough. A 90-second multi-station alert during a simulated high-volume period tells you more about how the system performs than 45 minutes of feature narration.
Reference calls with peer PSAP directors, including direct dispatcher access, complete the picture. No documentation substitutes for a candid conversation with someone running the same system in a comparable environment.
Westnet's dispatch alerting systems page covers the full platform and is the right starting point for a documentation request. The team can provide CAD integration documentation, reference site contacts, and system architecture details as part of a formal evaluation process.
The Decision Criteria That Matter Most
If the checklist has to be compressed to three criteria for a final comparison, those criteria are: CAD integration that has been validated and is in production on your specific platform; automatic redundancy that has been tested under real conditions with documented results; and a support model with contractually enforceable response times and remote diagnostic capability.
Everything else is important but recoverable. Those three are the foundation the system runs on, and gaps in any of them will surface under exactly the conditions when the system needs to perform.
For a fuller picture of how the dispatch and station alerting layers work together as an integrated system, the fire station alerting systems guide covers the station side of the same infrastructure, useful context for PSAPs evaluating end-to-end alerting architecture rather than dispatch in isolation.
