Voxistry
Sign inPlan a pilotBook a demo

Network operators and retail energy

AI worker teams for outage and service operations

Utilities run in two modes — steady state and incident — and the contact centre is judged almost entirely on the second. Design for the incident and the steady state comes free.

Discuss our sectorWhere to start
NETWORK OPERATORS AND RETAIL ENERGYCONSTRAINT ENVELOPE4 sector constraints designed to firstHUMAN AUTHORITY — NEVER AUTOMATED· Dispatch and crew allocation· All safety decisions· Prioritisation during major e…ACTS WITH APPROVALThresholds and gates on anything with cost or risk attachedACTS WITHIN POLICY4 blueprints start hereAutonomy widens outward only on evidence from the recordearned autonomy
The authority boundary we design to in Energy & utilities — autonomy widens outward from the centre, and only on evidence.

Our view

Where we think the real opportunity is

Most contact-centre planning optimises the average day. In utilities the average day is not the problem: an incident multiplies volume within minutes, every caller wants the same three facts, and the callers who genuinely need priority handling are buried behind the ones who only want a status update. That is a queue-composition problem, and it is exactly what a conversational layer solves — not by being clever, but by absorbing the identical questions at unlimited concurrency so the hazard report and the medically dependent customer reach a person immediately. The corollary is uncomfortable and worth stating: if the automation cannot be trusted to recognise a gas leak, it should not be deployed at all. So hazard triage is not a phase-two feature here. It is the first thing built and the thing the pilot is judged on.

Operating reality

How demand actually behaves here

Volume has a shape, and the shape is what breaks teams. This is what we assume about your operation before we design anything.

  • Incident volume arrives faster than people can be redeployed

    By the time staff are moved onto phones, the queue is already unmanageable and the abandonment rate has done its damage.

  • Nearly every caller wants the same three facts

    Am I affected, why, and when will it be back. The uniformity of the demand is what makes it absorbable — and what makes inconsistent answers so damaging.

  • Priority customers are indistinguishable in a queue

    A medically dependent customer and a routine status enquiry occupy the same position, so priority depends on someone reaching the front and explaining themselves.

  • Incident communications are reportable

    What you told customers, and when, is subject to regulatory scrutiny after a major event, which makes the communication log an operational deliverable rather than a nicety.

Where the hours go

The cost we would try to move first

Almost every operation spends its most expensive time on its least valuable work. Naming that precisely is what makes a pilot measurable rather than impressive.

  • Standing capacity held for incident risk

    Carrying headcount against events that may not happen is expensive; not carrying it is a service failure when they do. Neither option is good, which is why surge capacity that is not headcount changes the calculus.

  • Inconsistent restoration estimates

    Two customers on the same street receiving different times generates repeat calls, complaints, and a credibility loss that outlasts the incident.

  • Hazard reports queued behind status calls

    This is the most expensive queue-composition failure in the sector, and its cost is not financial.

  • Post-event reconciliation

    Reconstructing who was told what, from call notes, after a major incident, is slow manual work performed under regulatory deadline.

The trust envelope

What constrains the design, and what never gets automated

We design to the boundary first. A control added after launch is a control nobody believes — and in this sector the boundary is not negotiable.

Sector constraints

  • Unconditional emergency routing

    Gas, electrical, fire, and injury language must bypass self-service immediately, with no path, target, or intent match capable of overriding it.

  • A single source for estimates

    Restoration times may only be repeated from the incident record. No worker computes, interpolates, or softens one.

  • Priority service obligations

    Registers of vulnerable and medically dependent customers carry duties, and those flags must drive automatic prioritisation rather than requiring the customer to advocate for themselves.

  • Auditable incident communications

    Every message and call during an event needs to be logged against the incident in a form that survives regulatory review.

Stays human, permanently

These are structural boundaries, not trust levels waiting to be relaxed.

  • Dispatch and crew allocation

    Committing field resources during an incident is an operational judgement with safety implications, made in the control room.

  • All safety decisions

    Isolation, evacuation, and make-safe decisions belong to qualified staff, and the worker's role ends at getting them the report.

  • Prioritisation during major events

    When resources are scarce, deciding who is restored first is an accountable human decision, not an optimisation.

Where to start

Sequencing matters more than scope

The first blueprint should be the one whose success criteria your team already agrees on. Each step below links to the blueprint that implements it.

  1. Start

    Steady-state status, hazard triage live from day one

    Handle location-based status questions during normal operations. Hazard triage is enabled immediately — it is the control the whole deployment rests on, not a later feature.

    Read the blueprint

  2. Then

    Proactive notification on incident-record change

    Push updates when the incident record changes. This is what removes the second and third contact from every affected customer, and it compounds during an event.

    Read the blueprint

  3. Next

    Rehearse a surge, then adopt as standing capacity

    Run a scripted incident scenario, measure priority latency from hazard signal to responsible team against your target, and only then rely on the blueprint as surge cover. Billing and arrears follow using the same governance.

    Read the blueprint

Systems we would expect to read and write

  • Outage management system
  • Customer information system and billing
  • Field service management
  • Mass notification gateway
  • Priority service register

Blueprints that apply

4 operating blueprints for Energy & utilities

Each one carries the full team, process, and control detail — the mechanics this page deliberately does not repeat.

Push back on this

Objections we actually hear in Energy & utilities

Answered as we would answer them in the room, including the cases where the right answer is that this is not for you.

A missed gas leak would be catastrophic. Why would we risk it?
You should not risk it, and if hazard triage cannot be validated to your satisfaction the honest answer is not to deploy. What we would put in front of your safety team is this: hazard recognition runs on every turn as a mandatory, non-overridable escalation, priority latency is instrumented and reviewed, and the rehearsal scenario has to pass before the blueprint is relied on for surge. Compare that against the current position, where a hazard report waits in a queue behind status calls during exactly the events that generate hazards.
Our restoration estimates change constantly, so any answer we give is wrong.
That is an argument for proactive notification rather than against automation. The workers repeat only what the incident record currently says, and when it changes, affected customers are told without anyone placing a call. Inconsistency today comes from humans working from stale information; a single source and automatic re-notification is a direct fix.
Our incident volumes are unpredictable — how do we size this?
You do not size it, which is the point. Concurrency is not headcount, so the same configuration handles a quiet Tuesday and a regional storm. What does need sizing is your human escalation capacity for hazards and priority customers, because the blueprint will surface those faster than your current queue does.

Other sectors

How the argument changes elsewhere

Next step

Argue with this in a working session.

Bring your own numbers. We will map your version of the operating reality, agree what must stay human, and scope the first blueprint against a measurable win — or tell you it is not worth doing yet.

Discuss our sectorAll industries