Utility Crew Callout and Storm Dispatch Software: How Do You Call Out 400 Line Workers Without Breaking the Contract?

Hour three of a storm, and the dispatcher is dialling

Wind hits at 9pm. The outage management system starts lighting up. By 11pm you need four more line crews and two service crews, and the way you get them is a dispatcher with a printed roster and a desk phone.

She is not just calling people. She is calling them in a specific order that the collective agreement dictates, usually lowest accumulated overtime first within the correct classification and the correct geographic district. She logs each attempt: answered, declined, no answer, unavailable. A decline still counts as an offer for equalisation purposes in most contracts, which means the log matters as much as the outcome. She has to build crews that meet composition rules, because a journeyman cannot work alone and there are ratio requirements for apprentices. And she is doing this while the phone rings with damage reports and a supervisor asks for an estimated restoration time for a hospital feeder.

Two weeks later, the grievance arrives. An employee says he was skipped. Your defence is a paper log with times written in pen. You settle, because you cannot prove otherwise, and the settlement is paid at the overtime rate for the hours he did not work. That happens several times a year at most utilities and everyone treats it as the cost of doing business.

The contract is the specification, and it is yours alone

This is the reason generic workforce software struggles here. Callout is not scheduling. It is a rules engine whose rules were negotiated at a bargaining table and rewritten at the last one.

Consider what varies between utilities, and sometimes between locals inside the same utility. Whether equalisation is by hours offered or hours worked. Whether the accumulator resets annually or rolls. Whether a no answer counts the same as a decline. How long the phone rings before it is a no answer. Whether an employee on vacation is charged. Whether the list is by district first or classification first. What happens when the district list is exhausted and you go to a neighbouring district. Whether a supervisor can skip the list in a genuine emergency and what documentation that requires. How crews must be composed by classification and how apprentices count. Whether standby employees are called before the list.

Every one of those is a clause with a grievance attached. A vendor product handles the common shapes and then asks you to adapt, and where the contract will not adapt, your dispatchers work around the system. Once dispatchers work around the system during a storm, the system stops being the record, and you are back to defending a paper log.

Mutual assistance is the second system nobody built

When the storm is bigger than your own workforce, crews arrive from other utilities and from contractors through mutual assistance arrangements. Fifty trucks show up on a Sunday from three states away. Now you need to know who they are, what their qualifications are, which of your circuits they are cleared to work, where they are staging, where they are sleeping, where they are eating, who their bird dog is, and what rate each contractor is billing.

Most utilities run this on spreadsheets and a room full of whiteboards, and it works because people work eighteen hour days to make it work. The costs of that improvisation land later: assignments given verbally that nobody recorded, crews idle for three hours because their guide was reassigned, and an invoice reconciliation weeks afterwards where the contractor's hours do not match anything you can verify. If your storm costs are being submitted for regulatory cost recovery, that reconciliation is not administrative, it is the difference between recovering the money and eating it.

Where ARCOS, Clevest and IFS actually sit

• ARCOS is the established product in this exact category and it is the honest first thing to evaluate. It does automated callout, roster rules, crew manager and mutual assistance, and it is used across a lot of the industry. The recurring limitation we hear from operations directors is contract nuance: the rules engine covers the common patterns, and where your local's language does not map, you get a workaround or a manual step. Integration into your outage management and mobile workforce systems is per utility work regardless of vendor.
• Clevest, now inside the Schneider portfolio, is strong at field mobility and switching workflows for utilities. Callout under union rules is not its centre of gravity, so it tends to be a complement rather than an answer.
• IFS is a capable enterprise field service and asset management platform with genuinely good scheduling optimisation. It is also an enterprise programme, and union callout rules become configuration inside a much larger implementation. If you are already deploying IFS across the utility, look at it. If you are not, this is a large door to open for one problem.

The build case is narrow and specific: your contract language is unusual enough that a product cannot express it, your grievance history proves the current process is failing, and you need the callout record joined to outage, restoration and cost data that already lives in your own systems.

What a custom callout and storm system has to include

The rules engine comes first and it has to be configurable without a code change, because your contract will be renegotiated inside the life of this system. Model the list as an ordered query over the roster with pluggable criteria: classification, district, accumulator value, availability status, qualification set. Every callout event stores the list as it stood at that moment, frozen, so a grievance six months later is answered by replaying the exact roster and rules that applied that night. That single design choice is what makes the system worth building.

