AI for customer support operations in utilities: billing, outages and vulnerable customers
A utility contact centre has a contact mix that barely changes from year to year, and a volume profile that can treble overnight. Most of the year the queue is billing, reads, payments and moves. Then a storm crosses the region on a Tuesday evening, or the temperature drops for a fortnight in January, and the same team is taking supply interruption enquiries at five times the normal rate while the billing queue keeps arriving on schedule.
Predictable intents and unpredictable volume is the honest case for automation here, and also where the hard boundaries sit: a few of those contacts are safety calls, and many more come from customers for whom a wrong answer is dangerous.
The contact mix is narrow, repetitive and evidence heavy
Water, gas, electricity and multi-utility retailers converge on the same list: billing queries, read disputes and smart meter faults, tariff switches and price change notices, payment plans and arrears, priority services register customers, outages and supply interruptions, connections and moves, and complaints carrying regulatory deadlines.
The repetition makes automation viable. The evidence requirement makes it hard. Each contact needs a specific record read correctly: the read history with its estimate flags, the tariff the customer is actually on, the state of the meter, the live incident covering that address. An agent that writes a fluent paragraph without the record produces something worse than silence, because the customer will act on it.
Billing queries and the gap between estimated and actual
This is the largest single driver in most utility operations, and the estimate sits at the centre of it. A bill built on an estimate often does look wrong, because it is wrong. Estimates also compound: a run of low ones followed by one actual read produces a catch-up charge that lands as a shock, and often as a complaint.
An agent can close much of this end to end. It can state what the bill was calculated from, which reads were estimated and which actual, the dates covered, and how standing charge and unit charge each contribute. It can accept a customer read, validate it against the register range, the previous reading and a plausible consumption rate, then trigger a rebill and show the revised figure in the same conversation.
It should stop in four places. Reads that fail plausibility. Anything implying a register rollover or a meter exchange. Balances reaching back far enough to engage a back-billing limit. And any catch-up charge large enough that the real conversation is affordability rather than arithmetic.
What a prepared handover looks like
A prepared case gives the advisor the read history with estimates flagged, the tariff in force and any change within the period, consumption against the same period a year earlier, the validation result on the customer's read, and a plain statement of what the agent could not determine. This is where most of the value sits, and it is consistently underbuilt.
Meter reads, smart meter faults and the limit of remote diagnosis
"My meter is wrong" covers several different problems: a read that failed validation, a meter that has stopped communicating, a device left in the wrong mode after a tariff or supplier change, a display disagreeing with the bill, and a genuine metering fault needing a site test.
Remote diagnosis handles most of that list. The agent can check the last successful communication, confirm the configuration on the device matches the tariff being billed, explain why a display and a bill differ, attempt a remote read, and book a site visit with the right skill attached.
What it must not do is adjudicate an accuracy dispute. Meter testing follows a defined procedure, the result can be challenged, and the outcome changes the bill retrospectively. Keep the diagnosis automated, the determination human.
Tariffs, price changes and notification waves
A price change notice creates a wave of contacts inside a narrow window, and nearly all are the same few questions in different words. What am I on now. What is it becoming. When does it take effect. Do I have an exit fee. Does this change my direct debit. An agent answers all of those from record, and can recalculate a direct debit against projected consumption while showing the working.
The boundary is recommendation. Steering a customer onto a particular tariff carries suitability obligations. Set out the options with their terms and let the customer choose, routing to an advisor where a recommendation is sought. For multi-utility retailers, answer per fuel rather than per account: gas and electricity commonly sit on different tariffs with different end dates, and a blended answer is incorrect.
Payment plans, arrears and where automation stops
The administrative end automates cleanly: changing a payment date or method, setting up a direct debit, taking a card payment, adjusting an instalment inside a policy band, explaining a balance.
Debt is a different activity. An affordability conversation is not a form to be filled in, and an arrangement set without understanding income and expenditure is one that breaks, costing more than the contact it saved. A workable rule: an agent may set an arrangement inside a pre-approved band, for an account with no vulnerability marker and no previously broken arrangement, and prepares everything else for a person. Never let an automated collections, restriction or disconnection journey run against a flagged account. That control belongs in code, not in a prompt.
Priority services and vulnerability signals
A register entry can reflect dependence on electricity for medical equipment, a sight or hearing impairment, age, serious illness, mental health, language needs, or a temporary circumstance after a bereavement or a birth.
There are two jobs. The first is honouring an existing flag across every contact, not only those about the vulnerability itself. The second is catching signals where no flag exists yet: a mention of dialysis or an oxygen concentrator, an admission about not affording heating, a third party calling on someone's behalf, distress, confusion that does not resolve.
The correct response to a signal is immediate escalation to a person. Not assessment, not reassurance, not completing the current task first. An agent that recognises a marker and stops has done its job. One that carries on is the transcript read out later.
Outages, supply interruptions and the calls that are never automated
Start with the boundary, because it is absolute. A suspected gas escape, a smell of gas, a carbon monoxide alarm, a downed or damaged power line, an exposed cable, water flooding into a property from a burst main, a fire, or any report of someone hurt goes straight to the emergency process and to a human being. Immediately, with no triage questions and no containment attempt. This is not a policy preference to be weighed against handling time. It is the point at which a misclassification injures someone.
Build it as a deterministic classifier ahead of the model, tuned so false positives are cheap and false negatives effectively impossible. The agent recognises the category, gives the standard safety instruction, and transfers. Over-triage is the acceptable error here, and a rate you should be comfortable seeing high.
The rest of the outage queue suits automation: whether a known incident affects this address, the cause, the current restoration estimate, whether compensation applies, and notification when supply returns.
Storm weeks and cold snaps
Volume multiplies overnight and headcount does not. Automation earns its place on those nights by absorbing repetitive status enquiries so advisors can work the contacts needing judgement: register customers off supply, welfare arrangements, medical equipment, access problems.
Three things have to hold. Incident data must be live, because a status answer an hour out of date is worse than none. Repeat contacts must become a callback register rather than a queue. And the system must be comfortable saying no restoration estimate exists yet, which is better than a fabricated one. Priority routing stays open throughout: a register customer off supply in a cold snap reaches a person quickly even when everything else is queued.
Connections, moves and complaints with a clock attached
Moves are transactional and largely automatable: a read on the day, a final bill, an opening balance on the new account, and who owns which period. Disputed occupancy dates, void periods, unregistered supply and landlord disagreements go to a person, because the contested part is a fact about the world rather than a fact in the system. Connections and alterations split the same way: status reads automate, commitments to dates depending on network work or third party consent do not.
Complaints carry regulatory deadlines and possible redress, which makes them a defined object rather than a bad conversation. Recognition is the weak point, because customers rarely use the word and systems routinely close complaints as resolved queries. An agent reading contacts for the markers, and raising the record with the clock started, is doing compliance work that today rests on adviser discretion. It should not investigate, decide redress, or issue a final response.
Where AI fails here
Data quality defeats the design before the model matters. If meter to address or address to network mapping is wrong, the agent will tell a customer there is no incident while their street is dark, or attribute consumption to someone else's meter. Ambiguous identity has to mean handover.
Estimation logic is often opaque even internally. An agent asked why an estimate was what it was will construct a plausible reason if allowed to. Restrict it to facts: these reads were estimated, this one was actual.
Distress is not a text classification problem. Models read obvious markers well and flat, quiet statements badly, so set the threshold to over-escalate and accept the cost.
Long histories exceed the conversation. A customer on their fifth contact about one disputed read carries a narrative no single window reconstructs, and another explanation of the billing basis is an insult.
Regulated determinations do not forgive errors. Meter accuracy findings, back-billing limits, redress decisions, complaint outcomes and anything touching disconnection stay human or read only. And major incidents are the worst case rather than the showcase: the hours when the data is least reliable carry the most contacts.
Where to start
Pick one intent with checkable ground truth: bill explanation against read history, or outage status against a live incident feed. Fix the meter and address data first. Then build the safety classifier and the vulnerability escalation path before any containment target exists, because neither improves a handling time figure and neither gets built later.
If you run a utility contact centre and want a plain view of which of these an agent should carry, describe your queue to Adopt AI Partners at hello@adoptaipartners.com.