NG911 Software Problems: The 7 That Break at the PSAP Boundary, and How to Avoid Them

Why does a GIS project turn into a call handling replacement proposal?

An authority sets out to fix routing data. Somewhere in discovery a vendor points out that the routing problem would be smaller if every center were on the same platform, and a data cleanup project acquires a procurement for call handling equipment attached to it. The logic is not wrong, it is just a different project with a different budget, a different timeline and a different risk profile.

What makes this specific to 911 is that the platform decision is emotionally larger than the data decision. Directors have opinions about Motorola VESTA and Comtech Solacom Guardian, and comparatively few have opinions about address point validation, so the conversation drifts to the thing people can argue about. Meanwhile the routing errors that cause real misroutes are geospatial and would persist under any platform.

The fix is sequencing. Run a validation pass over one county's data against your state's adopted model before you scope anything else. The error count that comes back tells you honestly whether routing or transfers is your first project. If routing is the answer, the GIS validation and reconciliation pipeline is $80,000 to $180,000 over 3 to 5 months and it is where most authorities should start. Do not build your own i3 call handling core under any circumstances. That is a certified, continuously operating telephony product with a 3am support obligation, and the right question to ask any vendor offering to build one is who answers the phone when a position will not launch.

What goes wrong with county GIS data once you start validating it?

Two things, and neither is technical. The first is that the errors belong to somebody else. Road centerlines, address points and boundary polygons are maintained by counties and addressing authorities who did not commission your project, have their own workload, and until now had no reason to care that two adjacent counties disagree about where the line runs. A gap between two counties was nobody's error under legacy routing. Under location based routing it is a misroute waiting for the right caller.

The second is volume. The first validation pass on a county that has never been validated typically returns a number that alarms people, and the natural reaction is to argue with the tool. Some of those failures genuinely are false positives from a model interpretation dispute, and sorting real from spurious is the first month of work rather than a bug.

The pattern that works is to make ownership unavoidable and progress visible. Errors are assigned to the addressing authority that owns them, dashboards are per county rather than regional, and remediation is funded alongside the tooling. Authorities that fund only the dashboard watch the number stay flat for a year. Authorities that fund correction see routing improve inside the first two quarters, and they can prove it, which is what keeps surcharge funded investment defensible.

Why do the call handling and ESInet integrations break after launch?

The first break is commercial rather than technical. Getting data out of a call handling platform depends on what your contract entitles you to and what interface the vendor will expose, and those are negotiations with two companies rather than engineering tasks. Projects that assumed an interface exists have stalled waiting for a contract amendment nobody scoped.

The second is method. There is a large difference between a documented interface, a logging recorder feed and screen scraping, and only the first two belong anywhere near an emergency environment. Screen scraping survives until the vendor ships an update, which they will, on their schedule, without telling you.

The third is the mixed estate. A region with several vendors and several migration stages has several integrations, and each vendor upgrade is a potential break in one of them. This is not a one time cost, it is an ongoing maintenance obligation that belongs in the operating budget rather than the capital request.

The fourth is the ESInet provider. Whether they will expose what you need is a contract question first and an architecture question second, and it should be settled before design. The fix throughout is to require, in the statement of work, the named product, the named interface, the contractual basis for access, and what happens when the vendor upgrades.

What happens when additional data policy and retention are not decided first?

The standard describes how supplementary information can be referenced with a call. It does not decide which sources your authority trusts, what a telecommunicator is permitted to see, for how long it is retained, how it is disclosed under your state's records law, or what gets redacted. Those are policy decisions, and when they are not made before design the build stalls in month three waiting for a committee.

Worse, the decisions get made implicitly by whoever writes the code. A source is included because it was available, a retention period is set because a default existed, and an access log is added later because someone asked. In an environment where call content and criminal justice information carry statutory obligations, defaults are not a safe way to decide.

There is an operational failure here too. In an emergency system a slow or unavailable data source must never delay the screen the telecommunicator is working. Timeouts, graceful degradation and a clear indication of what is missing are design decisions, not bugs to be fixed after a bad night.

The fix is to run the policy work in parallel with discovery and treat it as a deliverable. Write down the approved sources, the retention rule per category, the access logging requirement and the redaction path before the interface is designed. Text to 911 belongs in the same conversation, because text sessions are records that have to be retained, disclosed and redacted alongside voice, and that is a records problem rather than a telephony one.

Should you build custom or configure what you already own?

Buy the call handling platform, always. VESTA, Solacom Guardian, Carbyne and RapidDeploy operate under certification, redundancy and support obligations that took years to build, and no authority gains anything by owning that. Choosing between them is a genuine procurement, and the questions worth asking are about transfer behaviour with your specific neighbours, what data they will expose to you, and how they behave while part of your region is still legacy.

Buy the ESInet as a service in most cases. Owning transport infrastructure is not where a 911 authority's advantage lies, and the operational burden is significant.

Before commissioning anything custom, check whether your existing platform already does it. Some vendors provide reporting and additional data presentation that is adequate for a single center authority, and paying to rebuild that is waste.

Build when you are a state or regional authority responsible for many PSAPs and cannot get comparable operational data across them. Build when your counties' GIS is the reason calls route wrong, because no product fixes that. Build when your busiest transfer relationship crosses a vendor boundary and telecommunicators are reading coordinates over a phone line. And build when your authority has decided what additional data telecommunicators should see and no platform will assemble it on your terms.

How do hidden costs get into the quote?

The largest hidden cost is county GIS remediation. The tooling is quotable. The work of correcting thousands of address points and reconciling boundaries sits with authorities who are not party to your contract, and if it is not funded the project delivers a report rather than an outcome. Put it in the program budget explicitly.

The second is vendor count. Each distinct call handling product in your region is a separate commercial negotiation and a separate integration to build and maintain. A quote written for a region with two vendors does not scale to five by simple multiplication, because the fifth negotiation is often the slowest.

The third is security posture. Anything touching criminal justice information or call content brings authentication, audit, retention and access review requirements that are engineering scope rather than a policy attachment.

The fourth is testing. The only credible acceptance for this work involves telecommunicators in a lab running realistic scenarios including a transfer to a neighbouring center, which means staff time, scheduling around shifts and a lab environment. Quotes that show a demonstration to a director instead have not priced acceptance.

The fifth is the interim period. Migration takes years, and the years where half your region is next generation and half is not are where the operational risk lives. That interim behaviour is scope, and because it is temporary by definition it is the first thing dropped from an estimate.

What separates an NG911 build that works from one that fails?

The first separator is whether the developer can explain how a location resolves to a PSAP in the i3 model without prompting. If they cannot describe the role of authoritative geospatial data in routing, they will treat your GIS work as a mapping exercise and you will fund a rewrite.

The second is whether error ownership is designed in. A validation pipeline that produces a regional number changes nothing. One that assigns each error to the addressing authority that owns it, shows per county progress and tracks time to correction is what actually moves the routing accuracy.

The third is degradation behaviour. Ask what happens when an additional data source is slow or dead. The right answer is a timeout, a clearly marked gap on the screen and no delay to the telecommunicator. Any answer that assumes availability has not been designed for the night it matters.

The fourth is acceptance testing with telecommunicators rather than a demonstration to a director, including a live transfer to a neighbour on a different platform.

The last is ownership, which matters more here than almost anywhere else because regional programs run for decades and outlive their vendors and their staff. The authority should own the repositories, the cloud accounts, the pipelines and the data outright, with an unrestricted right to hire another firm, written in before kickoff. At Digital Heroes that is the position from the first commit.