Voice agents for energy utilities: administrative support

Publish bounded sources

Attach documents covering channels, hours and administrative procedures. Identify update date and owner. Rules for another region or branch should not be presented as universal.

Protect personal lookups

The external service must verify identity and permission before retrieving individual requests. A spoken reference alone does not authorize account disclosure. Return only necessary status and respect authorization rejection.

Receive requests without technical promises

With a configured connection, the agent can register a request in the responsible system. Confirm a case number only after receiving confirmation that it was registered. Opening a request does not mean restoring supply, dispatching a team or automatically changing an installation.

Define exception channels

Risk, accident and technical-intervention questions are outside administrative scope. Use responsible owners’ approved routing and keep contacts current. The agent should not improvise safety instructions or assess severity.

Evaluate each request

Test outdated policies, unauthorized accounts, unavailable systems and out-of-scope topics. Check communicated next steps and delivered records. Measure correct guidance and continuity without equating an ended call with a resolved technical issue.

How should billing, interruptions and service requests differ?

General payment questions can use published guidance; account retrieval needs verification and authorized access. Reported power interruptions should preserve location and observations through the approved incident channel. Do not turn reports into confirmed technical causes.

For follow-up, explain returned states and update times. “Incident recorded” does not establish dispatched staff or restored supply. When the source is unavailable, explain that the state could not be confirmed and follow the next step defined by operations.

Distinguish account questions, interruptions, and service requests

An energy operation may receive billing questions, interruption reports, and administrative service requests. These categories require different sources and actions. A general policy explains how to request service; an individual account needs authorized lookup; a technical report needs the operation's approved procedure. The agent should not use one question sequence for every case or infer a technical cause merely from a word related to energy.

In a fictional example, someone asks where to follow a service request. Documents may explain the available channel. Another person asks about their account's current state. Access then depends on the provider's required identifier and verification. A third reports an interruption and needs the guidance approved for that category. The conversation's first objective is to identify the need without anticipating diagnosis, timing, or authorization.

Write scope in verifiable terms: explain approved procedures, query available states, and record permitted requests. Avoid broad goals such as “solve every energy problem,” which may lead to improvised technical recommendations. For reports the operation classifies as urgent, define the approved channel and message in advance. That decision belongs to the service owner rather than to the agent's improvisation during a call. The prompt should make the relevant alternative easy to identify.

Test informal language and mixed requests. “My electricity is wrong” might describe billing, local lighting, or interruption. One short question can establish what the person means. Then resolve the in-scope portion and route what needs another service. Confirm what was handled without announcing technical or financial resolution that has not happened. Classification should improve practical routing and source selection, not merely add a label to the transcript.

Explain incidents from the source without promising restoration

If incident lookup exists, the agent may explain the authorized states it returns. A recorded incident does not prove it explains every individual report; no recorded incident does not prove service is normal. Records may lack sufficient information for that location or moment. Responses should preserve this limitation, particularly when callers want a concrete prediction.

At a fictional operation, a customer reports an interruption at one site and lookup returns an open regional incident. The agent can explain available state and approved follow-up. Without a prediction in the source, do not invent a restoration time. When an approved estimate exists, explain its meaning and conditions as defined by the operation rather than converting an estimate into guaranteed individual recovery. Keep reported conditions separate from externally verified conditions.

Confirm identifiers required for lookup without collecting extra details merely because other request types use them. If the caller corrects the site, query the correct reference. A result obtained for an earlier address should not continue applying to the new case. Where information is individual, the integration needs to validate the relationship between the authorized account and the queried site.

Test missing incidents, known records, unavailable lookups, and information that has not been updated. Define permitted wording and a real next step for each scenario. Do not repeat queries without a reason just to fill waiting time or claim staff are already working at the location without evidence. The role is to communicate available information and organize reports according to procedure, preserving the distinction between a recorded incident and confirmed restoration. A calm explanation can remain useful even when the source cannot provide the deadline the customer wants.

Separate payment reports from verified account state

