Emergency Management Software: Problems and Solutions for Agencies That Coordinate Real Incidents

Why emergency management software makes or breaks an agency

It is 02:14 on the second night of a flood activation. The duty officer has WebEOC open with three boards: significant events, resource requests, and a road closure board somebody built in 2019 that nobody has permission to change. Public Works calls in and asks for four trailer pumps and twelve operators. That request gets typed into the significant events board, then retyped onto the request board, then the Logistics Section Chief gets a text because the board does not page anyone. Two hours later a mutual aid partner sends pumps. Nobody records which jurisdiction they came from, which is the detail that will cost you at closeout.

Meanwhile the Documentation Unit is printing blank ICS-214 activity logs because the ones people fill in on their phones end up in a shared drive as photos. The Everbridge send log lives in Everbridge. The evacuation zone status lives in Genasys or Zonehaven. The map lives in ArcGIS. The CAD feed is on a separate screen in the corner that nobody can query. Six systems, and the Planning Section Chief builds the ICS-209 by reading screens and typing.

The cost is measurable. Across the emergency management builds we have delivered, the pattern is consistent: a nine to twelve day activation generates somewhere between 150 and 300 hours of pure reconstruction work for the Finance and Documentation Units afterward, retyping paper logs into a form the state Public Assistance coordinator will accept. Then a chunk of it gets kicked back, because "assisted with debris removal" is not a project worksheet line. This software is used hard maybe six days a year, and on those six days it either holds or it does not.

Problem: your resource request board is a form with a list behind it

An ICS-213RR is not a ticket. A resource request has a lifecycle: requested, sourced, ordered, en route, checked in, assigned, demobilized, returned, invoiced. It carries a NIMS type, a jurisdiction of origin, a mutual aid agreement, an EMAC A-tag if it crossed a state line, an equipment rate code, and a work and rest cycle for the humans attached to it. A board does not know any of that. A board knows a text field.

WebEOC, Veoci and Knowledge Center boards are configurable, and vendors will sell you a configuration engagement to prove it. What they cannot do is enforce a state machine across two jurisdictions with different cost share rules, or carry the Schedule of Equipment Rates code from the moment the pump is ordered through to the invoice your Finance Section has to defend. Each board is a silo, and Salamander T-card scans at check-in land in a third place entirely.

A custom build makes the resource one object with one lifecycle. The check-in scan writes to the same row the request created. Demobilization fires automatically when the assignment ends and the operational period rolls. The object carries its cost code, its owning jurisdiction, its agreement, and its assignment down the ICS org chart to branch and division. When Logistics asks what is in the field right now and who is paying for it, that is a query rather than a phone call.

Problem: cost recovery starts on paper and ends in an appeal

This is where the real money is. Eleven days of activation, force account labor across six departments, equipment hours from a fleet system, timecards in Munis or Workday or Kronos, and a Finance Section Chief manually assembling a package for Grants Portal. Line items get rejected for documentation rather than for eligibility. The work was real. The record was not structured.

Crisis Track handles damage assessment and debris well. It does not know your payroll. WebEOC does not know your fleet rates. No incumbent tool assembles the package, so a human does, months later, from memory and photos.

The custom answer is capture at the source. Every activity log entry is structured at the moment it happens: person, position, cost center, site with coordinates, asset, hours, PA category, project. Payroll feeds in nightly and reconciles against the assignment roster, so a mismatch surfaces on day three rather than at closeout. Field photos carry a geotag and timestamp bound to a damage site ID that becomes a project worksheet line. Every change is written to an immutable audit log, exportable in the shape your state coordinator wants.

AI earns its keep here in one place. Vendor invoices, contracts and paper timesheets get scanned, and a document extraction model pulls vendor, date, equipment class and hours, matches to the applicable rate, and flags the mismatches for a human to confirm. It also reads procurement documentation and flags the contract with no competitive bid trail under 2 CFR 200 while you can still fix it, rather than during an audit two years out. On our builds this is the difference between three weeks of package assembly and three days.

Problem: the common operating picture lives in six systems and one person's head

Ask your EOC this question tonight: which shelters sit within two miles of a zone under mandatory evacuation order, are above 80 percent capacity, and have no generator on site? Nobody can answer it, because the zones are in one vendor, the shelters are on a spreadsheet or in the National Shelter System, and capacity is a phone call to a Red Cross liaison.

Vendor integrations do not fix this. What vendors call integration is usually a link out or a read-only feed. The data never joins, because nobody owns the keys.

A build gives you your own incident data layer. Ingest from ArcGIS feature services, NWS CAP feeds, the Everbridge or Rave API, your CAD read replica, and yes, WebEOC's API if you are keeping it. Normalize on shared keys: zone ID, facility ID, incident ID, resource ID. Once those join, the situation report drafts itself from real objects and a section chief edits it rather than authoring it. A plain-language query layer over the log means the 03:00 duty officer asks a question instead of remembering which board filter someone built six years ago.