Contact has to be multi channel and simultaneous where the contract allows it. Voice call with keypad response, text message, and a mobile app push, with every attempt timestamped and every response recorded including the channel it came through. Voice matters more than people expect: at 2am a phone call wakes someone and a push notification does not. Twilio or a similar carrier grade provider is the usual foundation, and the system must handle the case where the telephony provider itself is degraded during a regional event.

Crew assembly then works from responses. The system builds valid crews against composition rules, flags a crew that cannot legally roll, and assigns equipment. A dispatcher should be approving suggestions, not solving a constraint problem in her head at midnight.

Outage management integration is what turns callout into restoration. Predicted outage devices and affected customer counts from the outage management system drive how many crews you need and where, assignments flow back with the job, and restoration progress updates without a radio call. Estimated restoration times published to customers and to the regulator become defensible because they are derived from actual crew assignment and progress rather than from an educated guess on a whiteboard.

Mutual assistance deserves its own module: crew rosters from the assisting utility or contractor, qualifications and clearances, staging assignments, lodging and meals, a guide assignment, daily time capture, and contractor rate application. Get the time capture right at the source and the invoice reconciliation stops being a six week argument.

Fatigue and rest tracking matters both for safety and for defensibility. Hours worked and rest taken per employee, visible to the storm room, with alerts before someone crosses your policy threshold. Where crews drive commercial vehicles, hours of service rules and the utility service vehicle provisions apply, and emergency declarations can change what is permitted during a restoration event. Your legal and safety teams own those determinations; the system's job is to hold the data so the determination can be made with real numbers rather than a guess.

Finally, cost capture. Labour by employee and rate, contractor hours, equipment, materials, lodging and meals, all tagged to the event from the moment it starts. If you file for storm cost recovery, this data assembled in real time is worth substantially more than the same data reconstructed in March.

Cost, timeline and what moves the number

A first release with the roster and accumulator model, the configurable rules engine, multi channel automated callout with full attempt logging, and crew assembly runs $70,000 to $140,000 over 12 to 16 weeks. The full platform adding outage management integration, mutual assistance management, restoration and estimated restoration time tracking, fatigue tracking and storm cost capture runs $180,000 to $400,000 phased over 8 to 12 months.

What raises cost: the number of bargaining units, because each contract is its own rule set and two locals with different language is nearly two engines. Integration depth with your outage management system, whether that is a Schneider, Oracle, GE or Survalent platform, since each has its own interface and its own operational sensitivity. Telephony reliability engineering, because a callout system that fails during a regional event is worse than no system. And integration to your human resources (HR) and payroll systems for roster truth and for pay, which is rarely as simple as it sounds.

What lowers it: build for one bargaining unit and one district's storm process first, prove it in a real event, then expand. Do not attempt a company wide launch during storm season, and plan your go live for the quietest month you have.

When you should buy instead

Buy ARCOS if your contract language fits its model reasonably well and your main need is reliable automated callout with a defensible log. That is a real product solving a real problem and there is no prize for building what you can buy.

Do not build anything if you run a small municipal or cooperative utility with a few dozen field staff. The rules complexity is low and the dispatcher knows everyone by name.

Build when you have multiple bargaining units with genuinely different callout language, when you are paying grievance settlements you cannot defend, when mutual assistance coordination runs entirely on whiteboards, when your storm cost recovery filings are reconstructed after the fact, or when your dispatchers already work around the tool you bought.

How to choose a developer

Ask them how they would answer a grievance filed six months after a storm. If the answer does not involve replaying the frozen list and rule set as they stood that night, the system will not defend you and you will keep settling.

Give them three of the strangest clauses in your contract and ask them to describe how the rules engine expresses them. This is the fastest way to find out whether you are talking to someone who will build a configurable engine or someone who will hard code your current agreement and disappear before the next negotiation.

Ask what happens when the telephony provider degrades in a regional event. You want to hear about fallback channels and queued retries, not an assumption that the API will be up.

Ask who owns the code, the database and the cloud accounts, in writing, before kickoff. Callout logs are labour relations evidence and storm cost data supports regulatory filings, so neither can live in a vendor account you do not control. At Digital Heroes the client owns the repository from the first commit. A concrete next step: send us the callout and overtime articles from your two most complex agreements, and we will tell you within a week what the rules engine has to be able to express.