BulkSMSBD Platform Study
Written from inside the account, not from outside the industry.
Bangladesh's A2P bulk-SMS market has matured to the point where price competition has almost nowhere left to go — the going rate sits at 0.25 BDT per message. The next decade of leadership will be decided by something else entirely: how good the product feels to use.
This is a three-part product study for one of the country's established gateways, written in Bengali and grounded in day-to-day use of a live reseller account running thousands of OTP messages a day. It proposes a mobile client app, a rebuilt web panel designed for high-volume users, and a support ticketing system to replace ad-hoc messaging.
The gateway is strong. The way in is not.
A mature SMS gateway is a deep piece of infrastructure: masking and non-masking routes, voice blast, two-way messaging, developer APIs, WordPress and WHMCS plugins, and a multi-level reseller architecture that pushes the service into every district of the country.
But almost all of that value is reachable through exactly one door — a desktop browser. The people who actually run the volume are resellers on the move, SME owners between meetings and developers debugging at midnight. None of them are sitting at a desk when the balance runs out and messages start failing silently.
The study's argument is simple: the product is not the problem, the distance to the product is. Close that distance and retention, top-up frequency and support load all move in the right direction at once.
Tap through the whole thing, right here.
Twenty-five app screens in a phone frame and four website pages in a browser — the same mockups the study is built around. Tap the sides of the phone, or use the arrows.
Findings from use, not from a questionnaire.
Every claim in the study traces back to something observed directly in a working account or measured on the public site — not to assumptions about what a gateway "probably" needs.
A live reseller account
The reference account carries 275 client sub-accounts and pushes up to 14,000 messages on a peak day, almost entirely through the API. That volume is what surfaces the workflow problems a light user never notices.
Panel walkthrough
Every module was opened and used: messaging, reports, phonebook, client management, sender IDs, payments and developer tools — noting where the interface fights a high-volume operator instead of helping.
API surface review
The documented endpoints, the full error-code table and the JSON services already backing the newer report modules were catalogued — which is how the study concludes most of the backend a mobile app needs already exists.
Front-end measurement
The public marketing site was measured rather than judged: total transfer weight, the heaviest single asset, script count and library versions — turning a vague "it feels dated" into a number with a target next to it.
Three proposals, deliberately separable.
Each one stands on its own and can be funded on its own — but they share an API layer and a design system, so doing two together costs materially less than doing them apart.
Official mobile client app
A Flutter app for Android and iOS built on the gateway's existing API — balance, sending, delivery reports, reseller client management and in-app top-up, with push alerts for the failures that are currently silent.
Web platform rebuild
A page-by-page rethink of the client panel for high-volume users — bulk actions, saved views, team accounts with roles, approval workflow, audit trail, API analytics and a white-label reseller portal — plus a faster, better-positioned public site.
Support & ticketing system
Replacing personal-phone messaging with a real two-tier ticketing system — screenshots, voice notes, permanent history, SLA timers and a suggestion board — so support becomes a source of product data instead of a cost centre.
Low-risk migration path
Nothing is switched off. New modules ship alongside the old ones with a toggle back, the database is untouched, and the highest-traffic pages are rebuilt first so the benefit lands early.
Phased delivery
Four phases over roughly thirteen weeks to a store-ready app, each ending in a build that runs — with a clickable prototype in hand inside the first two weeks.
Written to be read on a phone
The document itself practises what it argues: Bengali typography with an embedded webfont, tables that fold into cards on small screens, and collapsible sections — because the person deciding will most likely read it standing up.
The people a gateway actually runs on.
Price buys you a year. Experience buys a decade.
When every provider in a market has landed on the same rate, the differentiator stops being what you charge and becomes what it feels like to work with you. That shift is already underway in Bangladesh's messaging sector — and the operators who move first on experience will be the ones still leading in ten years.
Want a study like this for your platform?
Product audits, roadmaps and the software to deliver them — for teams who would rather fix the experience than cut the price.
