Mutual Aid Software Problems: The 7 That Stall Reimbursement, and How to Avoid Them

Why does the scope become a ticketing system?

The requirement usually arrives in operational language. Coordinators want to see requests, see what is outstanding, and see what has been filled. That description maps neatly onto a ticket with a status, and that is what gets built.

What is actually happening at one in the morning is contract formation. One party asks for a defined capability for a defined period, another offers it at a defined cost, someone accepts, and financial obligations attach to the acceptance. Every element that will be disputed later, what was asked for, what was offered, what was accepted, when the clock started and what rate applies, is agreed verbally and recorded nowhere both sides hold.

A ticket cannot carry that. It also cannot prevent the specific operational failure that costs the most during a large event, which is two coordinators allocating the same resource in parallel because neither can see the other's commitment. Nobody is at fault. There is no shared record, so both allocations are honest.

Scope the deployed resource as a state machine with a single shared timestamped history: requested, offered, accepted, authorised to move, departed, arrived, assigned, reassigned, released, departed for home, returned. Both jurisdictions see the same history and amendments are visible amendments with an author, never silent edits. Get that right and the four month invoice argument becomes a five minute reconciliation, because the facts are not in contention.

What goes wrong when resource registers and past event records are migrated?

A compact administrator with eighty participating jurisdictions is migrating eighty different worldviews, and the register is the hard part rather than the history.

Resource typing is the first problem. The national typing language is common and the capability behind it is claimed by the sending jurisdiction and inspected by nobody until it arrives. Migrating existing inventories imports every one of those unverified claims as fact. A type three engine appears in the register with a crew of four and full equipment because that is what somebody entered in 2019, and it shows up in a real event with a crew of two.

Handle it by migrating typing as a dated claim with an attributed source rather than as a property of the resource. Every registered resource carries its type, its components, its crew composition and the date the claim was last verified, and the register shows the age of that verification plainly. Resources with claims older than your policy threshold are visible as such rather than being quietly trusted.

Past event records are the second problem, and expectations need managing. Historical deployments almost never carry arrival and departure timestamps captured by the receiving jurisdiction, because nobody was capturing them. Migrating them produces a history with no defensible clock, so import them as reference records clearly marked, and start your defensible baseline at go live. Attempting to reconstruct timelines from invoices reproduces exactly the disagreement the system exists to prevent.

Why do payroll, fleet and rate integrations break after launch?

Labour and equipment evidence has to come from systems of record rather than from typed entries, and those systems belong to jurisdictions you do not control.

The first break is participation. Eighty jurisdictions means eighty payroll and fleet environments across many products and many versions, and a coordinating authority cannot integrate all of them. What breaks is the assumption that everyone will connect. Design for a spectrum: full integration for the largest participants, structured file upload for the middle, and manual entry with attestation for the smallest, with the evidence quality of each visibly different on the record.

The second break is rate schedules. Rates come from your compact, your local agreements and the applicable published rate references, and they differ by resource class, by jurisdiction and sometimes by event declaration status. Systems that resolve rates against the billing date rather than the deployment dates produce invoices that are wrong every time a schedule changes between the event and the settlement. Store schedules as versioned data with effective dates and resolve against deployment dates, always.

The third break is credentialing sources. Qualification, medical, licensure and vehicle inspection status live in other agencies' systems and change constantly. An integration that caches status without an expiry will happily certify a person whose qualification lapsed in March. Treat every credential as a dated assertion with an expiry, and surface staleness rather than hiding it behind a green tick.

What happens when the deployment clock is not modelled properly?

Mobilisation begins when the sending jurisdiction is authorised to move, not when the request was made. Travel time is treated differently from operational time in most agreements. Operational periods are defined by the incident rather than by calendar days. Demobilisation and return travel are usually claimable. Rest periods may or may not be.

Every one of those boundaries is a place where two honest jurisdictions can differ by thousands of dollars per resource per day, and a system that records only a start date and an end date cannot adjudicate any of them. Worse, it invites both parties to compute the difference their own way, which is the situation you already have.

