Website Chatbot for Energy & Utilities (2026)

Because most utility website visits are simple and repetitive - a billing question, a request to start service at a new address, a check on whether an outage is already known - and routing every one of those through a phone queue wastes the customer's time and the call center's capacity. A chatbot handles the high-volume, low-complexity requests instantly and reserves the phone line for what actually needs a person.

Page context matters directly here: a widget on /outages should open by pointing straight to the live outage map and asking for an address to check, not with a general greeting. A widget on /billing can go straight into payment or billing-question routing. The one place this pattern changes completely is anything describing danger - that gets the same urgent response regardless of which page it started on.

The honest limit: the bot handles account and information requests. It is never the right channel for reporting an active safety hazard, and the flow has to make that unmistakably clear from the first message.

Keep the automated scope to account, billing and general information:

• Start, stop or transfer service. Collecting the address, date and account details needed to process the request.
• Billing questions. Explaining a bill, payment options, due dates, and routing payment-dispute questions to a person.
• Outage status checks. Directing to the live outage map by address, and explaining what "reported" versus "confirmed" status means - not estimating a restoration time the bot can't verify.
• Rate plan explanations, in general terms. What's included in a time-of-use plan versus a flat rate, without recommending one for the customer's specific usage.
• Assistance program information. What a low-income or hardship program covers and how to apply - capturing interest and routing to the team that reviews applications.
• Appointment scheduling for a meter installation, inspection, or non-emergency service visit.

Every one of these is administrative. None of them involves telling a customer what to do about a safety hazard - that's handled entirely differently.

The bot should stop the normal flow immediately and give one instruction: call the emergency number, right now, and step away from the area if it's a downed line. Nothing else. Not troubleshooting steps, not a request for more details, not a form to fill in first.

This has to be triggered on keywords - "smell gas," "downed line," "sparking," "fire" - and it has to work identically no matter which page the conversation started on, whether that's the billing page or the outage map. A customer describing danger while trying to report an outage should get the emergency instruction before anything about outage status.

Get this wrong in either direction and the cost is high: a bot that tries to be helpful with safety guidance risks giving instructions that are wrong for the specific situation, and a bot that's too slow to recognize the keywords delays a customer from calling the number that actually gets a crew dispatched. The safest version of this flow says as little as possible and points to the phone number as fast as possible.

Because most utility customers browsing the website aren't logged into an account portal for a simple question, and the conversation only exists while the tab is open. Someone checking whether an outage in their neighborhood is already reported, or asking a quick billing question on their phone while waiting for something else, will lose the thread entirely if they get interrupted and close the tab - there's no ticket number, no way to pick it back up.

For anything beyond a pure information lookup - a service transfer request, an assistance-program application, a billing dispute - capturing an account number or phone number partway through means the request survives even if the visitor doesn't finish the conversation. Ask for it once the request moves from a general question to something that needs to be processed, not at the very first message.

On mobile, where the widget goes full screen, this is common during actual outage events - customers checking status from a phone, often on battery power, need the flow to be fast enough to finish before the phone dies or they lose signal.

Very selectively, and the outage page is the one place proactive prompting has an obvious, low-risk use: a trigger that appears as soon as someone lands on /outages, offering to check status by address, saves a step rather than interrupting anything. On billing or general information pages, an aggressive prompt is more likely to feel like a distraction from someone who just wants to find a number on the page.

The broader trade-off still applies here: turning up exit-intent or scroll-depth triggers site-wide increases chat volume without necessarily increasing resolved requests, and during an actual widespread outage event a flood of low-value chat-opens can compete for the same support capacity that's needed for genuine account issues. Utilities generally get the most value scoping proactive prompts narrowly to the outage page and leaving the rest of the site to open on demand.

Beyond the emergency-line rule, there are two more limits worth stating plainly.

• No safety or outage-emergency instructions. This is the constraint that overrides everything else on this page - the bot directs to the emergency line and stops, it does not attempt to guide a customer through a hazardous situation itself.
• No eligibility determinations for assistance programs. Whether a household qualifies for a low-income or hardship program depends on income, household size and program-specific criteria the bot isn't positioned to verify - capture interest and route the application to the team that reviews it.
• No restoration-time promises the system can't confirm. An estimated restoration time should come from the actual outage-management system, not a guess generated in conversation, since a wrong estimate erodes trust exactly when customers need it most.

Review the emergency-trigger keyword list regularly - language customers use to describe a hazard varies, and this is not a section to leave on default settings indefinitely.

Beyond the immediate emergency-line instruction, route to a person when:

1. A billing dispute or payment issue needs account-specific judgement the bot doesn't have.
2. An assistance-program application is ready to be reviewed.
3. A customer explicitly asks for a person, available at every step.

The handover should carry the account or address information already gathered, so the customer doesn't have to repeat it to a representative. On Conferbot this lands in a shared agent inbox with the full transcript attached - see human handoff for how that transfer should be designed. During a widespread outage, stating expected response times honestly - even if that means "high volume right now" - keeps customers from assuming they've been ignored.

1. Build the emergency-keyword trigger first, before any other flow, and test it thoroughly - this is the highest-stakes piece of the entire setup.
2. Map the widget to page context so /outages opens straight into a status check and /billing opens into account questions.
3. Build billing and service-request flows from a template in the template library, then push submissions to your billing and service systems over webhook.
4. Pipe live status from the outage-management system in over webhook so restoration information shown is real, not estimated by the bot - there's no native OMS integration, so a utility's own systems team wires this side.
5. Scope proactive triggers to the outage page and keep other pages on demand.
6. Pilot during a planned maintenance window before relying on it through an actual unplanned outage event.

Should a utility chatbot give instructions during a gas leak or downed line?

No. The moment a customer describes a gas smell, a downed line, sparking or fire, the bot should stop its normal flow and give a single instruction: call the emergency number immediately, and step away from the area if it's a downed line. It should not attempt troubleshooting steps or ask for more details first - speed to the emergency number matters more than anything else here.

Can a chatbot tell a customer their power will be restored by a specific time?

Only if that estimate comes directly from the utility's actual outage-management system. A restoration time generated in conversation without checking the real system risks being wrong exactly when customers are most anxious for accurate information. The bot should pull and display real status data rather than estimate one itself.

Can a chatbot decide if a customer qualifies for a low-income assistance program?

No. Eligibility for assistance programs depends on income, household size and program-specific criteria the bot can't verify. It should explain what the program generally covers, capture the customer's interest and basic details, and route the application to the team that actually reviews eligibility.

How do you stop a utility customer's request from being lost?

Capture an account number or phone number once the conversation moves from a general question to an actual request - a service transfer, a billing dispute, an assistance application - rather than at the very first message. That way the request survives even if the customer gets interrupted and closes the tab before finishing.

Should a utility chatbot pop up automatically on the outage page?

Yes, that's one of the few places an automatic prompt clearly helps - offering to check status by address as soon as someone lands on the outage page saves a step. On billing or general information pages, an early prompt is more likely to feel like a distraction than a help, and utilities generally see better results keeping those pages on demand.

How much does a website chatbot cost for a utility company?

Conferbot plans start free for 600 conversations a month, then $19, $39 and $59 a month, with the website widget included. A utility piloting billing and service-request flows, with the outage-page integration connected separately, typically evaluates cost against call-center volume reduction before a wider rollout.