All insights

AI Agents

AI agents for utilities: the high-bill call, and the disconnection they can't own

A cold snap doubles ten thousand bills and the call center drowns in 'why is my bill so high.' An agent grounded on interval usage, weather, and the rate can answer that one well. Disconnection, a reported gas smell, and a hardship deposit are where it has to stop. Here's the split, on Energy & Utilities Cloud and Data 360.

AI agents for utilities: the high-bill call, and the disconnection they can't own, article illustration

The first cold week of the season doubles ten thousand bills at once. By Monday the call center is a wall of “why is my bill so high.”

The answer is almost always the same: it got cold, the heat ran, the rate has a winter tier. Explaining that ten thousand times is work no human should be doing, and it’s work an agent can do well, if it’s grounded on the right data.

The trap is treating a utility like a generic service desk. A retailer’s agent can improvise around a late order. A utility agent operates inside tariffs, regulator rules, and physical safety, where the cost of a confident wrong answer is a wrongful disconnection or a missed gas leak, not a refunded shipping fee.

So the design question isn’t “can an agent handle utility calls.” It’s which calls, and where the agent has to stop and hand a human the decision. My split, up front: let the agent own the high-volume account and billing work, ground it hard on usage and rate data, and keep it away from disconnection, credit decisions, and anything that touches safety.

The data model is why this is a Salesforce build, not a chatbot

A utility’s data doesn’t fit a plain CRM, and that mismatch is why a bolt-on chatbot fails here. A customer isn’t one account. They’re a person with a billing account, one or more service accounts, each tied to a premises, a service point, a meter, and the interval usage that meter produces.

Salesforce Energy & Utilities Cloud models exactly that. It’s an additive extension of the core data model that adds the utility layer: customers, premises, service points, meters, assets, usage, and contracts, with the Salesforce Industries tooling to run the processes on top. An agent that answers a billing question has to read across that whole chain, from the person to the meter reading, in one turn.

That’s where Data 360 earns its place. Interval usage, weather, outage events, and payment history rarely live in one system. Data 360 unifies them onto the customer so the agent grounds on one profile instead of stitching four systems mid-conversation.

Grounding quality is the whole game, the same lesson every production agent learns. An agent reasoning over stale or partial data gives a fluent answer that’s wrong, which in a regulated industry is worse than no answer.

The high-bill call, done properly

The high-bill inquiry is the single highest-volume, most-automatable call a utility gets. Most deflection attempts do it badly, reciting a generic “check for drafts” script. An agent grounded on the account can do the thing a good human agent does: compare this bill to the same month last year, point at the usage spike, and tie it to a cause.

The pattern is retrieval, then explanation. The agent pulls the current period’s interval usage, the prior year’s same period, the rate schedule, and the weather for the billing window. Then it explains: usage rose 40% over last January, the coldest week aligns with the spike, the winter tier applies above a threshold. That’s an evidence-based answer tied to the customer’s own meter, not a deflection.

It can go further inside policy. Enroll the customer in budget billing to smooth the seasonal swing, set up autopay, start a payment arrangement that fits the rules, or send the usage breakdown to the account email. These are bounded, reversible actions with clear eligibility, which is the shape of work to automate first.

What it must not do is invent the cause. If the usage data doesn’t explain the bill, the agent says the numbers don’t add up and escalates, rather than guessing at a faulty meter or a billing error it can’t verify. A high bill caused by a metering fault is a real event with a real remediation process. An agent that hand-waves it into “seasonal usage” has done harm.

Move-in, move-out, and the rest of the account queue

Start of service, stop of service, and transfer are high-volume, form-shaped, and seasonal, which makes them good agent work. A customer moving house needs to stop service at the old premises and start it at the new one on specific dates.

The agent collects the addresses, confirms the service points, checks date availability, and schedules the field visit where a physical connect or disconnect is needed, handing that to Field Service for the actual dispatch.

Outage handling splits cleanly by scale. For a single-premises outage, the agent confirms whether it’s known, checks for a local event, and either reports it or files the trouble ticket.

During a major storm, the job is proactive status and honesty: tell the customer their area is affected and give the restoration estimate the outage system provides. The agent must not invent an ETA. “Crews are working, no estimate yet” is a true answer; a fabricated “power back by 6pm” is a broken promise at scale, and it reads worse than silence.

