Storm Restoration and Mutual Aid: Why 400 Foreign Crews Arrive Faster Than a Spreadsheet Can Log Them

Why the first 48 hours decide what the storm costs you

Two in the morning at a county fairgrounds that became a staging site nine hours ago. Buses are arriving from three states. There are line crews, tree crews, damage assessors, wire guards, a caterer, a fuel truck, and one person from the storm room with a laptop, an Excel workbook, and a phone that has not stopped. Every arriving crew wants three things: where do we sleep, where do we work, and who is signing our hours. The workbook has a tab per utility, each with a different column order because each sister utility sent their roster their own way. Someone is retyping names at 2am so that a crew can be assigned at 6am.

Everything expensive about a storm gets decided in that window. Crews that sit idle for a shift because nobody could confirm their voltage qualifications are paid for that shift. Lodging booked in a panic costs more and puts a crew ninety minutes from their circuit, so they lose three hours a day to windshield time for a week. And the hours logged on a paper sheet at a staging site are the evidence you will use months later to recover the cost, either in a FEMA Public Assistance submission if you are a public power utility or an eligible co-op, or in a regulatory filing if you are investor owned. Neither audience accepts a spreadsheet with a formula error.

The tools in this space are real and each solves part of it. ARCOS is strongest at calling out your own represented workforce under your labor agreement rules, and ARCOS Crew Manager extends into storm logistics. Clevest and Oracle Utilities Mobile Workforce Management are built around your own configured crews doing scheduled or dispatched work. What none of them absorb cleanly is the specific shape of mutual aid: several hundred people you have never met, arriving in 48 hours, from organizations whose data you do not control, whose hours you must evidence to a standard set by somebody else.

Problem 1: rosters arrive in a dozen formats and none of them are yours

Your regional mutual assistance group activates. Within hours you have commitments from six or eight utilities and their contractors. What arrives is a spreadsheet per utility, sometimes a PDF, occasionally a photo of a printed sheet. Names spelled inconsistently. Crew composition described differently: one utility sends crews with a lead and members, another sends individuals you have to assemble. Equipment listed as free text. Nothing shares a key.

A workforce management system expects employees to exist in it before work is assigned. That assumption is fine for daily operations and useless here, because the population arrives faster than anyone can enroll it and half of it will be gone in twelve days. So the storm room falls back to Excel, which at least does not object.

What a custom build does: treat roster intake as an ingestion problem with a forgiving front door. Accept whatever arrives, spreadsheet or PDF, run a structured extraction pass over it, and produce proposed crew and personnel records for a human to confirm in bulk rather than retype. This is the one place a language model earns its keep in storm work: not chat, just turning eleven inconsistent roster formats into one schema with a review queue. Give each person and crew a durable identifier at that moment, because every downstream record for the next two weeks, assignment, lodging, hours, safety briefing attendance, hangs off it. If identity is created at check-in instead of at commitment, you spend the storm reconciling.

Problem 2: qualifications are a safety and liability question, answered on trust

A foreign crew rolls up and says they are qualified. Qualified for what, exactly. Energized work or de-energized only. What voltage class. Bucket or climbing. Do they need an escort familiar with your system, and what is your escort ratio. Are their tree crews certified for line clearance near energized conductors or are they general tree care who must stay outside minimum approach distance.

In a normal week your own crews' qualifications live in your training records and nobody thinks about it. During mutual aid it is a stack of paper handed over at a staging tent, and the person receiving it is checking people in as fast as they can. If something goes wrong on a 34.5kV circuit and the investigation asks how you verified that crew's qualifications, the honest answer at most utilities is that somebody said so at 2am.

What a custom build does: capture qualification claims at check-in against your own defined categories, attach the evidence photo or document to the person record right there on a tablet, and make assignment rules enforce it. A circuit tagged as requiring energized work qualification does not accept a crew without it. Escort assignment becomes a required field rather than an assumption. The safety briefing that every crew receives on arrival gets signed on the device, so attendance is a record and not a memory. None of this slows check-in down if it is designed as a two minute flow. It slows check-in down enormously if it is designed as a form.

Problem 3: logistics is the real constraint and it is invisible in every operations tool

Restoration speed is bounded by lodging, food, fuel and laundry far more often than by crew count. A hundred rooms in the wrong town costs you an hour each way per crew per day. Meals that arrive at the staging site at 7pm when crews come off at 9pm produce cold food and a morale problem that shows up as slower work on day five. Fuel for bucket trucks in an area where stations have no power becomes its own operation. Ice and water in the summer are safety items, not comfort items.

Workforce management products model work orders and technicians. They do not model a hotel block with a room list, a base camp with bunk assignments, a caterer's headcount that must be submitted by 3pm for the following day, or the fact that crew 14 needs their laundry back before shift. So this runs on a separate spreadsheet owned by the logistics lead, disconnected from the assignment sheet, which is why crews get moved to a different work area without anyone updating where they sleep.

