Capture service location, account context, observed condition, affected area, accessibility, and callback while preserving emergency and restoration authority.
Last updated: June 21, 2026
Clear operating rules
These pages explain how the service is intended to be used and how customer data is handled inside VoxsAgents.
Illustrative product workflow—not a verified customer result. It does not claim a conversion, revenue, cost-saving, or performance outcome.
Callers may report loss of service, lines, odour, sparks, water, flooding, equipment damage, or medical dependence while asking when service will return. Automation can submit approved reports but cannot assess hazards or invent restoration estimates.
Original VoxsAgents research
How can an outage workflow create accurate provider evidence and urgent routing without providing safety or restoration advice?
The VoxsAgents research team decomposed this scenario into caller intent, required fields, system authority, evidence states, permissions, failure paths, and staff ownership. We reviewed the difference between caller-reported information, organization-approved rules, external provider results, and professional judgment. The model covered corrections, interrupted calls, repeated contacts, stale records, unavailable staff, rejected actions, provider timeouts, unknown outcomes, and manual reconciliation. The purpose is to produce an inspectable operating design rather than a selected success story or unsupported customer-performance claim.
Address and service-point matching need confirmation because a postal address can contain several meters, units, or services.
A submitted report, known incident match, crew assigned, estimate published, and service restored are separate states.
Medical or accessibility needs require an approved priority-support path without the agent deciding clinical severity or restoration order.
The governing evidence boundary is explicit: The agent may collect approved outage fields and use exact utility-authored emergency language; utility systems, emergency services, and qualified staff determine hazards, incidents, crew dispatch, restoration, and customer support. This prevents fluent conversational language from silently becoming authority that the underlying workflow does not possess.
Confirm service type, location, unit or service point, caller contact, observable condition, affected extent, and approved support needs.
Apply exact emergency language for configured hazards before routine outage questions.
Match current provider incidents or submit one correlated report.
Communicate only provider-returned incident and estimate information with timestamp and uncertainty.
Route accessibility, medical-equipment, account, and damage requests to authorized staff.
Do not provide hazard, repair, medical, or restoration advice.
Do not invent or reuse stale restoration estimates.
Protect account and support-need information.
Prevent duplicate outage submissions while preserving changed conditions.
Confirm service type, location, unit or service point, caller contact, observable condition, affected extent, and approved support needs. Store caller-provided values with source and confirmation state, and make critical identifiers available for read-back and correction. Fields that do not change routing, ownership, eligibility, or the next approved action should remain optional.
Apply exact emergency language for configured hazards before routine outage questions. The route must use organization-owned rules, destinations, and identifiers. Caller language and generated content must never supply arbitrary organization scope, protected status, transfer destinations, or permissions.
Match current provider incidents or submit one correlated report. Record the rule and version that selected the route so staff can explain and replay the decision after business configuration changes. Exceptions need a visible human owner rather than silent rejection.
Communicate only provider-returned incident and estimate information with timestamp and uncertainty. A requested action, submitted tool call, sent notification, and ringing destination are not completed outcomes. Persist provider identifiers and terminal status independently from the generated call summary.
Route accessibility, medical-equipment, account, and damage requests to authorized staff. Staff corrections should append an audit event and update customer-facing state without erasing the original evidence. Notifications should contain the minimum action context and link to a protected record when detail is required.
The caller describes a configured hazard.
Several service points share one address.
A stale restoration estimate remains cached.
A provider timeout leaves submission uncertain.
reports confirmed
incident matches
service-point corrections
emergency escalations
estimate corrections
Utility, emergency, safety, medical-support, account, outage, damage, and restoration procedures require provider and jurisdiction-specific approval. This is an illustrative product workflow, not an independently audited customer outcome. A real deployment must test the configured tools, permissions, jurisdictions, staffing, retention, and failure recovery before launch, then report failed, uncertain, corrected, and successful outcomes using a defined review method.
This page is original VoxsAgents workflow analysis based on product behavior, failure-path review, and the official references below. It is not an empirical customer outcome study.
Treat these steps as a test plan. Adapt the fields, routing, permissions, and failure handling to the business before launch, then review real calls for errors and unintended behavior.
Read the evidence and methodology policy for the standard required before publishing customer outcome claims.
