Emergency Mass Notification Software: Targeting the Right Addresses and Proving Delivery Afterwards

Six blocks, twenty minutes, 2:10 in the morning

A transmission main is leaking and the fire chief wants six blocks evacuated. The emergency manager is at a workstation drawing a polygon over a map, then deciding what goes out over it. Text and voice to the opt in list, which covers perhaps a fifth of the households in that polygon and skews heavily toward people who signed up at a county fair four years ago. A wireless alert through the federal gateway, which will reach far more phones but will also wake up people three blocks outside the danger area, because device based targeting is approximate. Sirens if the county has them. A post to social media, typed separately, in a slightly different wording than the text went out with, which is how the first contradiction of the night gets created.

By 6am the leak is capped and the real work starts. Somebody will ask how many people in that polygon were actually reached, and whether the resident at a specific address who says she was never warned is right. The honest answer in most jurisdictions is that nobody knows, because the delivery records live in the notification vendor's reporting screen, the wireless alert has no per device receipt by design, and the sirens have no telemetry at all.

The polygon is the easy part, the list underneath it is not

Every product on the market lets you draw a shape. What separates a warning system that works from one that looks like it works is what the shape resolves to. An opt in subscriber list resolves to whoever volunteered. That population is older, more affluent, more English speaking and more long tenured than your actual community, and it under represents exactly the renters and recent arrivals a night evacuation is most likely to fail.

Address level targeting resolves to parcels, and then to the people and phone numbers associated with them, assembled from your own utility billing accounts, your address point layer, listed and appended telephone data and whatever opt in you do hold. That is a data engineering problem with real ownership and privacy questions attached, and it is precisely the problem the packaged products cannot solve for you, because the data lives in your county assessor and your water utility, not in their platform.

Where Everbridge, Rave, AlertMedia, Genasys and OnSolve stop

These are serious platforms and for a large share of buyers they are the right purchase. Everbridge and OnSolve carry deep multi channel delivery and enterprise workflows. AlertMedia is excellent for warning a known, employed population where you already hold accurate contact records. Rave has strong ties into the public safety side. Genasys brings acoustic hardware alongside software, which matters if you actually own sirens or long range acoustic devices.

The common ceiling is the same for all of them. 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 parcel and utility systems. Their delivery evidence is a report inside their product, exported as a document, which is fine for an after action review and thin as a legal record. And multilingual alerting is template based, so it covers the languages you loaded in advance in the wording you loaded, which is a real constraint in a county where the languages spoken on one street do not match the county wide census profile.

The federal gateway reality check, and the honest architecture

Here is the part where inexperienced developers get emergency managers into trouble. Sending wireless emergency alerts and broadcast alerts through the federal system is not an integration you write over a weekend. Your jurisdiction has to be a designated alerting authority with an agreement in place, your staff have to be trained, and the software originating alerts has to go through the compatibility process the federal programme office runs. That is a programme with a queue, not an API key.

So the architecture we recommend, and the one we build, is deliberately split. Own the layer that is genuinely yours: the address resolution, the audience assembly, the message composition in multiple languages, the direct channels of text, voice, email and app push, and the evidence store. Then treat the federal gateway leg as an approved sender you compose into, so a single incident produces one message identity that goes out through your channels and through the approved path, with everything logged as one event. Emergency managers who try to replace the whole stack in one project usually end up with neither half working. The split gets you the targeting and the evidence in months while your wireless and broadcast path keeps operating exactly as it does today.

Composition is where contradictions get created

The wireless alert is short by design, with modern devices supporting a longer message than the original ninety character limit and Spanish language delivery on capable handsets. Your text message can be longer. Your voice call has to be spoken. Your social post has hashtags and a link. In most agencies each of those is typed by a different person under time pressure, and the wording drifts, which is how a resident ends up with a text saying shelter in place and a wireless alert saying evacuate.

Build one message object with channel renderings derived from it, so the emergency manager writes the incident once and reviews each rendering before send. Translation belongs in that flow, pre approved by whoever in your jurisdiction is authorised to approve emergency wording in each language, because an unreviewed machine translation of an evacuation instruction is not a risk worth taking at 2am. Hold a library of pre approved incident templates for the hazards you actually have, reviewed annually, so the composition step at 2am is filling in a location rather than writing prose.

Delivery evidence, which is the whole reason to build

• Every intended recipient at send time, with the address and the source that produced that contact record, frozen as a snapshot rather than recomputed later.
• Per attempt outcomes by channel: delivered, failed, busy, invalid, answered by a human, answered by voicemail, opened.
• The exact rendered content that went out on each channel, with the version and the approver.
• Retry policy and what it actually did, since a call attempted three times and never answered is a different fact from one never attempted.
• The polygon geometry and the underlying parcel set as they existed at send time, because your address layer will change and your record has to reflect the night in question.
• An immutable append only log, so nobody can tidy it up before an after action review.

That package is what turns the question of whether a resident was warned from a memory contest into a document. It is also, in our experience, the single feature that makes a legal department stop objecting to the project budget.

What this costs and how long it takes

A first release covering address resolution against your parcel and utility data, audience assembly with polygon and list targeting, one message composition flow with text, voice and email, and the evidence store runs $80,000 to $170,000 and ships in 12 to 18 weeks. The full platform adding app push, siren and acoustic device control, composition into the federal gateway path, multilingual template governance, a resident self service preference portal and the after action reporting suite runs $200,000 to $500,000 across 8 to 14 months.

Cost drivers specific to this build: the state of your address data, which is the single biggest variable and is usually worse than the emergency manager believes; the number of utility and billing systems you need to join, since a county with four water districts has four integrations; voice capacity, because dialling tens of thousands of numbers in a few minutes is a telephony scale decision with real cost; and language coverage, because each additional approved language is a governance process as much as a translation.

When buying is the right answer

Buy if you are a campus, a hospital system or an employer warning a population you already have accurate contact records for. That is what AlertMedia and Everbridge do well, your targeting problem is solved by your human resources (HR) or student system, and a custom build would be an expensive way to arrive at the same place. Buy if you are a small jurisdiction whose alerting is occasional and whose parcel data is not maintained, because 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 can honestly cover.

How to choose a developer for public alerting

Ask them 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 answer reveals they have read a specification and never delivered in this space.

Ask how they would join parcel, utility and address point data, and what they would do with the roughly ten to fifteen percent of records that will not match cleanly, because there always is such a set and pretending otherwise is how targeting silently fails. Ask them to describe the evidence snapshot: if they propose querying the recipient list later rather than freezing it at send, they do not understand what the record is for.

Ask about voice scale and what happens when the carrier throttles you mid campaign. Then settle ownership before kickoff, including the resident contact data, which must stay in infrastructure you control under your own retention rules. At Digital Heroes the jurisdiction owns the code and the data from the first commit. Start your scoping by taking your last real activation and trying to produce, today, a list of every address in the polygon and what each one received. However long that takes you is the problem you are buying out of.