Procurement in this category tends to converge on per-message price, which is the most visible number and among the least decisive. Here is what to read instead.
1. What counts as a message#
Segment definitions, especially for non-Latin scripts. An Arabic SMS uses a different encoding with far fewer characters per segment, so a message that looks like one unit bills as several. If your traffic is not English, get worked examples in the languages you actually send.
2. Route quality and substitution#
Ask whether you are on a route the provider controls or one it resells, and whether they may substitute routes without telling you. Cheaper quotes frequently reflect a right to move you to grey routes during congestion — where deliverability and sender identity both degrade.
3. Delivery reporting fidelity#
"Delivered" from whom? Some receipts mean the downstream aggregator accepted it, not that the handset received it. This distinction is invisible in a dashboard and decisive in a diagnosis.
Ask for the list of status codes and what each one actually attests.
4. Data residency and retention#
Where message content is stored, for how long, and who can read it. Then ask what happens to it at termination — deletion timelines, export format, and whether they will certify deletion.
5. Export rights#
Can you extract your message history, contacts, templates and consent records in a usable format, at any time, without a fee or a support ticket? If not, the switching cost you are agreeing to is much higher than the licence fee suggests.
6. Incident communication#
Not the uptime SLA — everyone offers one, and service credits never compensate for the actual damage. Ask instead: how are you notified, how quickly, and does the status page reflect partial degradation on specific routes or only total outages?
Partial route failures are the common case, and the ones a coarse status page hides.
7. Registration ownership#
For 10DLC, DLT, GCC sender IDs: who owns the registration? If it is registered in the provider's name, migrating means re-registering, which reopens vetting timelines. If it is in yours, you can move.
This is one of the highest-leverage details in the whole agreement, and it is usually not discussed.
8. Price change mechanics#
Carrier fees change, and pass-through is legitimate. What matters is notice period and whether you may exit without penalty when prices rise materially. A contract with no exit on a price increase is not a fixed price.
9. Support model#
Who answers, on what channels, at what hours, in what timezone, and what is the escalation path at 3am on a public holiday in the market where the failure is occurring?
The question that reveals most#
Ask: "walk me through what happens when delivery drops in one country overnight."
A provider with real operational maturity has a rehearsed answer: how they detect it, how they tell you, who investigates, what you do meanwhile. A reseller improvises. The improvisation is the answer.
And the framing to hold on to#
You are not buying messages. You are buying an operational relationship that will be tested during an incident. Price the relationship.
You are not buying messages. You are buying a right to send under someone else's operator relationships, and a set of commitments about what happens when that stops working.
The unit price is the least interesting number in the document. The exit clause is the most interesting, and it is the one written to be skimmed.
The clauses that decide what you actually bought#
A CPaaS contract is mostly boilerplate and about six clauses that matter. These are the six, and the failure mode for each is a live one rather than a hypothetical.
Where the money and the risk actually sit
- Rate structure
Per message, per conversation, per segment. Ask which, for each channel, and what changes it — Arabic switches encoding and multiplies segments.
- Pass-through fees
Carrier and platform fees that are not in the headline rate. Ask for a worked example on your real traffic mix.
- Term and exit
Notice period, minimum commitment, and what happens to your data on the way out. Exit is a clause, not a courtesy.
- Service credits
What the SLA actually pays. Usually a percentage of the affected month, which is rarely the size of the damage.
- Data location
Where messages and metadata are stored and processed, per sub-processor. Names, not regions.
- Registration ownership
Who holds the sender IDs and campaign registrations. If they hold them, switching means re-registering.
Reading an SLA honestly#
| What it usually says | What it usually means | |
|---|---|---|
| Uptime | 99.9% on the API | Roughly 43 minutes a month, measured on their endpoint, not on delivery |
| Delivery | Excluded | Carrier behaviour is outside the SLA in almost every contract, and that is where failures live |
| Remedy | Service credits | A percentage of one month's fees. Not consequential loss, which is where your actual damage is |
| Measurement | Their monitoring | You have no independent measurement unless you built one |
| Claim process | On request, within N days | An unclaimed credit is not paid automatically. Most are never claimed |
The useful move is not to negotiate a higher percentage. It is to instrument your own delivery independently, so that when the relationship becomes difficult you are arguing from your data rather than theirs.
What to negotiate, in priority order#
Most buyers spend their negotiating capital on unit price, which is the term with the least room and the least consequence.
Spend it instead on: portability of sender registrations, a defined exit with an export format, data location commitments naming sub-processors, and a term short enough that the next negotiation happens while you still have alternatives. Price moves a few percent. Those four decide whether you have a supplier or a dependency.
What to take away#
Six clauses matter. Ask the exit question first and listen to the shape of the answer. Read the SLA as a refund policy. Keep your own delivery measurement. And spend the negotiation on portability and term rather than on the per-message rate.