Utilities & Energy
Billing, outage reporting and new connection status in Bangla, at the volume a distribution utility actually receives.
A distribution utility in Bangladesh has a contact profile unlike any other sector. On an ordinary day it is bill amount and due date, payment confirmation that has not reflected, meter readings that look wrong, new connection status and name or address changes. Then a feeder trips, and within minutes the same question arrives from thousands of subscribers in one area, all of them asking something the control room already knows the answer to. Human floors cannot be sized for that, and an IVR that only takes a message makes it worse by converting a flood of questions into a backlog of tickets your field teams have to close manually. The engine we deploy answers the ordinary day from your billing system, and on a fault day it leads with the outage, gives the restoration window from your own feed, and stops generating duplicate tickets for something already dispatched.
The problem before the product.
One fault, thousands of identical calls
An area outage produces a contact spike of the same question, at the exact moment the control room and the field teams are busiest. Every one of those calls is answerable from data you already hold.
Duplicate tickets for a fault already dispatched
When each caller gets a ticket, a single feeder fault becomes hundreds of records your team closes by hand, which buries the genuinely separate faults underneath them.
Billing disputes start as a phone call
A bill that looks wrong is the most common non-outage contact there is. Without a live read of the billing record and the meter history, the answer is always a callback.
New connection status has no self-service path
An application moves through several internal stages that the applicant cannot see, so they call repeatedly to ask where it is, and each call interrupts the process they are asking about.
Prepaid meters generate their own call pattern
Recharge failures, token entry problems and emergency balance questions arrive constantly and are almost entirely procedural.
Built against your
systems of record.
Outage-first answering
When a fault is active for the caller's area, the engine leads with it: what is affected, that it is known, and the restoration window from your outage management or NOC feed. It attaches the caller to the existing incident instead of raising a new ticket.
Billing answers read from the billing system
Current bill, due date, last payment received, arrears and meter reading history, read at the moment of the call after verification. Where a reading genuinely looks anomalous, it raises a billing investigation with the right data already attached.
Fault reporting with structured capture
For a fault not yet known, a consistent intake: location, nature, since when, whether neighbours are affected, and a callback number. The ticket reaches dispatch complete rather than as a free-text note.
Connection and application status
Application stage, what is outstanding, and what the applicant needs to provide next, read from your connection workflow so the answer is current.
Proactive outbound
Planned shutdown notice to the affected area, restoration confirmation, bill due and disconnection warning reminders, with consent state and quiet hours enforced.
Your systems stay yours.
Nothing here is a replacement platform. The engine reads from and writes to what you already run.
- Billing and revenue management systems
- Outage management and SCADA or NOC feeds
- Meter data management, including prepaid vending
- New connection and application workflow systems
- Existing PBX, contact centre and IVR
- bKash, Nagad and bank gateways for bill payment links
What it will not do.
The constraints are the product. A system that cannot be audited cannot be approved.
- Deployable on-premise or in your own tenancy, which matters for utilities operating under government or regulator oversight.
- Subscriber PII masked before any prompt leaves your boundary.
- Bill figures and meter readings are read from the system of record, never estimated by the model.
- Outage and restoration statements come from your operational feed, so the engine never promises a restoration time the control room has not given.
- Append-only recording and transcripts, retention set by you, with consent carried on outbound notices.
Why this sector
works differently here.
The regulators, the systems and the operating reality that decide whether a deployment in this sector actually survives contact with your environment.
Distribution is zoned and mostly state-linked
Electricity distribution is split across utilities serving defined areas, such as DESCO and DPDC in Dhaka, with gas and water run by their own authorities. Procurement is government-shaped, which means longer cycles and a harder requirement to show that the system runs on your own infrastructure.
Prepaid metering created a new call pattern
The rollout of prepaid electricity meters moved a large population onto tokens, vending and emergency balance. Those calls are procedural, constant and almost perfectly suited to a self-service Bangla line.
Load shedding makes volume non-linear
Supply interruption here is not a rare incident, it is a recurring operational reality. Contact volume is therefore spiky by nature, and an outage-aware line is the difference between absorbing a spike and being buried by it.
One fault, one incident, not a thousand tickets
The single biggest operational win is attaching callers to an incident the control room already has, rather than raising a ticket per caller. That requires a live outage feed, and whether you have one determines most of the value on this page.
Bills are paid over MFS and agent points
Utility bill payment through bKash, Nagad and agent networks is routine, so confirming an amount and sending a link completes the task rather than ending it at a counter visit.
The first build, in about 30 days.
Outage-first answering for one distribution zone, plus bill amount, due date and payment status from the billing system.
- Area-level outage lookup from your outage or NOC feed
- Attaching callers to an existing incident instead of new tickets
- Bill, due date, last payment and arrears from billing
- Structured fault intake for faults not yet known
- Bill payment links over bKash or Nagad
Scoping everything at once is how these projects fail. These come after the first build is answering real calls.
- New connection and application status
- Prepaid vending and token support
- Meter reading dispute investigation
- Planned shutdown outbound notification
If three of these are true, book the diagnostic.
A single area fault reliably overwhelms your hotline.
Your team closes large numbers of duplicate tickets for one incident.
Bill disputes always end in a callback rather than an answer.
Applicants call repeatedly for connection status you could expose.
Prepaid recharge problems take up a material share of your contacts.
What happens if our outage feed is not integrable?
Then the engine cannot be outage-aware, and we would tell you that before scoping rather than after. It would still handle billing, connection status and fault intake, but the biggest single win on this list depends on that feed.
Can it tell a caller when power will be back?
Only what your control room has published. It reads the restoration window from your feed and says so. It will not generate an estimate, because a wrong restoration time is worse than none.
Can it take a bill payment?
It confirms the amount and sends a payment link through bKash, Nagad or your bank gateway. It does not capture card or account credentials by voice.
A diagnostic, then a written scope.
Forty-five minutes on your call mix and your systems. You get the findings in writing inside 72 hours, and they are yours whether or not we work together.