911 Call Handling Systems: What PSAP Leaders Should Evaluate in 2026

A call handling system is the one piece of technology a telecommunicator touches on every single call, so getting the evaluation right matters more than almost any other 911 procurement decision.

A call handling system (CHS) typically stays in place for many years, which means the choice made this cycle will carry a PSAP through several technology generations, several vendor mergers, and whatever comes after the current wave of NG911 rollouts. That is a long time to live with the wrong fit.

This piece is a practical framework for comparing CHS platforms in 2026: what the system actually needs to do at the position, how to think about architecture and cost, and the procurement and cutover questions that tend to get skipped until they cause a problem. It closes with a checklist you can bring into vendor demos.

What a Call Handling System Actually Does at the Position

It is easy to talk about CHS in the abstract. In practice, the call taker's screen is where several distinct functions come together, and any evaluation should walk through each one separately rather than accepting a vendor's summary slide.

Call answering and queuing. The system has to answer, queue, and distribute calls across positions, ring groups, and time-of-day rules, and it has to do this correctly during a surge, not just during a demo.

Location and caller data. Legacy ANI/ALI delivered a phone number and a registered address. In an NG911 environment, location increasingly arrives as a PIDF-LO, the location object format the National Emergency Number Association (NENA) adopted for Next Generation 911, originally defined by the IETF in RFC 4119. Your CHS has to receive, parse, and display that object correctly, including when it updates mid-call as a caller moves.

Transfers and conferencing. Calls move between positions, agencies, and disciplines constantly. Evaluate how the system handles warm transfer, conference, and transfer of data (not just voice) alongside the call.

Multimedia and text. Text-to-911, photos, and video are no longer edge cases in most jurisdictions. Ask how the CHS ingests and displays these formats, and what happens to that data downstream, in the incident record and at the console.

Recording. Every call, every text thread, and ideally every screen action needs to be logged in a way that survives an audit, a court request, or an after-incident review, without a separate manual export step for the call taker.

Mapping and CAD integration. The call handling layer and the mapping/CAD layer have to stay synchronized in real time. A CHS that displays a location the CAD does not have yet, or vice versa, creates the kind of gap that shows up in incident reviews.

None of this is exotic. It is the baseline. The differentiation between vendors shows up in how reliably these functions perform together, under load, during a failover, and years into the contract, not in any single feature on a spec sheet.

Functional Requirements: Write Them Before You Talk to Vendors

The single biggest procurement mistake is letting a vendor's product catalog define your requirements list. Write your functional requirements first, based on how your agency actually operates, then use vendor demos to test against that list rather than to discover what you need.

Requirements should cover call volume and concurrency, position count today and at projected growth, discipline-specific workflows (law, fire, EMS, or combined), language line integration, TTY/TDD and text-to-911 handling, and any regional interop requirements if you dispatch across agency boundaries. Include your existing recording, CAD, and mapping vendors by name and ask every CHS vendor to describe the integration path with each one specifically, not generically.

Get this in writing before scoring proposals. A generic "supports open integration standards" answer is not a requirement met.

Integration with CAD, Mapping, and Recording

A CHS rarely lives alone. It sits between the network layer (trunks, ESInet) and the systems your agency already runs: CAD, GIS/mapping, logging recorders, and often a records management system downstream.

Ask three integration questions of every vendor. First, is the integration a certified, supported interface with your specific CAD and mapping products, or a custom build your agency will own the maintenance of. Second, what happens to that integration during a vendor upgrade cycle, who tests it, and on what schedule. Third, can you see a live reference site running the same CAD/mapping/recording combination you have, not just a similar one.

Integration risk is where CHS projects quietly go over budget and over schedule. It is worth spending more evaluation time here than on the call taker interface itself, because the interface is what you see in a demo and the integration is what breaks six months after go-live.

Redundancy and Failover Architecture

Ask every vendor to draw their failover architecture on a whiteboard, not describe it in marketing language. You want to understand, concretely: what happens to an active call if a server, a site, or a network path fails mid-call; how positions reconnect; whether failover is automatic or requires a manual step; and what the failover looks like across geographically diverse data centers versus a single site with local redundancy only.

For hosted and cloud-based CHS, ask specifically how the vendor's cloud infrastructure is architected for resiliency, including whether it spans multiple availability zones or regions, and what your agency's obligations are (network diversity, backup connectivity) to make that redundancy meaningful at your PSAP.

Redundancy claims are cheap to make and expensive to verify. Ask for the failover test results from the vendor's own most recent test, and ask what happened the last time a real outage occurred at a comparable customer site.

i3 Conformance at the Call Handling Layer

NENA's i3 architecture, formally the i3 Standard for Next Generation 9-1-1 (NENA-STA-010), defines the functional elements and interfaces an NG911 system needs, including how call handling systems receive location, media, and additional data. i3 conformance at the network and NGCS layer is necessary but not sufficient. The call handling system also has to correctly consume and display what the network delivers.

