Disaster Case Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope collapse into a case tracker so often?

Most of these projects begin with the sentence "we need to get off the spreadsheet". That framing is the failure. A spreadsheet replacement gets scoped as intake, case notes, document upload and a status field, all of which are easy to describe in a requirements workshop. The duplication of benefits arithmetic, the part that determines whether an award is lawful, is harder to describe, so it becomes phase two. Phase two rarely arrives with the same funding attention, and the recovery group ends up with a prettier tracker sitting next to the same award workbook it had before.

This happens in disaster recovery specifically because the people writing the requirements are case managers, and case managers experience the pain as paperwork rather than as arithmetic. The committee experiences it as arithmetic, but the committee meets for two hours a week and is rarely in the room when scope is set.

The fix is to invert the build order. The first release should be the household record, verified loss by damage component, the assistance ledger with categorised line items, and the duplication engine. Notes and documents hang off that. If a proposal puts the engine after the case management screens, ask what the committee will use in month four, and be honest about the answer. The engine is the product. Everything else is a container for it.

What goes wrong migrating paper case files and award histories?

A long term recovery group that has been running for eight months has hundreds of case folders, each containing a federal inspection summary, a contractor estimate, photographs, an insurance letter and a case narrative. The instinct is to scan and attach the lot. That produces a searchable archive and no usable data, because none of the awards are categorised and none of the loss figures are structured.

The specific trap here is that the duplication engine cannot work on migrated cases unless the assistance ledger is populated retrospectively, which means somebody reads every file and enters source, programme, category, amount, date and status for each award. At ten to twenty minutes a case that is a real project, and it is the single most underestimated line in these builds.

Decide the migration policy explicitly rather than by default. A workable split is full structured entry for every case still open or expected to reach committee, documents attached only for cases already closed, and a flag on the household record showing which treatment it received so nobody later mistakes an unstructured legacy case for a verified one. Where a legacy case returns to committee, it goes through structured entry first. That rule prevents the quiet situation where the engine produces a confident figure from an incomplete ledger.

Why do partner agency and funder integrations break after launch?

The integrations that matter here are rarely technical. They are consent. A faith based partner agrees at the outset to share award data, then their board reviews the agreement, and six weeks after launch the partner turns off everything except a name match. A state programme changes its reporting template. A funder starts asking for a breakdown by damage component that nobody captured.

Systems break at this point because they were built assuming a fixed sharing arrangement. Access was implemented as roles, consent was recorded in a memorandum of understanding rather than in the database, and the reporting was hard coded to one funder's template.

Build the sharing model as data instead. Consent is recorded per organisation, per information category, with a start date and an expiry, and it is enforced when the record is read rather than at login. A partner that narrows its sharing becomes a configuration change made by your programme manager, not a development ticket. Funder reporting should be built from the same structured fields the engine uses, so a new template is a mapping exercise. And treat the Coordinated Assistance Network as a source you check rather than a system you sync with, because knowing another relief agency is already working with a family is useful even when they will not share the detail.

What happens when duplication and retention are not properly covered?

Two gaps produce almost all the pain in this category. The first is category blindness. A system that stores one total assistance figure per household cannot tell you that a personal property award does not offset a subfloor, or that an approved loan the household declined is treated differently from one they accepted. Committees using such a system either freeze, sending cases back for verification while a family lives in a damaged house, or approve and hope.

The second is retention. A community development block grant disaster recovery award can be reviewed long after the programme closes, and the recovery group that made the award may have formally dissolved by then. If the calculation was reproducible only inside a running application, and the application was switched off when the grant ended, the evidence is gone.

Cover both deliberately. Every award produces an immutable decision package holding the verified loss by component, the assistance line items offset against it, the resulting unmet need, the rule version applied and the committee decision, exported in a format readable without the software. Conditional approvals need the same treatment, because an award that activates eight months later when a state programme denies an application must show the condition, the trigger and the date. Agree at the outset who holds that archive if the organisation winds up.

Should you build custom or configure what you already own?

Configure if you are a single agency handling under roughly 200 households, distributing your own philanthropic funds, with no committee spanning multiple organisations. CaseWorthy and Apricot by Bonterra are capable configurable case management platforms, and with a disciplined award ledger maintained beside them a diligent programme manager will hold that volume comfortably. At that scale the money is better spent on case managers than on software, and we tell organisations this regularly.

The honest limit of configuration is the arithmetic. Neither product models verified loss by damage component, categorised assistance and the offset between them as native concepts, so you will maintain that logic yourself in a workbook. A workbook is fine when one person owns it and the total funds moved are modest. It stops being fine when a nine person committee drawn from six organisations relies on it, or when a funder with formal duplication requirements asks how a specific award was calculated.

Build when two or more apply: you are moving over roughly $3M of unmet needs funding, your committee spans several organisations needing different views of the same household, you administer federal disaster recovery funds, or your cases will run three to five years across full staff turnover. If none of those are true, configure and revisit after the next event.

How do hidden costs get into the quote?

Four items are routinely priced at zero and are never zero. Legacy file migration, discussed above, which is measured in staff hours rather than developer hours and belongs in the budget as its own line with a named owner. Funder specific reporting, because a programme carrying several funding sources needs several report formats and each one has to be reconciled to the same underlying figures. Partner onboarding, which is a consent design conversation with each organisation before it is any technical work, and which takes calendar weeks that no engineering estimate captures. And offline intake, because early intake happens in shelters and neighbourhoods without power, and a system that assumes connectivity needs rework the first time it is used in the field.

There is also a timing cost that quotes never show. Building during an active response costs more than building in a calm period, both in fees and in the quality of the requirements, because the people who know how the committee works are busy running it. Recovery organisations that pre position even a lean intake and ledger take structured data from day four instead of collecting a thousand paper forms they spend six months transcribing.

Ask for these four to be priced explicitly, with assumptions written down. A proposal that omits them is not cheaper, it is less finished.

What separates a build that works from one that fails here?

The working builds share three habits. They treat the duplication engine as the first deliverable and prove it against ten real historical cases before anything else is designed, which surfaces the category mismatches that documents alone would never reveal. They record consent, retention and archive ownership in the contract at kickoff rather than at handover, because the entity commissioning the system may not exist when the review arrives. And they make the calculation visible to the committee in the room, showing which awards were offset against which losses, because a figure the committee cannot interrogate is a figure they will not trust and will check by hand.

The failing builds share one: they optimise for the case manager's daily experience and treat the committee as a reporting audience. That produces a system everyone likes using and nobody can defend when a funder asks how $18,400 was reached.

Two practical guards. Insist on a data export from the first release, in a documented format, tested by someone outside the project. And require that every rule change is versioned with an effective date, so a decision made in March can be reproduced under March's rules rather than under today's. Both cost very little to build early and are close to impossible to retrofit once several hundred awards depend on them.