Someone may call about a charge they do not understand or report payment without seeing the expected update. Acknowledge the report without assuming the system confirms every fact. An authorized lookup may show available account state; approved policy may explain a review procedure. Neither source authorizes inventing a banking explanation or assigning blame to the customer.

In a fictional scenario, the account has a pending state and the caller says payment was made. Explain what was checked and what remains unconfirmed. “The lookup still shows this state; I can explain the review channel” differs from saying the person did not pay. Preserve the statement for responsible staff when recording is configured, and avoid drawing a conclusion unsupported by the response. The record should make clear which part came from the customer.

Define what is needed to locate an account and which verification permits access to individual information. Do not request complete card details, passwords, or credentials for a lookup that does not require them. If supporting documents belong in a particular channel, provide it according to approved guidance. Avoiding improvised channels keeps service consistent and prevents unnecessary circulation of documents. The agent should not ask for a receipt merely to answer a public question about payment procedures.

Test incorrect identifiers, missing accounts, reported payments, disputed charges, and unavailable APIs. Distinguish lookup, review submission, and completed review. A new reference proves only the state returned by the system. Deadlines, adjustments, and financial consequences should come from the appropriate policy or system, with routing for cases requiring individual analysis. Accuracy includes recognizing when an account result is unavailable rather than treating an unsuccessful query as evidence of a customer's financial position.

Record requests with confirmed site and intent

Administrative requests may involve changing contact information, following an existing request, or asking about a service. Each operation needs defined scope and permissions. Do not select an action merely because the caller uses a verb such as “change.” Establish what should change, confirm relevant information, and use only an existing tool intended for that purpose.

In a fictional example, someone wants to change the return-contact number, but the agent interprets the request as changing the serviced site. A recap before writing prevents the mistake: “You want to update the telephone number used to contact you about this request.” The integration should validate the account and permitted fields. Prompt guidance supports the conversation but does not replace server-side validation. Check both submitted parameters and the resulting record during tests.

Look up repeated requests when that capability exists. If a caller returns because confirmation was unclear, opening another record without checking may duplicate work. The tool should handle repetition consistently and communicate the result. If an earlier call created a request, explain the existing state without announcing that the underlying service was performed merely because a reference exists. Submission and execution belong to different stages.

Test corrected intent, changed sites, rejected operations, and pending responses. After a write, a change requires a valid modification operation; do not pretend the earlier request disappeared. Closing should state what was recorded, the returned identifier, and approved next step. If integration failed, explain the limit and real alternative. This preserves useful records and expectations consistent with the operational process. Review whether staff can understand the request without reinterpreting a vague category or guessing which corrected value the agent ultimately used.

Review accuracy, routing, and continuity

Pilot evaluation should distinguish general information, individual lookup, administrative recording, and technical reports. These tasks have different expected outcomes. A correct procedural answer may resolve a question; a recorded report still depends on staff; a lookup without sufficient information may require routing. Avoid one “resolution” rate that mixes these situations and encourages premature completion claims.

Build scenarios with located accounts, corrected identifiers, absent incidents, known interruptions, reported payments, and repeated requests. Include out-of-scope questions and situations needing the operation's specifically approved guidance. For each case, define the permitted source, available action, and expected final message. Review tool results and external records alongside transcripts. The evidence should establish what happened rather than merely whether the agent sounded helpful.

Track information corrected by people, routing to wrong destinations, duplicates, and repeat contacts caused by unclear explanations. Inspect examples behind the measures. A shorter call may have omitted necessary identification; a longer one may have correctly confirmed an ambiguous site. Improve accuracy and continuity without assuming shorter duration always means better service. Compare similar request categories so a change in case mix does not distort conclusions.

Review sources when contacts, hours, or procedures change. Test integrations when fields and system states change. If context reaches staff through a separate notification or record, verify delivery and access. A direct telephone transfer in Tigy does not automatically send history to the receiving person. Provide a real route for cases automation cannot complete. The agent contributes by organizing requests and communicating available evidence while preserving clear limits around diagnosis, authorization, timing, and service execution. Keep recurring exceptions in regression tests so later configuration changes remain aligned with those limits.