Utilities
Meter reading week stops blocking the line.
An energy supplier has three days a month when the line is permanently busy, and a good share of those calls are a number being read out. The rest of the month the same line carries billing questions and outage reports, which have nothing in common and nothing like the same urgency.
The assistant takes meter readings with the customer code confirmed and the digits read back, answers billing questions from your own documents, takes outage reports and passes them to the dispatch desk, and hands anything about the contract or money to an operator.
What rings on the customer line
A supplier has a predictable peak and a constant background. Automating the peak is the part that is felt immediately.
A meter reading
The customer code, the reading dictated and read back, and confirmation that it was recorded.
Billing questions
What a line means, when it is due, how to read the bill. From the documents you publish.
An outage report
The address and what is happening, passed straight to dispatch. This is not a call that waits in a queue.
The status of a request
If you expose an endpoint, it can read it. Otherwise it takes the question and hands it on.
Contract changes
Recognised and passed to an operator, because something gets signed there.
How a reading is taken by phone
The reading is the best-defined call in a utility and it has exactly one real difficulty: digits dictated over a phone are misheard, and a wrong digit means a wrong bill.
- 01 Ask for the customer code Read back digit by digit for confirmation. Without that confirmation the rest of the call is a guess.
- 02 Check it in your system Through an HTTP tool written over your API, the assistant confirms the consumption point exists and, if you want, states the previous reading.
- 03 Take the reading and read it back The digits repeated in full and confirmation asked for explicitly. This is the one part of the flow that cannot be shortened.
- 04 Sanity-check it If your system returns the previous reading, the assistant can flag a value lower than the last one and ask for confirmation instead of recording it silently.
- 05 Record and confirm It submits the reading through a second tool, says it was recorded, and sends an SMS confirmation if you want the customer to hold a trail.
What reaches your system
For a supplier the written trail is not a convenience, it is the evidence when a bill is disputed.
| The reading | Submitted through your tool, with the customer code, the value and the time, exactly as from any other channel. |
|---|---|
| The outage ticket | Opened in Zendesk or Freshdesk with the address and description, plus a message to dispatch. |
| The confirmation to the customer | An SMS through Twilio with the recorded value, which settles half the later disputes on its own. |
| On the call record | The transcript and the recording, which for a supplier is precisely the document asked for when somebody disputes what they dictated. |
What it does not do for a supplier
A utility supplier is regulated, and this product takes over none of the regulated part.
- It does not take bill payments It processes no payments on the phone in any form, and does not confirm a payment already made.
- No link to your billing system There is no connector for any utility billing system. Everything about a customer account reaches the call through an HTTP tool you write, or an MCP server.
- It does not identify the caller strongly enough A customer code read out over the phone is not authentication. For personal data or account operations you need a verification you build, or a human operator.
- It does not change or end contracts It signs nothing and accepts no request that has contractual effect.
- It does not replace the dispatch desk It can transfer and open a ticket, but it does not assess an outage and does not send a crew.
What suppliers ask us
How reliable is a reading dictated over the phone?
It depends almost entirely on the read-back. The assistant repeats the digits and asks for explicit confirmation, and if your system gives it the previous reading it can flag an implausible value during the call. Without a read-back, every transcriber gets digits wrong, whichever vendor it is.
What happens on the peak day?
That is really the argument: the number of simultaneous calls does not depend on how many people are at the counter, it depends on your telephony account. What has to be said honestly is that we have not yet run a real peak of thousands of calls, and the status page states what has been run.
Can it say what I owe?
Technically, if you give it a tool that returns the amount. Practically it is worth thinking about twice: a customer code read out over the phone identifies nobody, and an amount told to the wrong person is a data protection problem rather than a product bug.
Are the calls recorded?
If you switch recording on, yes, and recordings can be written straight into your own storage with a configured retention period. The announcement the caller hears is written by you, because the legal requirement is yours. The recordings and storage guide describes the mechanism.
Where to go next
Telephony
Numbers, trunks, dial plan, queues, operators and campaigns, in one system.
Tools and MCP
Discovery, per-tool permissions, per-server namespacing, and a tool of your own.
Integrations
25 business connectors, 18 selectable providers, eight storage destinations.
Pricing
Components at their published price, the platform on top, and what we cannot price yet.
Notes
-
1
The tools named on this page are the ones in
App\Services\Integrations\ConnectorRegistrycarryingimplemented. Anything that is only in the catalogue, without that flag, is not named here as though it worked. - 2 The link to a billing system is your own HTTP tool, with a JSON schema and versioning, or an MCP server. No connector in the registry covers utility billing.