Utility contact volume is close to flat until it is not. A storm, a substation fault, or a widespread outage produces the sharpest demand curve in any customer-facing industry, and unlike retail peaks it arrives with no notice at all.
The instinct is to treat this as a capacity problem, and capacity is part of it. But the utilities that handle outages well have solved a design problem first. They have decided what each type of call is, where it goes, and what an agent may say on it. Capacity added on top of a bad design makes the bad design bigger.
Three contact types, one queue
Outage events generate three kinds of contact. Reports of a loss of supply. Requests for a restoration estimate. And safety reports: a downed line, a gas odour, sparking or damaged equipment. These are not equivalent, and routing them identically is the most consequential design mistake available in this sector.
The first two are customer service. They can be answered by an agent with a screen, a script, and access to what your operational system currently shows. The third is not customer service at all. It is a hazard report that happens to have arrived on a customer service line, and the person making it may be in danger.
Routing them apart does not require three phone numbers. It requires the agent to identify the type within the first exchange and follow a different path for each. The opening script does that work: it asks whether anyone is in danger before it asks for an account number.
A safety report is not a customer service contact. It needs its own path and its own urgency.
Safety reports: one job, no judgement
An agent taking a report of a downed line or a gas smell should have one job: capture the location precisely, give the caller the scripted safety instruction, and escalate immediately through a route that is staffed at full queue depth, not only when things are calm. There is no version of this where agent judgement improves the outcome. The script is the safeguard.
The script has to be equally clear about what the line is not. An outsourced outage line, or any customer service line, never replaces the emergency services. A caller who describes an immediate danger to life, a fire, an injury, or a live wire in contact with a person or a vehicle is told to hang up and call the emergency number, and the agent then escalates the report on your side as well. Our agents are trained to say this plainly and early, because a caller in that situation should not spend another minute on hold with us.
Build this path first and test it at volume. A safety escalation route that works when the queue is quiet and fails when it is deep has not been tested.
Supply reports: capture and confirm
A report that the power is off is useful to you as data and useful to the customer as reassurance that someone knows. The agent's job is to confirm the address against the account, log the report into your outage system so that it contributes to the fault picture, and tell the caller what happens next. If your system already shows a known outage at that address, the agent says so. If it does not, the report may be the first signal of a new fault, and that is worth capturing precisely.
Customers on medical equipment or otherwise registered as vulnerable need their own handling rule. The agent should be able to see the flag, follow the instruction you have written for it, and route the contact to whoever manages priority restoration on your side. That decision stays with you. The agent's part is to recognise the flag and follow the path without delay.
Where you have an automated outage line or an outage map, agents should know how to point callers to it for future updates, so that the second and third contacts about the same fault do not all land on a live agent.
Restoration estimates: relay, do not predict
Restoration estimates change, and an agent repeating an estimate that later slips creates a second, angrier contact. The workable approach is to relay only what the operational system currently shows, state plainly that it is an estimate, and avoid any commitment beyond it. Scripts that allow reassurance beyond the data cause more damage than a blunt statement that you do not yet know.
- Read the estimate exactly as the system shows it, with the time it was last updated.
- Say that crews update estimates as they assess damage, and that the time may move.
- Never round an estimate toward what the caller hopes to hear.
- Offer the automated line or map for updates so the caller does not need to queue again.
- Log any commitment a caller says they were given earlier, so it can be checked.
Every prediction becomes a promise
The design rule behind that list is simple. Agents relay system state; they do not forecast it. Every prediction becomes a promise in the customer's memory, and the promise is what they will quote back when the lights are still off an hour after the time they were given. A script that permits 'it should be back soon' has quietly authorised a promise nobody in operations made.
The same rule applies to causes. Unless the operational system records why the outage happened, the agent does not speculate. 'We have crews assessing the fault' is accurate and complete. A guess about a transformer or a tree is a fact the customer will repeat to a neighbour, and it may be wrong.
Volume rises as your own capacity falls
Widespread events affect staff as well as customers. Your own contact centre may be in the affected area, running on backup power, short-handed because people cannot travel, or dealing with its own outage. The value of outsourced coverage is that the agents are not in the affected area and can absorb volume while your team deals with the event itself.
That only holds if it was arranged in advance. Routing, systems access, and authority take time to establish and cannot be improvised while the event is running. When we onboard a utility programme, the project manager maps the outage process alongside the routine one, so that the same agents who handle billing and moves on a quiet day can switch to outage handling when the routing changes. The overview of disaster and emergency call centre support covers how that switch is organised.
Storms do not keep office hours, and neither does the queue. The overnight version of the outage line needs better documentation than the daytime one, because there is nobody down the corridor to ask, and it needs an escalation rule that says precisely which reports wake someone on your side and how. Agree that during scoping, not on the night.
Deflection is worth more here than anywhere
A well-maintained outage map, proactive text updates, and an accurate recorded message remove a large share of 'is it off, and when is it back' contact before it reaches a queue. Programmes that invest here first need materially less live capacity during an event, and the live capacity they do have is spent on the calls that need a person: new faults, vulnerable customers, and safety reports.
The recorded message deserves more attention than it usually gets. It should name the affected areas, give the last-updated time, state the current estimate as an estimate, and tell callers how to report a hazard. A message that is a day stale does the opposite of deflecting. It sends people into the queue to find out whether anyone is awake.
Measure the tail, not the peak
Everyone watches the spike. The number that predicts customer sentiment is how long the queue stayed high after restoration, because those are billing questions, damage claims, and complaints, and they arrive when the emergency staffing has already stood down.
The measures worth agreeing during scoping are the time from a safety report to its escalation, the share of outage contacts resolved without transfer, the accuracy of estimates relayed against what actually happened, and the length of the post-restoration tail. Reported on the rhythm agreed at the start, they tell you whether the design held, which matters more than whether the peak was survived.
Recorded calls from the event are worth more than the numbers. A sample reviewed in the week after, against the safety script, the relay-not-predict rule, and the prescribed record, shows where the design bent. Those findings go into the script and the training before the next storm, and they are the most reliable way a programme improves from one event to the next.
When outsourcing this work is the wrong move
If you do not have an operational system that agents can read in real time, outsourced agents will be relaying nothing, and callers will notice. If your safety escalation route depends on one person's mobile number, it will fail in the first serious event, whoever is answering the phone. And if you expect the outsourced line to make decisions about crew dispatch or restoration priority, you have handed over something that must stay with your operations centre.
Fix those first. When the system is readable, the escalation route is staffed, and the boundary is clear, outsourced capacity is the right answer to a demand curve nobody can staff for permanently. The energy and utilities outsourcing overview covers the wider service mix, and after-hours answering explains how overnight coverage is structured for the storms that arrive at two in the morning.