--- title: "Evaluating a CPaaS contract: the clauses that decide what you actually bought" summary: "Unit price is one of the least consequential numbers in the agreement. Nine provisions that matter more, and what a good answer to each looks like." canonical: https://cpaas.co/en/learn/evaluating-a-cpaas-contract kind: report depth: advanced origin: original published: 2026-07-02T16:26:18.899Z updated: 2026-10-14T16:26:19.634Z topics: ["Procurement", "Market", "CPaaS"] language: en --- # Evaluating a CPaaS contract: the clauses that decide what you actually bought ## Why this matters When businesses buy a messaging platform, negotiations tend to focus on the price per message because it is the most visible number. But most of the money and risk in a CPaaS agreement sits elsewhere: in how messages are counted, what "delivered" means, who owns your sender registrations, what happens to your data, and how easily you can leave. This report goes through the clauses that decide what you actually bought, with what to ask and what a good answer looks like. It is not legal advice; have counsel review the final contract. If you are earlier in the process, start with [how to choose a CPaaS provider](/en/learn/how-to-choose-a-cpaas-provider). ## The nine provisions at a glance | Provision | What to ask | A good answer | A warning sign | |---|---|---|---| | What counts as a message | How are segments, templates or conversations counted, per channel? | Worked examples in your languages | "Per message" with no definition | | Route quality | Do you control the route or resell it? Can you change routes without telling me? | Named routes, notice of material changes | A right to move you to cheaper routes silently | | Delivery reporting | What does each status code actually attest? | A documented list, handset receipt distinguished from acceptance | One "delivered" status for everything | | Data location and retention | Where is content stored, for how long, by which sub-processors? | Named sub-processors and countries | "Industry-standard data centres" | | Export rights | Can I export history, contacts, templates and consent records at any time? | Self-service, documented format, no fee | Export only on request, at a cost | | Incident communication | How and how fast am I told about partial degradation? | Per-route status, proactive notice | Status page shows only total outages | | Registration ownership | In whose name are sender IDs and campaigns registered, and can they move? | In yours, with a migration path | In the provider's name, with no transfer process | | Price changes | How much notice, and can I leave if prices rise materially? | Notice period plus exit without penalty | Unilateral changes, no exit | | Support model | Who answers, when, in which time zone, and how do I escalate? | Named escalation path, coverage in your markets' hours | Email queue only | ## 1. What counts as a message Look closely at segment definitions, especially for non-Latin scripts. A standard SMS segment holds up to 160 characters in the GSM 7-bit alphabet, but only 70 characters when the message needs Unicode (UCS-2), which is the case for Arabic, Chinese, Hindi and many others, and also for many emoji. Long messages are split into parts of 153 or 67 characters respectively. A 160-character message is one segment in English and three in Arabic. If your traffic is not in English, ask for worked examples in the languages you actually send. For WhatsApp, Meta has charged per delivered template message since July 2025, with rates by country and category; check whether the provider passes Meta's rates through unchanged, adds a margin, or adds a platform fee on top. ```diagram:bars # One 160-character message, counted In English (GSM 7-bit) | 1 | Segments: one In Arabic (UCS-2) | 3 | Segments: three — parts of 67 characters > Ask for 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 it may substitute routes without telling you. Some cheaper quotes reflect a right to move traffic to lower-quality routes during congestion, where deliverability and sender identity can both suffer. ## 3. Delivery reporting fidelity "Delivered" according to whom? Some receipts mean a downstream aggregator accepted the message, not that the handset received it. The distinction is invisible on a dashboard and decisive in a diagnosis. Ask for the list of status codes and what each one actually attests. ```diagram:path # "Delivered" according to whom? Provider | Accepts your message | Hands it downstream Aggregator | Accepts it from the provider — some receipts that say "delivered" mean only this | Passes it to the operator Operator | Carries it to the handset | Returns a handset receipt Handset | Received: the only "delivered" that means delivered > Ask for the list of status codes and what each one actually attests. ``` ## 4. Data location and retention Where message content is stored, for how long, and who can read it. If you are subject to the GDPR or similar laws, the contract with a processor must cover specific points, including sub-processors and what happens to data at the end of the service. Ask what happens at termination: deletion timelines, export format, and whether the provider will confirm deletion in writing. ## 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 (almost everyone offers one) but: how are you notified, how quickly, and does the status page show partial degradation on specific routes or countries, or only total outages? Partial route failures are the common case, and the ones a coarse status page hides. ## 7. Registration ownership For US 10DLC campaigns, India's DLT registrations, sender IDs in the Gulf or Singapore and similar regimes: in whose name is the registration held, and can it move with you? Where it is held in the provider's name or tied to its account, migrating can mean re-registering and going through vetting again. Where it is in yours, with a documented transfer process, you can move. This is one of the highest-leverage details in the whole agreement, and it is often not discussed. See [sender registration around the world](/en/learn/sender-registration-around-the-world). ```diagram:decision # In whose name are your sender registrations held? ? | In yours | In the provider's Is there a documented transfer process? | You can move, registrations and all | Migrating can mean re-registering and going through vetting again > One of the highest-leverage details in the agreement, and often not discussed. ``` ## 8. Price change mechanics Operator fees change, and passing them through is legitimate. What matters is the 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 which channels, at what hours, in which time zone, and what is the escalation path at 3 a.m. on a public holiday in the market where the failure is happening? ## Reading an SLA honestly ```diagram:compare | What it usually says | What it usually means Uptime | 99.9% on the API | About 43 minutes of downtime in a 30-day month, measured on their endpoint, not on delivery Delivery | Excluded | Operator behaviour is outside the SLA in most contracts, and that is where many failures happen Remedy | Service credits | A percentage of one month's fees, not your consequential losses Measurement | Their monitoring | You have no independent measurement unless you build one Claim process | On request, within N days | An unclaimed credit is often not paid automatically > An SLA is mostly a refund policy, not a reliability guarantee. Read it as one and it becomes much easier to evaluate. ``` The useful move is usually not to negotiate a higher percentage. It is to measure your own delivery independently (for example, with test numbers in each key market and your own analysis of delivery receipts), so that when the relationship becomes difficult you are arguing from your data rather than theirs. ## The questions that reveal most Ask: **"Walk me through what happens when delivery drops in one country overnight."** A provider with operational maturity has a rehearsed answer: how it detects the drop, how it tells you, who investigates, what you do meanwhile. Improvisation is itself an answer. Then ask: **"Walk me through what happens when we leave."** Not "can we leave" (everyone says yes) but in practice: what is exported, in which format, how long it takes, who owns the sender registrations, whether message history comes with you, and how the notice period fits a migration that has to run in parallel. A provider with a calm, practised answer has probably done it before. One that turns vague has an exit process that exists on paper. ```diagram:checklist # "Walk me through what happens when we leave" What is exported | History, contacts, templates, consent records In which format | Documented, usable elsewhere How long it takes | And how the notice period fits a migration run in parallel Who owns the sender registrations | And whether they move Whether message history comes with you > A calm, practised answer suggests they have done it before. Vagueness suggests an exit that exists on paper. ``` ## What to negotiate, in priority order Many buyers spend their negotiating capital on unit price, which often has the least room and the least consequence. Consider spending it instead on: 1. **Portability of sender registrations**, with a documented transfer process. 2. **A defined exit**, with an export format and timelines. 3. **Data location commitments** that name sub-processors and countries. 4. **A term short enough** that the next negotiation happens while you still have alternatives. Price may move a few percent. These four decide whether you have a supplier or a dependency. ```diagram:steps # Where to spend negotiating capital Portability of sender registrations | With a documented transfer process A defined exit | An export format and timelines Data location commitments | Named sub-processors and countries A short enough term | The next negotiation happens while you still have alternatives > Price may move a few percent. These four decide whether you have a supplier or a dependency. ``` ## What to take away You are not just buying messages. You are buying the right to send under someone else's operator relationships, plus commitments about what happens when that stops working. Read the nine provisions, ask the overnight-drop and exit questions first and listen to the shape of the answers, treat 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. ## Where to go next - [Federating systems without merging them](/en/learn/federating-without-merging): designing your stack so any one vendor can be replaced. - [Sender registration around the world](/en/learn/sender-registration-around-the-world): what registrations you will need, and why ownership matters. ## Sources [^1]: [3GPP TS 23.038: Alphabets and language-specific information](https://www.3gpp.org/dynareport/23038.htm) — 3GPP [^2]: [Regulation (EU) 2016/679 (General Data Protection Regulation), Article 28](https://eur-lex.europa.eu/eli/reg/2016/679/oj) — EUR-Lex [^3]: [Pricing on the WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) — Meta for Developers [^4]: [The Campaign Registry](https://www.campaignregistry.com/) — The Campaign Registry --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.