The single most valuable record in the whole system costs almost nothing to capture: arrival and departure timestamps recorded by the receiving jurisdiction at a physical check in point. Somebody is already standing at the staging area with a device. Those two timestamps, captured independently rather than reported by the sender, are the most persuasive evidence in any later dispute and they make every other line in the reimbursement package stronger.

The related failure is undocumented demobilisation. A team goes home after three days without telling anyone, and the home jurisdiction keeps accruing costs it will later invoice. A check out record at the same physical point closes that gap, and an alert on resources with no activity for a defined period catches the ones who left without checking out.

Should you build custom or configure what you already own?

A single county that receives aid occasionally and never coordinates it should not build. Your job is disciplined records of what arrived, when, what it did and when it left, and existing tools plus a good check in procedure will do that properly. The same applies if your mutual aid activity is a handful of movements a year between two agencies that settle informally.

The interstate compact's own operations system is the required path for state to state requests and it does that job competently. Keep using it for what it covers. What it does not cover is the intrastate movement that makes up the overwhelming majority of any real event: county to county, region to region, special district to city.

Juvare WebEOC is entrenched for good reasons and many states have configured its resource boards heavily. As a communication surface it earns its place. The limit is that a board shows a request rather than enforcing a state machine, so it will not stop the same resource being committed twice by two coordinators working in parallel, and it does not carry a resource from acceptance through arrival, operational periods, demobilisation and invoice as one object with one clock. Veoci is more flexible and will let you build closer to that shape, at the cost of building inside their abstraction and meeting friction when you reach into credentialing and financial systems.

Build when you administer a compact or a regional agreement, when a single event generates enough deployed resources that phone allocation breaks down, when reimbursement disputes routinely run past a quarter, or when you cannot answer mid event which resources are committed and which remain available.

How do hidden costs get into the quote?

A first release covering the request and offer workflow with a shared state machine, resource registration with typing claims, acceptance binding and the check in and check out record runs 70,000 to 150,000 dollars over 12 to 18 weeks in Digital Heroes delivery experience. The full platform adding credentialing verification, the versioned rate engine, the reimbursement package generator with evidence assembly, dispute handling and payroll, fleet and financial integrations runs 180,000 to 400,000 dollars over 7 to 12 months. Two costs are specific to this category and both are routinely missed.

Multi party visibility is the first. This is not one agency's system. It is an instrument several independent jurisdictions rely on, which raises the bar on access control, on amendment history and on what one party may and may not see about another. Designing that access model properly is real architecture, and retrofitting it after the first jurisdiction objects to what a neighbour can see is painful and expensive.

Jurisdiction onboarding is the second and it dwarfs the first in elapsed time. Eighty participating jurisdictions means eighty conversations about resource registration, typing verification, credential sources and who holds the account. That is programme work, not software work, and it needs its own owner, its own budget line and its own schedule. Projects that treat it as training discover in month eight that the system is technically finished and operationally empty.

What separates a mutual aid build that works from one that fails?

Ask a developer to draw the state machine for a deployed resource on a whiteboard, from request through return. If the states are open and closed, they are building a ticketing system and your financial arguments will be unchanged. The right answer distinguishes offered from accepted, authorised from departed, and arrived from assigned, because those distinctions are where the money sits.

Ask how two jurisdictions see the same record without either being able to quietly alter the other's view. Listen for amendment history with an author and a timestamp rather than for edit permissions. Those are different answers and only one survives a dispute.

Ask how they version rate schedules and what they resolve against. Deployment dates, not billing dates, and if that distinction has to be explained to them it will cost you on the first schedule revision.

Ask what they have integrated on the payroll and fleet side, and how they handle participants who cannot integrate at all, because a design that assumes universal connection will strand your smaller jurisdictions.

Then settle ownership before kickoff, and be specific about the multi party case. The administering authority should own the code and the platform, and each participating jurisdiction should have a documented right to export its own data at any time. At Digital Heroes the client owns the code from the first commit. Before scoping anything, run one exercise: take your last event, pick five deployed resources, and reconstruct their full timeline from what you hold today. Where the reconstruction fails is your specification, and it will be more specific than any requirements document.