Program enrollment rounds it out: paperless billing, budget billing, autopay, renewable or community-solar programs, efficiency rebates. Bounded, eligibility-driven, reversible. The agent qualifies and enrolls, and where a program has a hard eligibility test it can’t confirm, it collects the request and routes it.

Where the agent stops, and why the line is not negotiable

Some calls look routine and carry consequences that make them human decisions. In utilities the boundary is sharper than in most industries, because the wrong side of it is regulated, unsafe, or both. This is human-in-the-loop as a hard requirement, not a nicety.

Safety comes first and is absolute. A customer reporting a gas smell, a downed line, or a burning outlet gets one behavior: route to the emergency path immediately, with the standard “leave the building and call the emergency line” guidance, and no attempt to triage. An agent that tries to diagnose a gas leak conversationally is the one failure mode that ends a program. Build that route as a top-priority path and test it adversarially before anything else ships.

Disconnection for non-payment is the second hard line. Whether and when a utility may disconnect is governed by the regulator, and in many jurisdictions protections apply to medical-necessity and vulnerable customers, with moratoriums during extreme heat or cold.

An agent can explain a past-due balance, take a payment, and set up an arrangement within policy. It does not decide to disconnect or restore, and it does not tell a customer they’re safe from disconnection, because that’s a determination with legal weight. Collections here follows the same ledger discipline as any regulated dunning process.

Credit, deposits, and hardship are the third. A deposit waiver, a hardship or medical-hold designation, a payment plan outside standard terms: these are judgment calls with compliance exposure. The agent assembles the case, the human decides. Same for a dispute the usage data doesn’t resolve, and for any rate eligibility that carries a final determination.

The pattern across all three is that the agent triages and prepares, and a person decides. Guardrails enforce it: scope the topics so the agent can’t take the disconnection or waiver action at all, and make escalation carry the full account context so the human isn’t starting from a blank screen.

What to build first

Don’t boil the ocean. The highest-return first agent is billing and account service: high-bill explanation grounded on usage and rate, move-in and move-out, program enrollment, payment arrangements within policy. It’s the biggest slice of the queue, the work is bounded, and the data to ground it is data you already have if Data 360 is unifying it.

Get the grounding right before you widen scope. An agent that explains a bill from the customer’s own meter data builds trust; one that recites a generic script or guesses at a cause erodes it. Then extend into outage communication and field-visit scheduling, and leave disconnection, safety, and credit decisions where they belong, with a person who can be held accountable for them.

The cold-snap Monday doesn’t have to be a wall of identical calls. Most of them have the same true answer, and an agent grounded on the right data can give it ten thousand times, while your people work the calls that need a human.

Understanding the basics

What can an AI agent do for a utility customer service team?

Grounded on unified account and usage data, an agent can explain a high bill against the customer’s own interval usage, weather, and rate; handle move-in, move-out, and transfer of service; enroll customers in budget billing, autopay, and efficiency programs; take payments and set up arrangements within policy; and give outage status. It should not decide disconnections, make credit or hardship determinations, or triage a safety report like a gas leak.

Why does a utility agent need Energy & Utilities Cloud and Data 360?

A utility customer maps to a billing account, service accounts, premises, service points, and meters, which a plain CRM doesn’t model. Energy & Utilities Cloud adds that industry data layer as an extension of the core model. Data 360 then unifies interval usage, weather, outage, and payment data onto one customer profile so the agent grounds a billing answer on complete, current data instead of stitching several systems mid-conversation.

How should a utility agent handle a reported gas leak or safety issue?

With one behavior: route to the emergency path immediately with standard safety guidance to leave the area and call the emergency line, and make no attempt to diagnose or triage. This should be a top-priority, hard-coded route in the agent’s design, scoped and tested adversarially before launch. Conversationally triaging a safety report is the failure mode that ends an agent program, so it is the first thing to build and the first thing to test.

Can an AI agent disconnect a customer for non-payment?

No, and it should be scoped so it cannot take that action. Disconnection is governed by the regulator, with protections for medical-necessity and vulnerable customers and moratoriums during extreme weather in many jurisdictions. An agent can explain a past-due balance, take a payment, and set up an arrangement within policy, but the decision to disconnect or restore, and any statement about a customer’s disconnection status, stays with a human because it carries legal weight.


Scoping a utility service agent that explains a bill from the customer’s own meter data, handles the account queue, and hands off disconnection, safety, and credit decisions to a person? Talk to us. Building agents that hold up inside tariffs, regulator rules, and physical safety is exactly the work we do.

Keep reading

All insights