Disaster Debris Monitoring Software Problems: The 7 That Get Load Tickets Disallowed, and How to Avoid Them

Why does a debris project get scoped as a form builder so often?

Because the visible problem looks like data collection. Monitors are writing on carbon copies in the rain, so somebody proposes a mobile form, and a mobile form is cheap, quick and genuinely better than paper. Esri ArcGIS Field Maps is the usual instinct and it is a reasonable one. It is excellent at putting a form and a map in a field worker's hands, it works offline, and it syncs.

What it is not is a reimbursement system. It has no concept of a truck's certified capacity, so it cannot reject a load percentage against that capacity. It has no hauler contract rate model. It has no ticket sequence integrity when hundreds of devices are issuing identifiers independently. And it has no reconciliation between what monitors recorded and what the hauler invoiced. You end up with a clean table of observations and still assemble the grant package by hand, which is where the cost and the risk actually live.

The way to prevent this at scoping is to describe the output rather than the input. Tell the developer the deliverable is an audit package for any ticket, any project, any date range, generated rather than compiled, and ask them to work backwards from that. If the design that comes back does not include a truck certification record, a rate model and a nightly three way reconciliation, you have bought a form builder with better styling.

What goes wrong when three hundred devices create tickets offline for four days?

After a major storm the network in the affected area may be down for days rather than merely patchy, and this is the requirement most developers underestimate because most field apps only need to survive a weak signal.

Three things break. First, identifier collisions. If ticket numbers are assigned centrally, devices cannot issue them offline, and if devices assign them locally without a scheme, two monitors in two towers will produce the same number. That single defect can invalidate a day of tickets, because a duplicate ticket number is exactly the anomaly an auditor is looking for.

Second, sync conflicts. A supervisor corrects a ticket on one device while the original device is still offline, and on reconnect the system has to decide which version stands. If it overwrites, you have lost the original, and preserving originals is the entire point of the system.

Third, storage and battery. Photographs are the strongest evidence you capture, and four days of unsynced photographs on a device with no reliable power is a real constraint, not a theoretical one.

What to require: a locally issued identifier scheme that stays unique across hundreds of devices, append only records so a correction is a new record with an author and a reason rather than an edit in place, defined conflict resolution, and a tested answer on photo storage and power. Test this with a developer before hiring them, not during an activation.

Why does the hauler and disposal site reconciliation break after launch?

Because reconciliation depends on data the system does not own, and the arrangements around that data change from event to event.

• The hauler's format. Every hauler reports loads differently, some by spreadsheet, some by their own dispatch system, some by fax equivalent, and a new activation frequently means a new hauler and a new format.
• Disposal site throughput. Site managers count in their own way, and a site that opened mid event may not be in your configuration at all.
• Timing. Hauler records arrive on a different cadence than monitor tickets, so a naive comparison shows differences that are just latency, and people stop trusting the report within a week.
• Contract rates. Rate structures differ by jurisdiction, by debris category and sometimes by pass, and a rate that was entered once at mobilisation goes stale when a task order changes.

The design that holds up makes the comparison a nightly report with tolerance for arrival lag, assigns every discrepancy to a named person with a deadline of the next operational period, and keeps rate tables as versioned data with effective dates rather than configuration somebody typed. Resolving a dispute while the driver, the monitor and the site manager are all still on the job is a five minute conversation. Resolving it in month three is a contract dispute the jurisdiction pays for.

What happens when right of entry and category eligibility are not enforced?

These are the two gaps that produce the largest disallowances, and both are usually implemented as warnings rather than rules.

Private property debris removal generally requires a right of entry and its own documentation showing the work was eligible and authorised, on top of everything a right of way ticket needs. If the system merely warns a monitor that a parcel has no right of entry on file, that warning gets dismissed on the fourth day of twelve hour shifts, and the ticket exists. The correct design refuses to create the ticket, enforced against parcel boundaries rather than against a monitor's memory.

Category coding is the second. Vegetative debris, construction and demolition debris, hazardous trees, hanging limbs, stumps, white goods, electronic waste and hazardous household waste are treated differently, and some are measured by unit rather than by volume. A stump has a diameter that determines how it is paid, and a diameter recalled later is worthless. The fix is to scope the category list to the current project and the current pass so irrelevant options are not offered, and to require the measurement and a photograph at capture for anything measured by unit.

Neither of these is difficult engineering. They fail because they were specified as guidance.

Should you build custom or configure what you already own?

Do not build if you are a small municipality that clears storm debris with your own crews in a week and has never pursued a large reimbursement. Your exposure does not justify the project, and Field Maps with a disciplined paper backup is a defensible answer at that scale.

Do not build if your standby monitoring contractor already brings a system they own and operate, provided you have read the contract closely enough to know you receive the raw ticket records rather than a report, and that you keep access after the contract ends. That is a real and reasonable buy, and the contract language is the whole of the diligence.

Where a configured form tool genuinely stops is checkable in an afternoon. Ask it to reject a load percentage against a certified capacity. Ask it to flag the same truck placard recorded at two sites at the same time. Ask it to produce this week's hauler invoice variance. If it cannot do those three, it is collecting observations, and getting paid for observations requires the certification model, the rate application, the reconciliation and the audit package. Those are the parts nobody sells you.

How do hidden costs get into the quote?

Four places, and each is worth a direct question.

• Parcel and right of way data. Quality varies enormously between jurisdictions and sometimes the boundary data has to be assembled before the system can enforce anything. Ask whether that sits inside the number.
• Concurrent jurisdictions. A monitoring firm activating in four counties runs four rate structures and four sets of eligible boundaries at once. A quote written for one is not a quote for four.
• Scale under activation. A system that works with twenty monitors and fails at four hundred is worse than paper. Load testing at activation scale is real work and it is routinely omitted.
• Training and device logistics. Temporary monitors are hired days before deployment. Somebody has to build the training, provision the devices and support them at 6am, and that is an operational cost the software quote never mentions.

The thing that reduces cost most is timing. Every dollar of this is cheaper in blue sky than during an activation.

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

The builds that succeed are designed to be believed by a stranger years later. That means append only records where a correction is a new entry carrying who, when and why, and the original preserved alongside it. Anything that edits in place is disqualifying in a system whose entire purpose is evidence, and it is the single clearest test of whether a developer has understood the brief.

They also make the ticket fast. A scan and three taps, under thirty seconds, offline, with a photograph attached. The truck is identified by scanning the placard rather than typed, which pulls its certification, capacity and hauler automatically. If capture is slower than the clipboard it replaced, monitors revert to paper under pressure and the whole investment evaporates.

They surface anomalies while there is still time to act. Conflicting simultaneous tickets flagged as devices sync, and load percentage distributions per truck and per driver computed continuously so outliers reach a supervisor on day three rather than in a post event analysis. None of that requires accusing anyone of anything.

And they are deployed before the event, with a tabletop exercise run using real monitors. A system delivered mid activation will not be adopted no matter how good it is. Settle code, data and hosting ownership in the contract before kickoff as well. At Digital Heroes that is yours from the first commit, and here it matters twice over, because a jurisdiction that does not own the raw ticket data cannot defend its own grant.