The pattern we keep seeing
Talk to enterprise messaging buyers and a quiet shift becomes obvious. The default architecture from 2015–2022 — a single CPaaS handling SMS, voice, WhatsApp, and email behind one API — is being unbundled.
What replaces it is not another product category. It is a separation of three decisions that used to be bought as one:
- The application — what messages you send, to whom, and why.
- Route supply — who provides the connectivity into each destination network.
- Messaging operations — routing policy, sender registrations, monitoring, vendor escalation and reporting.
Bundled CPaaS answers all three with one contract. Once messaging volume matters commercially, buyers start answering them separately, because the right answer to each one changes at a different pace.
1. Unit cost becomes visible
At low volume, per-message price is a rounding error and convenience is worth paying for. At high volume it becomes a line item someone owns, and the buyer starts asking what part of the price is connectivity and what part is the platform around it. The size of that gap depends entirely on destination, traffic class and negotiated terms — it is not a single number, and anyone quoting you one is guessing. The point is that it stops being invisible.
2. Vendor concentration became a question people ask
Any single supplier can degrade — a route into one operator, a regional platform issue, a registration dispute. What changed is not that outages started happening; it is that buyers now treat "what happens if this one supplier is unavailable for six hours" as a question requiring a documented answer. Procurement wants:
- Multiple vendors per channel
- The ability to flip routing without a contract renegotiation
- Direct visibility into per-route performance
A single-vendor architecture makes all three harder, whoever the vendor is.
3. The compliance map got more complex
US brand and campaign registration, RCS and WhatsApp sender onboarding, data-protection review of message content and logs — the operational surface around sending has grown, and most of it is work rather than configuration. Buyers want someone accountable for that work who is not also the only possible supplier of the traffic.
What "managed gateway" actually means
The phrase is doing a lot of work. In practice, a managed gateway is:
- A routing engine that decides which route handles each message based on destination, traffic class, route health, and cost
- A monitoring layer that tracks DLRs, conversion, latency, and cost per route
- An operations team that handles vendor escalations, registrations, and incident response
- A single API for the application, regardless of how many suppliers sit behind it
What it deliberately does not do is force the supply question. The operational layer works the same whether the routes underneath it are supplied by the gateway operator, contracted directly by the buyer, or a mix of both. That separation is the whole point: you can change supplier without changing how you operate, and change how you operate without renegotiating supply.
Where BYOV fits
BYOV — bring your own vendors — is what this looks like when the buyer already holds direct relationships and wants to keep the per-message economics they negotiated. The gateway plugs into the existing SMPP or HTTP connections and takes over routing, monitoring and escalation.
It is one option, not the destination. Plenty of buyers never want to run vendor relationships and would rather buy routes from the party operating the gateway. Plenty of others do both: supplied routes for most destinations, their own contracts where they have real commercial leverage or a regulatory reason to hold the connection themselves.
What this changes for product teams
If you build product on top of messaging, three things change:
- API stability matters more, not less. When the routing layer can be re-platformed independently of the application, the API contract becomes the long-term commitment.
- Observability is a buy criterion. Per-route, per-operator dashboards stop being a nice-to-have when you have multiple vendors to compare.
- Vendor selection becomes a quarterly conversation, not a multi-year decision. When you can flip routing in minutes, the procurement cycle shortens and the operational discipline tightens.
What this changes for CPaaS vendors
CPaaS isn't going away — it's still the right answer for early-stage products, low volumes, and teams without procurement bandwidth. What's changing is the upper bound. There's no universal volume at which buyers make the switch; the trigger is usually a specific event — a bad incident, a pricing review, a market where the bundled route simply doesn't perform — rather than a threshold on a chart.
The vendors responding well are the ones repositioning as wholesale-grade infrastructure: better APIs, sharper SLAs, fewer added services. The ones who aren't are doubling down on the bundled pitch.
Where Flowstates fits
We operate the messaging layer, and we can also supply the routes underneath it. Customers run one of three models: buy channels and routes from us, keep their own vendor contracts and let us operate them (BYOV), or combine the two. In every case we own the same things — routing policy, sender registrations, monitoring, vendor escalation and reporting — and the supply arrangement is a commercial decision you can change without re-integrating your application.