A practical guide / Fonix.AI
Utilities support: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
A utilities voice bot needs the service point and incident state
A utilities voice bot can help callers identify a known interruption, lodge an individual service fault and reach the appropriate support team. Its first operational question is whether the problem belongs to an existing area incident or needs a separate service-point investigation.
Use a Fonix.AI evaluation to connect approved incident information with a bounded support workflow. Account access, identity checks, urgent wording and escalation destinations must be configured by the utility. This guide does not offer electrical, gas or other hazard-handling instructions.
Location alone does not prove an account relationship
Resolve the service point using an approved address or reference procedure. Several meters may exist at one building, and a caller's mobile location may be unrelated to the affected property. Establish the service address without exposing another household's account details.
Retrieve the latest relevant incident version and distinguish reported, investigating, estimated restoration and resolved states. If no restoration estimate has been approved, say that the time is not yet available. Avoid converting a historical average repair duration into a current promise.
Worked example: the area is restored but one property remains out
A fictional neighbourhood incident is marked restored. A resident calls to say their property is still affected. Repeating the resolved announcement would fail the caller. The agent should capture the current observation, check whether an individual follow-up fault already exists and create or route the remaining problem through the approved process.
Do not reopen the entire area incident automatically. Preserve the relationship between the original incident and the individual report so operations can detect a wider pattern if more reports arrive. If the caller describes an immediate hazard, follow the approved urgent route without waiting for a complete account history.
| Situation | Useful response | Operational record |
|---|---|---|
| Active area incident | Current approved update | Incident ID and version |
| No matching incident | Individual fault intake | Service point and symptoms |
| Restored area, still affected | Follow-up investigation | Linked unresolved report |
| Hazard reported | Approved urgent escalation | Receiving route and outcome |
Keep updates current across channels
Attach each spoken update to its incident version. Before a delayed callback or notification, recheck whether the incident has changed or closed. An obsolete “service is down” message after restoration creates unnecessary calls and damages trust.
The support record should preserve what the caller observed, the information supplied and the receiving owner. Billing queries and restoration queries may require different permissions. A fault report should not expose payment history; a billing question should not be answered with an unrelated area announcement.
Service-point checks beyond the area incident
Use synthetic service-point records and incident updates, including restoration followed by a continuing local report. Define what can be discussed before verification and which operational team accepts individual fault escalation.
| Pilot case | Required behaviour |
|---|---|
| The area incident closes but the caller remains affected | Record an individual unresolved report linked to the incident and assign investigation. |
| Two properties share a contact number | Resolve the affected service point before reading account-specific information. |
| A repair estimate changes while a callback waits | Refresh the approved estimate and its uncertainty before speaking to the customer. |
Measure correct service-point and incident association plus accepted unresolved-fault handoffs. Track stale restoration statements and repeat contacts caused by premature closure. A broadcast restoration update is not proof that every property has recovered.
Can the agent offer troubleshooting during an outage?
Only the operational instructions approved for that service and situation. It should preserve reported observations and route hazardous or uncertain conditions under the provider's policy. It should not improvise electrical, gas or other safety advice from a caller's description.
Test freshness and unresolved exceptions
Use a service address with multiple connections, an incident changing during the call, an unknown restoration time and a fault persisting after restoration. Measure correct incident association and unresolved reports reaching an owner. Keep false reassurance and stale updates as explicit errors rather than hiding them in an overall answer rate.
Review a utility support workflow with your incident schema and approved escalation rules. Outage notification calls cover proactive affected-cohort updates; customer-support voice bots cover broader case handling.
The telecom support example offers a related service-state test: an account's scheduled future plan must not replace its current entitlement or obscure a reported fault.