Problem: activation depends on one person who knows who is actually qualified

Everbridge and Rave send. They do not staff an EOC. They do not know that the Logistics Section Chief position needs someone with ICS-300 current within 24 months, or that the person who acknowledged is already scheduled for the day shift, or that two positions on the org chart are still empty forty minutes into a partial activation. The roster is a spreadsheet, the org chart is a PDF, and credentials are in a training tracker or a binder.

A custom staffing engine treats the ICS org chart as data. Position, qualified pool pulled from your LMS (Learning Management System) or training records, shift schedule per operational period, notification out through your existing Everbridge or Rave account by API so you keep the delivery infrastructure and your IPAWS authority. Accept and decline fills the seat. No response in fifteen minutes escalates to the next qualified name. The EOC Manager stops running the phone tree and starts running the EOC.

Problem: the after action report takes ten weeks and changes nothing

The HSEEP after action report and improvement plan gets written in Word, months late, from interviews with people who have forgotten. Corrective actions live in a table. Nobody tracks them. The same friction shows up in the next exercise, and again in the next real incident.

When your log is structured, the AAR is assembled rather than remembered. Corrective actions become tracked objects with an owner, a due date and a verification step, linked back to the specific log entries that generated them and forward to the next exercise's objectives. AI clusters the activation's log and comms traffic to surface the repeated friction points a human reviewer misses, for example the same resource request bouncing between two ESF desks nine times. The same structured record assembles your EMAP accreditation evidence without a three month scramble.

What this costs and how long it takes

From Digital Heroes delivery experience across 2,000-plus projects: a focused first release typically runs $60k to $130k and ships in 12 to 16 weeks. In this category that first release is almost always the resource request lifecycle plus structured cost capture, because that is where the money leaks. A full platform covering staffing, common operating picture, damage assessment and Public Assistance packaging runs $150k to $400k phased across 6 to 12 months.

What pushes the number up here specifically. Integration count: each real one, CAD from Tyler or Motorola or CentralSquare, payroll from Munis or Workday, Esri enterprise, Everbridge or Rave, a state system like EMResource or EM Constellation, adds roughly two to four weeks. Offline and degraded operation: a field damage assessment app that must work with no connectivity and sync cleanly is not a checkbox, it is a design constraint that touches everything. Security review: StateRAMP posture, CJIS handling if CAD data touches the system, SSO with county AD. That adds calendar time more than engineering hours, but it is real calendar time. Multi-jurisdiction tenancy with different cost share rules is the single biggest multiplier. And procurement, whether RFP, sole source justification or a cooperative contract, is your calendar rather than ours, so start it early.

The most expensive mistake we see is trying to rebuild the whole ICS suite at once. Ship the one board that hurts.

Build versus buy: an honest position

Buy is genuinely right for a lot of agencies. Single jurisdiction, two or three activations a year, you need a log, some boards and mass notification, and your state provides the WebEOC license at no cost to the county. Take it. Do not spend $200k building a worse WebEOC to save a license you are not paying for.

Build when these signals show up. You are burning more than roughly half an FTE per quarter reconciling between systems. Your PA claims get delayed or deobligated for documentation reasons rather than eligibility. You have paid for a custom board configuration twice and your staff still exports to Excel. You operate across jurisdictions or agencies with different rules and no vendor's tenant model fits. Or your resource types simply do not exist in anyone's catalog, which is the reality for ports, utilities, health systems, large campuses and regional authorities.

Our position: for most single counties, keep the incumbents and build the layer that binds them into one object model. For regional authorities, states with roll-up needs, utilities and health systems, build the core and let the incumbent do notification delivery only. Either way, the decision is not about features. It is about who owns the data model your money and your people flow through.

How to choose a developer for emergency management software

Make them model the domain before contract. Ask them to whiteboard a 213RR lifecycle across two jurisdictions with different cost share and a demobilization that triggers on operational period rollover. If the word "ticket" comes out of their mouth, they will build you a helpdesk with an ICS skin.

Demand integration proof, not integration claims. Have they written against Esri feature services, an Everbridge or Rave API, a CAD read replica, a Munis or Workday payroll export? Ask the specific auth model they used on each. Vague answers here predict a six week surprise in month four.

Audit and compliance are design questions. Ask to see an immutable audit log design, a records retention schedule, a public records request export, and how the system produces 2 CFR 200 procurement documentation on its own. Ask whether they have survived a state security review.

Ownership, offline behavior, and a real exercise. Source in your repository, infrastructure as code, no per-seat trap, a written runbook. Then make them demo the field app with the network cable pulled, and run the system in a functional exercise before go-live. An EOC tool that has never been activated is a prototype.