Utility Crew Callout and Dispatch Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the rules engine get hard coded to the current agreement?

It happens because the requirements document is written from today's contract. Somebody transcribes the callout article, a developer reads it as a specification, and the ordering logic gets built into the code that walks the roster. It works, it demonstrates well, and it is obsolete at the next round of bargaining.

The reason this is uniquely damaging in utilities is that your contract is the specification and it is yours alone. Whether equalisation counts 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 becomes a no answer. Whether an employee on vacation is charged. Whether the list is ordered by district first or classification first. What happens when a district list is exhausted. Whether a supervisor can skip the list in a genuine emergency, and what documentation that requires. Every one of those is a clause with a grievance attached, and two locals inside the same utility can answer them differently.

The fix is architectural and you can insist on it before signing. Model the callout list as an ordered query over the roster with pluggable criteria, meaning classification, district, accumulator value, availability status and qualification set, then express your clauses as configuration on top. Hand three of your strangest clauses to any prospective developer and ask them to show you how the engine expresses them. If the demonstration involves changing code, you are buying a system that expires when your agreement does.

What goes wrong with roster and overtime accumulator data?

The rules engine is only as good as the roster underneath it, and the roster is the part nobody scopes properly. It has to know classification, district, qualifications and certifications with expiry dates, standby status, leave, restricted duty, and the accumulated overtime figure that determines position on the list. Most of that lives in a human resources (HR) system that was never designed to answer a question at 11pm.

Two failures recur. The first is staleness: a nightly feed means an employee who went on leave this morning gets called tonight, or an apprentice who topped out last week is still ordered as an apprentice. The second is the accumulator itself. Hours flow from payroll, payroll closes on its own cycle, and the number the dispatcher sees during a storm can be a fortnight behind the number that will be used to judge the callout afterwards. That gap is where grievances are born, because the list was correct against the data available and wrong against the data of record.

Fix it by deciding explicitly which system owns each field and writing it down. Take roster attributes from human resources on a frequent feed with a change log, but compute and hold the accumulator in the callout system itself, incrementing it from callout events as they happen and reconciling to payroll on a schedule with a variance report. Then freeze the accumulator value used in every callout alongside the event, so the question later is not what the number is now but what it was at 11.04pm.

Why do telephony and outage management integrations break after launch?

Callout depends on a telephone network during precisely the conditions that degrade telephone networks. Regional storms take down cell sites, carriers throttle, and voice paths that were reliable in testing behave differently when a hundred simultaneous calls go out to one exchange. A system that assumes the provider is up is worse than a phone tree, because the dispatcher trusts it and stops dialling.

The prevention is multi channel from the start, with voice, text message and application push all instrumented, every attempt recorded with the channel it used, and a retry queue that survives a provider being unavailable for twenty minutes. Voice matters more than people expect. At 2am a ringing phone wakes someone and a push notification does not, so voice degrading gracefully is not a nice extra.

The outage management integration breaks differently. It usually works, then a vendor upgrade changes an interface, or the crew count the system requests turns out to be derived from predicted devices rather than confirmed ones and starts asking for crews that are not needed. Because outage platforms from Schneider, Oracle, GE and Survalent each expose different interfaces with different operational sensitivity, this is real engineering per utility rather than a connector you switch on. Nightly contract tests against each endpoint, alerting a named person, turn a vendor upgrade into a Tuesday morning ticket rather than a discovery made at hour three of an event.

What happens when mutual assistance and fatigue tracking are left out?

Almost every callout project scopes the roster and the phone calls and defers mutual assistance to phase two. Then fifty trucks arrive on a Sunday from three states away and the system that just cost you six figures has nothing to say about them.

The costs of running that on whiteboards land later and they are specific. Assignments given verbally that nobody recorded, so crews sit idle for hours when their guide is reassigned. Qualifications and clearances tracked on a printed sheet. And an invoice reconciliation weeks afterwards where a contractor's hours match nothing you can verify. If your storm costs go into a regulatory cost recovery filing, that reconciliation is the difference between recovering the money and absorbing it.

Fatigue is the other deferred item and it is the one with a safety consequence. Hours worked and rest taken per employee has to be visible in the storm room while decisions are being made, not reconstructed in March. Where crews operate commercial vehicles, hours of service rules and the utility service vehicle provisions apply, and emergency declarations can change what is permitted during a restoration. Your safety and legal teams make those determinations. The system's job is to hold real numbers so the determination is made from data rather than from a guess.

The fix is to scope both as thin slices in release one rather than as full modules later: incoming crew records with qualifications and a daily time capture, and an hours-worked counter with a threshold alert. Both are small. Both are unrecoverable if the storm arrives first.

Should you build custom or configure what you already own?

If your contract language fits a product's rules model reasonably well and what you need is reliable automated callout with a defensible log, buy ARCOS. It is the established product in this exact category, it does callout, roster rules, crew manager and mutual assistance, and there is no prize for building what you can buy. Configure it properly, integrate it once, and spend the difference on line crews.

If you already run Clevest for field mobility and switching, keep it there. Union callout is not its centre of gravity and it complements rather than replaces this workflow. If you are mid way through an IFS deployment across the utility, look at what its scheduling can express before opening a separate project, because an enterprise platform you are already implementing is a cheaper place to configure rules than a new one is to buy.

Build when the signals stack up: multiple bargaining units with genuinely different callout language, grievance settlements you cannot defend, mutual assistance running entirely on whiteboards, storm cost filings reconstructed after the fact, or dispatchers who already work around the tool you bought. That last one is decisive. Once dispatchers work around the system during a storm, it has stopped being the record.

How do hidden costs get into the quote?

Bargaining units are the largest and the least visible. A quote written against one agreement prices one rule set. Two locals with materially different language is close to two engines, because the test surface doubles and every ambiguity has to be resolved twice with two sets of stewards. Ask for the price per additional agreement in writing.

Telephony reliability engineering is the second. Multi channel delivery, retry queues, failover between providers and a load profile that assumes four hundred simultaneous contacts is work that does not appear in a demo and does not appear in a thin proposal either.

After that: integration with human resources and payroll, which is rarely as simple as a roster export; each outage management platform interface; and the storm-mode load testing that proves the system behaves when it is finally needed. Watch also for the go-live date. A launch scheduled inside your storm season quietly imports a large contingency into the project, because nobody will accept the risk and the date will move.

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

Ask one question first: how would you answer a grievance filed six months after a storm. If the reply 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.

Then ask what happens when the telephony provider degrades during a regional event. You want fallback channels and queued retries described in concrete terms, not reassurance about uptime.

Then check the operating model. Build for one bargaining unit and one district's storm process first, prove it in a real event, and expand from there. Plan the go live for the quietest month you have, and run the old process alongside the new one through the first event rather than betting the storm on a cutover.

Finally, settle ownership in writing before kickoff, covering the repository, the database and the cloud accounts. Callout logs are labour relations evidence and storm cost data supports regulatory filings, so neither can sit in an environment you do not control. A concrete next step: pull the last three grievances you settled, and ask a candidate developer to show you exactly which fields their system would have captured that would have changed the outcome.