Ask vendors for specifics: which version of the i3 standard their CHS supports, whether they have participated in NENA's industry collaboration testing events (NENA runs periodic multi-vendor interoperability testing, known as ICE events, specifically to validate i3 behavior across vendors), and how they handle the transition period where some originating service providers or neighboring PSAPs are still on legacy interfaces.

Conformance on paper and conformance in a mixed legacy/NG911 environment are two different things. Ask for a reference customer running the same mixed environment you expect to operate in during your transition.

Hosted or Cloud vs. Premises: Look at Total Cost of Ownership

The purchase price comparison between a premises-based CHS and a hosted or cloud-native one almost always favors the cloud model on paper, and it often should. But the honest comparison is total cost of ownership over the full contract term, not sticker price.

For premises systems, total cost includes hardware refresh cycles, facility power and cooling, local IT staff time, and the capital cost of redundant infrastructure if you want true site diversity. For hosted or cloud systems, total cost includes recurring subscription fees, the bandwidth and network diversity your agency has to provide and maintain, any per-position or per-seat scaling costs as you grow, and exit costs if you ever need to migrate off the platform.

Ask each vendor for a five-year and a ten-year total cost model, not just a year-one quote. Ask what is included in the subscription and what triggers an additional charge: extra positions, additional recording retention, API integrations, or after-hours support.

Security

A CHS handles caller PII, location data, and increasingly multimedia evidence, all of which needs to be protected in a way that satisfies your agency's compliance obligations and your state's public safety data requirements.

Ask vendors directly about data encryption in transit and at rest, access controls and audit logging for who touched what call record and when, their patch and vulnerability management cadence, and what happens to your data if the vendor relationship ends. For cloud and hosted systems, ask which cloud infrastructure provider underlies the service and what security certifications that infrastructure carries.

Security review should happen alongside your agency's IT or cybersecurity function, not solely inside the 911 director's office. Bring them into the vendor conversation early rather than after the contract is signed.

Vendor Questions Worth Asking Directly

Some of the most useful information in a CHS evaluation comes from questions that do not appear on a typical RFP template. Ask how long the vendor has been supporting CHS specifically, not their parent company's overall history. Ask for a customer reference list you can call without the vendor on the line. Ask what the support escalation path looks like at 3 a.m. on a holiday weekend, with names and response time commitments, not a generic SLA percentage. Ask how often the platform has required an emergency patch in the last two years and why.

Vendor stability matters as much as feature depth. A CHS vendor that gets acquired, pivots product strategy, or discontinues a platform mid-contract creates real operational risk for your agency, so ask about ownership structure and product roadmap commitments directly.

Procurement Path: RFP and Cooperative Contracts

Most agencies choose between a full RFP process and purchasing through an existing cooperative or state contract. Cooperative purchasing vehicles, such as those offered through Sourcewell, NASPO ValuePoint, and regional buying groups, can shorten the procurement timeline significantly because the vendor has already been through a competitive solicitation and vetting process. Several 911 technology vendors, NGA included, hold contracts of this kind, and some state 911 offices maintain their own approved vendor lists or statewide term contracts specifically for 911 technology.

A full RFP still makes sense when your requirements are unusual, when you want maximum competitive leverage on price, or when your governing board or state 911 office requires it regardless of what cooperative options exist. Either path, build in time: a rushed procurement timeline is one of the most common causes of a rushed, poorly scoped implementation later.

Implementation and Cutover Risk

The evaluation does not end at contract signature. Ask every finalist vendor to walk through their implementation methodology in detail: a typical project timeline from contract to go-live, how many of your staff need to be dedicated to the project and for how long, and what the cutover night actually looks like operationally.

Cutover risk is highest when a PSAP tries to run parallel systems for too short a window, or cuts over without a tested rollback plan. Ask what the vendor's rollback procedure is if go-live reveals a problem, and ask for the honest version of what went wrong at the last two or three implementations, not just the success stories.

Training is part of implementation, not an afterthought bolted on at the end. Ask how training is delivered (in person, remote, train-the-trainer), how long it takes for a call taker to reach full proficiency on the new interface, and what refresher training looks like a year after go-live when new hires join a system your veteran staff already know cold.

Key Takeaways

• Write your functional requirements before talking to vendors, and score every demo against that list, not against the vendor's own feature narrative.
• Treat CAD, mapping, and recording integration as a first-order evaluation criterion, since that is where CHS projects most often go over budget and schedule.
• Compare hosted/cloud and premises options on total cost of ownership over five to ten years, not year-one price.
• Push every vendor for specifics on i3 conformance, failover architecture, and security, and ask for reference sites operating in conditions similar to yours.
• Build real time into the procurement and cutover schedule; rushed timelines are a leading cause of rocky go-lives.

If you are early in a CHS evaluation, it can help to see how a modern, cloud-native platform approaches these questions end to end. NEXiSConnect is built around that mapping, recording, and multimedia integration, and NGA's team is a useful sounding board even if you are still building your requirements list.