What a custom build does: put lodging, meals and equipment on the same crew object as assignment, so moving a crew's work area surfaces the lodging implication immediately. Headcounts for the caterer and the camp come out of the live roster rather than yesterday's estimate. Fuel and equipment get tracked against the crew, which matters twice: once for operations and again for cost documentation, because equipment hours are billed at published rate schedules and undocumented equipment time is money you will not get back.

Problem 4: hours become money, and the evidence has to survive an audit

The paper crew sheet signed at the end of a shift is the artifact your entire cost recovery rests on. For public power utilities and eligible cooperatives, FEMA Public Assistance requires force account labor and equipment documented to a standard, with equipment reimbursed against FEMA's published Schedule of Equipment Rates or your own approved rates. For investor owned utilities, FEMA Public Assistance is generally not available, and the same evidence is instead used to defend deferred storm costs in a regulatory filing where intervenors will test it line by line.

Either way the failure mode is identical. Crew sheets are filled in at the end of an eighteen hour day by someone exhausted. Names are approximated. Equipment is described loosely. The sheets are photographed, emailed, and reassembled weeks later by an accounting team who cannot ask questions because the crew went home to Alabama. Then the contractor invoices arrive and do not match the sheets, and nobody can tell whether the difference is a real dispute or a transcription error.

What a custom build does: capture hours on a device against the crew identity created at commitment, with the assignment, the work location and the equipment already attached because the system knows them. The crew lead signs on the device at the end of shift. Contractor invoices get reconciled against those records automatically with a variance queue rather than by a person with two stacks of paper. And every record is written to an append-only log, so an auditor asking whether hours were adjusted after the fact gets a real answer rather than a promise.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape is this. A first release covering roster intake with extraction, crew check-in with qualification capture and safety briefing sign-off, assignment, and daily hour logging with signature runs $60,000 to $140,000 and ships in 10 to 16 weeks. A full platform adding lodging and meal logistics, equipment tracking at rate schedules, damage assessment intake, contractor invoice reconciliation and structured demobilization runs $180,000 to $400,000 phased over 6 to 12 months.

What drives it up: integration into your OMS so that assignments align with actual damage and restoration progress rather than being managed in parallel. Multi-jurisdiction operation, because two states means two sets of cost recovery expectations. Offline capability at staging sites and in the field, which you will need, because the communications infrastructure is part of what the storm broke. And the number of contractor arrangements you carry, since each one has its own rate structure and invoicing pattern.

What keeps it down: build for the first 72 hours and the hour trail, and leave damage assessment and ETR calculation to your OMS. The coordination problem is where the manual work is. Do not try to replace an outage management system in a storm tool.

One scheduling reality specific to this category: there is a season. A build that lands in October for an Atlantic coast utility gets exercised in an ice event at best, and the team's first real use of it will be in an actual emergency. Ship the first release before the season, then run a tabletop exercise against it with your storm room, because that exercise finds more problems than any test suite.

Build versus buy, and when buying is the right answer

Buy if your storm profile is modest. A co-op or municipal utility that receives fewer than roughly 30 foreign crews in a bad year does not need this. Standardize your roster template with your mutual assistance group, tighten your crew sheet, and put the money into vegetation and hardening where it does more good. If you already run ARCOS for callout under your labor agreement and it is working, keep it. Callout under a collective bargaining agreement is genuinely hard and ARCOS does it well.

Build when two or more of these are true. You routinely host or send several hundred foreign personnel. Your cost recovery goes to FEMA or to a commission and has been questioned before. You operate across more than one state or more than one operating company. Your staging and logistics function currently lives in one person's spreadsheet, which means it lives in one person. Or your last event produced a lessons learned document whose top three items were all coordination failures rather than field failures, which is the usual pattern and the clearest signal.

Our position: storm software is not a productivity tool, it is an evidence system that happens to help you work faster. Buy for callout, build for coordination and evidence, and be honest about which problem is actually hurting you.

How to choose a developer for storm and mutual aid systems

Ask them how they create identity for a person who has not arrived yet and may never arrive. If they start by describing a user account with a login, they are building an enterprise app for people who will never log in. Foreign crews do not get accounts, they get identifiers and a crew lead with a device.

Ask what their system does when the staging site loses connectivity, which it will. Check-in and hour capture must work offline and reconcile later. A cloud-only design fails on the day it is needed.

Ask them to describe the evidence chain for one crew's single shift from commitment to invoice reconciliation. A developer who has done this will walk it without hesitating and will mention append-only records. One who has not will describe a timesheet screen.

Ask who owns the code and get it in writing before kickoff, along with the right to export every record. At Digital Heroes the client owns the code from the first commit. Then, before you sign anything, get the storm room lead and the accounting lead in the same room with the candidate developer for an hour. Those two people disagree about what matters, and how a developer handles that disagreement tells you whether they will build the right system.