Mass Notification Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does trying to replace the whole alerting stack at once go wrong?

The plan looks coherent on paper. One system that draws the polygon, resolves the households, composes the message, sends text, voice, email, app push, sirens, social media and the wireless alert, and produces the after action report. Every part of it is genuinely needed. The problem is that one of those parts is gated by a federal process with its own timetable, and the moment it becomes a dependency, everything behind it waits.

This is specific to public alerting because nowhere else in emergency software is a core channel governed by an external authorisation programme rather than by an integration. You cannot engineer your way past the alerting authority designation, the agreement, or the compatibility review, and no amount of budget shortens the queue. Emergency managers who try to replace the whole stack in one project typically end up with neither half working, because the parts that could have shipped were held to a schedule set elsewhere.

The fix is a deliberate split. Own the layer that is genuinely yours: address resolution, audience assembly, multilingual message composition, direct channels of text, voice, email and app push, and the evidence store. Treat the federal gateway leg as an approved sender you compose into, so one incident produces one message identity logged as a single event. In Digital Heroes delivery experience that first release runs $80,000 to $170,000 and ships in 12 to 18 weeks, with the full platform adding app push, siren control, gateway composition, multilingual governance, a resident preference portal and after action reporting at $200,000 to $500,000 across 8 to 14 months. Your wireless and broadcast path keeps operating exactly as it does today while the targeting and evidence get built.

What goes wrong when parcel, utility and address point data are merged?

The design assumes a clean join: parcels give you addresses, utility billing gives you names and phone numbers, address points give you geometry, and the polygon resolves to households. Then the data arrives. The assessor's parcel layer, the address point file and the water utility's billing accounts disagree with each other, a meaningful share of records will not match on the first pass, and a recently annexed area is in one system and not the others. A county with four water districts has four integrations, each with its own account structure and its own idea of what an address string looks like.

What makes this dangerous rather than merely tedious is that the unmatched set is invisible at send time. A subscriber list at least fails honestly, because everyone knows it only covers the people who signed up. A targeting system built on a partial join fails confidently, producing a recipient count that looks authoritative and quietly omits the households nobody could match.

The fix is to treat the unmatched set as a first class output rather than a rounding error. Every record that does not resolve goes to a review queue with the candidate matches shown, and the system reports coverage per polygon so an emergency manager sees that this area resolves well and that one does not. Expect this to be the longest part of the first release, and expect the state of your address data to be worse than anyone in the building currently believes. Start by taking your last real activation and trying to produce, today, a list of every address in the polygon. However long that takes is the problem you are buying out of.

Why do telephony, app push and gateway integrations break after launch?

Everything tested fine against a few hundred numbers. The first real activation puts tens of thousands of calls into the network in a few minutes, the carrier throttles you partway through, and the campaign that the dashboard says completed actually stopped. Text delivery hits filtering. App push tokens have gone stale on devices that have not opened the app since the last training exercise. The social post goes out with different wording than the text, because a different person typed it.

Alerting is unusual in that the system is idle for months and then asked to perform at maximum scale, at night, under stress, with no opportunity to warm up. Failures that would be invisible in daily software are exactly the ones that surface during an activation, and they surface at the point where nobody has attention to spare for diagnosis.

Three fixes. Design voice as a capacity decision with a stated throughput target and a documented behaviour when a carrier throttles, including whether the queue holds, reorders by priority, or fails visibly to the operator. Build one message object with channel renderings derived from it, so the emergency manager writes the incident once and reviews each rendering before send, which removes the class of failure where a resident gets a text saying shelter in place and a wireless alert saying evacuate. And exercise the system quarterly against a real subset, because an alerting platform that has not been fired in six months is an untested one.

What happens when delivery evidence and language obligations are not covered?

By 6am the incident is over and the questions start. How many people in that polygon were reached, and is the resident at a specific address who says she was never warned correct? If the delivery records live only in a vendor's reporting screen, the honest answer is that nobody knows, and that answer does not improve with time.

Evidence is what makes this build different from a messaging project. The record has to be frozen at send time rather than reconstructed later, because your address layer will change and a query run next month describes a different county. That means the intended recipient list with the source of each contact record, per attempt outcomes by channel including delivered, failed, busy, invalid, answered by a human and answered by voicemail, the exact rendered content with its version and approver, what the retry policy actually did, and the polygon geometry with the underlying parcel set as it existed that night, all in an append-only log nobody can tidy before an after action review. Wireless alerts will never give you per device receipts, so your direct channels carry the evidentiary weight.

Language coverage fails the same way, through good intentions. Template based alerting covers the languages you loaded in advance, in the wording you loaded, and a county wide census profile rarely matches the languages actually spoken on one street. Hold pre approved templates per language, reviewed by whoever in your jurisdiction is authorised to approve emergency wording, and capture language preference at address level where you can. Unreviewed machine translation of an evacuation instruction at 2am is not a risk worth accepting.

Should you build custom or configure what you already own?

Buy if you are a campus, hospital system or employer warning a population you already hold accurate contact records for. Everbridge and OnSolve carry deep multi channel delivery and enterprise workflows, AlertMedia is excellent where your human resources (HR) or student system already solves the targeting problem, Rave has strong ties into public safety, and Genasys brings acoustic hardware alongside software if you actually own sirens or long range acoustic devices. A custom build would be an expensive route to the same place.

Buy also if you are a small jurisdiction whose alerting is occasional and whose parcel data is not actively maintained. A build sitting on bad address data produces confident, wrong targeting, which is worse than the honest limitation of a subscriber list.

Build when address level accuracy is the actual mission, when you hold utility billing data that would materially improve targeting, when you have been asked to prove delivery and could not, when you are coordinating multiple jurisdictions that each hold part of the picture, or when your language obligations exceed what template based alerting honestly covers. The common ceiling on the packaged products is not capability. It is that your targeting quality is capped by the contact data you can push into their platform, and their model of who lives where is a list you maintain rather than a live join against your assessor and utility systems.

How do hidden costs get into the quote?

Four places that reliably surprise emergency managers.

• Address data condition. The single biggest variable and the one nobody can price without looking. Insist that a developer inspects your actual parcel layer, address points and one utility extract before quoting, and that the quote states an expected match rate and what happens to the remainder.
• Number of source systems. Each water district, each billing platform and each municipal annexation is its own integration. A quote saying utility integration in the singular has not read your county.
• Voice capacity. Dialling tens of thousands of numbers in minutes is a telephony scale decision with real recurring cost, separate from build cost. Ask for the throughput assumption in writing.
• Languages. Each additional approved language is a governance process as much as a translation, involving whoever signs off emergency wording. Price it per language, and price the review cycle, not just the strings.

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

Four tests, all of which you can apply in a first conversation.

Ask what they would do about the federal gateway. If they promise to build a direct sender without mentioning alerting authority designation, agreements and the compatibility process, end the conversation. That single answer reveals whether they have delivered in this space or only read a specification.

Ask how they would join parcel, utility and address point data, and specifically what happens to the records that will not match cleanly. There is always such a set, and pretending otherwise is how targeting silently fails on the night it matters.

Ask them to describe the evidence snapshot. If they propose querying the recipient list later rather than freezing it at send, they have not understood what the record is for. In practice this is also the feature that makes a legal department stop objecting to the project budget, so it is worth being precise about it early.

Settle ownership before kickoff, including the resident contact data, which must live in infrastructure you control under your own retention rules. At Digital Heroes the jurisdiction owns the code and the data from the first commit. Contact records assembled from utility billing and parcel data carry privacy obligations that do not travel well into a vendor's platform, and you should never need anyone's permission to export them.