Candidate workflows that separate what anyone may ask from what only a verified account holder may change, and fit the systems you already run.
Utility service has two halves that look alike in the inbox and are nothing alike in risk. “Why is my bill so high?” is an explanation; “change my payment details” is an account change. Many contacts also arrive while the platform estate is moving: a billing system upgrade, a new CRM, a portal customers use less than hoped.
The workflows below keep the two halves apart and fit the AI to the systems and ownership you actually have, rather than assuming one integration or one regulatory model fits every utility and region. Nothing on this page is regulatory advice. Typewise agents read and write in connected CRM, ERP and ITSM systems, sensitive actions wait for approval, hand-offs carry the full context, and every action is logged. Whether any workflow below can run end to end in your organisation depends on what your systems expose and on the data behind them, so each is presented as a candidate design to evaluate, with what it needs, not as a promised capability.
Candidate design
Answer questions anyone may ask: tariffs, processes, how to apply for a connection, what a notification means, without touching an account.
What it needs from your systems
Approved public information sources with an owner who keeps them current.
What stays with people
Public answers never include account data; the boundary is enforced in the systems that serve the data.
Candidate design
Explain a verified customer’s consumption and charges from billing data, in plain language, before it becomes a dispute.
What it needs from your systems
Read access to billing and consumption data for an authenticated customer, confirmed for your specific billing product and version.
What stays with people
Adjustments, goodwill and payment arrangements follow your policy and your approvers.
Candidate design
Handle the changes you grant, such as updating contact or payment details, for a customer verified by your systems.
What it needs from your systems
Authentication that your systems perform before any account action; a write path for each change in scope, tested with the correct parameters; a rule for emails that mix a supported change with an unsupported request.
What stays with people
Authentication comes first, always; the unsupported part of a mixed request is routed to a person.
Candidate design
Explain status and options for customers who paid late or received a reminder, which are among the more standard contacts a utility receives.
What it needs from your systems
Payment status data for an authenticated customer and your dunning policy in a form the AI can apply.
What stays with people
Collection decisions and exceptions stay with your team.
Candidate design
Support installers, inspectors and business customers with process information and request intake, which is a different audience from households.
What it needs from your systems
Process information per request type and an intake destination the responsible engineers work in.
What stays with people
Technical approvals and connection decisions stay with the responsible engineers.
Agents read and write only in the systems and scopes you connect. Sensitive actions wait for approval, hand-offs carry the full context, and every action is logged. Hosting, access control and certifications are described on the security page.
Security and compliance →See how it works →A channel that cannot answer the question adds an unresolved contact. Confirm the data and actions behind the first workflow before launch; a connector tested with the wrong parameters is not ready.
Let the business owner judge value and IT judge fit with the technology strategy, with a shared rubric so neither decides alone.
Decide which instruction and task changes your service team may make without a developer, and which integration development and data-access repairs stay with IT. Write the boundary down.
Adoption dashboards that show features staff cannot access invite justified challenges. Keep reporting aligned with the actual rollout, and do not confuse inferred sentiment with surveyed satisfaction.
In a candidate design, only for a customer verified by your systems, and only for the changes you grant after evaluation. Identity verification is a readiness gate before any account-changing design; the AI never acts on an asserted identity.
You may be able to start with general information and explanation workflows that do not depend on the changing system, and keep account changes for after the migration. Map platform ownership first so the first workflow is not blocked by a system in transition.
Integrations are confirmed per product and version during evaluation, not assumed from a vendor name; many billing products exist under one brand. The data-readiness check at the start of a project establishes what can be read and written.
Book a demo and we’ll separate information from account changes and walk through these candidate workflows against your billing, CRM and portal landscape.
