Telecom
Subscriber-scale Bangla voice and chat on one brain, for the repetitive layer that dominates an operator's contact volume.
Telecom contact volume in Bangladesh is extreme in quantity and narrow in variety. Balance and validity checks, pack activation and deactivation, data usage, recharge issues, SIM replacement, FNF and migration questions, coverage and outage reports. The distribution is so top-heavy that a small number of intents account for most of the traffic, which makes the sector the clearest case for automation in the country, and also the least forgiving, because an error does not affect one customer but a cohort. We deploy the same Bangla brain across the voice line and the digital channels so a subscriber gets the same answer whichever one they use, grounded in your business support systems.
The problem before the product.
Volume that no floor can be sized for
Staffing for peak is uneconomic and staffing for average guarantees queues during exactly the events, outages and campaign launches, when contact spikes.
The same ten questions, in four language registers
Bangla, English, romanised Bangla and regional speech patterns all arrive on the same line, usually mixed, and usually carrying a digit string that has to be heard exactly.
Channel answers drift apart
When the voice line, the app chat and Facebook are each served by different teams or different tooling, the same question gets different answers, and the inconsistency itself generates more contacts.
Outage events overwhelm everything at once
A regional outage converts into a contact flood of identical questions, at the precise moment agents are least able to absorb it.
Built against your
systems of record.
One brain across voice and digital
The hotline, app chat, website and social channels answer from the same engine and the same knowledge, so the answer does not depend on where the subscriber asked.
Grounded account answers
Balance, validity, active packs, data usage and recharge history are read from your BSS at call time. The engine states what the system holds, or says it cannot reach it.
Self-service actions, not just answers
Pack activation and deactivation, recharge guidance and request raising executed against your systems with confirmation, rather than being read out as instructions.
Outage-aware responses
When an outage is active for a subscriber's area, the engine leads with that, gives the expected restoration window from your NOC feed, and stops generating tickets that your field teams already know about.
Proactive outbound
Recharge and validity reminders, pack renewal, migration and campaign outreach, 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.
- BSS, billing and charging systems
- CRM and ticketing
- Existing contact centre platform and IVR
- NOC and outage management feeds
- App, web, WhatsApp, Facebook and Instagram channels
- Recharge and payment gateways
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 cloud tenancy, relevant where BTRC obligations and subscriber data policy constrain where data may be processed.
- Subscriber PII masked before any prompt leaves your boundary.
- Consent state and quiet hours enforced on outbound campaigns.
- Append-only recording and transcripts across voice and digital, with retention set by you.
- Account actions are logged with the verification tier that authorised them.
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.
BTRC sets the operating constraints
The Bangladesh Telecommunication Regulatory Commission governs operators here, including obligations around subscriber data and service quality. Where subscriber data may be processed is a BTRC-shaped question, which is why on-premise or in-country deployment is usually the only approvable option.
A prepaid market behaves differently
The overwhelming majority of subscribers here are prepaid, so the dominant intents are balance, validity, recharge and pack activation rather than billing disputes. That distribution is unusually narrow, which is exactly what makes the sector automatable.
Mobile is the internet for most subscribers
Fixed broadband reaches a small share of households, so data pack behaviour, usage questions and speed complaints arrive at the same hotline as voice ones, from the same subscriber, often in the same call.
Code-switching is the default register
Pack names and technical terms arrive in English, the complaint around them in Bangla, and the digits in either. Handling that inside one utterance is a baseline requirement here, not a refinement.
Agent and retailer networks are part of the load
Recharge retailers and distribution agents generate their own stream of calls about commissions, stock and activation, and they compete with subscribers for the same lines unless they are given their own path.
The first build, in about 30 days.
The top five self-service intents on the voice line: balance, validity, active packs, data usage and pack activation, read from BSS.
- Subscriber identification and the verification tier you require
- Balance, validity, pack and usage reads from BSS
- Pack activation and deactivation executed with confirmation
- Outage-aware answering where your NOC feed is available
- Handover to agents with context for anything else
Scoping everything at once is how these projects fail. These come after the first build is answering real calls.
- The digital channels, usually phase two once voice is stable
- Complaint and ticket lifecycle management
- Retailer and agent support line
- Outbound campaigns
If three of these are true, book the diagnostic.
A small set of intents accounts for most of your contact volume.
Your voice line, app chat and social channels give inconsistent answers.
Outage events reliably break your service levels.
Subscribers call because self-service in the app did not work.
You cannot economically staff for peak.
Can it handle our volume?
Concurrency is a sizing question answered in the diagnostic, not a yes or no. What we design for is horizontal scale on your infrastructure, so peak capacity is a provisioning decision rather than a hiring one.
Do we have to replace our IVR?
No. In most deployments the engine is reached from your existing IVR, which keeps your routing, reporting and fallback paths intact.
How does it know about an outage?
From your NOC or outage management feed. If that feed is not available to integrate, the engine cannot be outage-aware, and we would say so rather than fake it.
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.