How to compare SMS providers on compliance, deliverability and support
Comparing SMS providers on compliance, deliverability and support means judging only what each vendor publishes—registration regimes, opt-out handling, retention statements, rate cards, coverage—plus what you can measure yourself; vendor-reported delivery figures are self-graded and not comparable across suppliers. Keep published claims and your own test results in separate columns so the side-by-side stays honest.
What a trustworthy side-by-side can and cannot claim
A useful comparison starts from a hard boundary: published records versus observed behaviour. Published records include signup and sender-registration requirements per market, documented opt-out and consent language, data-retention and subprocessors statements, coverage lists, commercial terms (all-in versus floor rate, minimums, prepay versus invoice), status-page URLs, and documented support paths. Observed behaviour is everything else—handset-confirmed receipt, sender-ID preservation, DLR honesty, latency percentiles, and how support actually responds under load. Those require your tests or sampled tickets; they cannot be taken from a marketing page.
Vendor-reported “delivery rates” collapse different definitions (accepted by the gateway, accepted by the operator, handset-delivered, or simply not bounced). Because each supplier grades itself, those figures do not form a side-by-side. Treat them as non-comparable. The rest of this framework states, for compliance, deliverability, commercial terms, and support, exactly which evidence to demand and how to record it so two engineers can reproduce the same matrix months later.
SMSRoute publishes rate and coverage facts in a dated published-rate matrix and exposes a testing cluster so you can run handset and DLR checks yourself. Where we do not publish a claim—real-world delivery percentage, “best” support, guaranteed latency—we refuse the claim rather than fill the cell with marketing language. Your comparison table should do the same for every vendor: empty cell or “unverified” beats a soft number.
SMSRoute's published-rate matrix links every cell to the provider's own page with the date it was read.
Compliance: registration regimes, opt-out, retention
Compliance is mostly documentary. For each destination market you care about, demand the registration regime the provider actually requires: brand/campaign registration, local entity, pre-registered sender ID, template approval, or none stated. Record whether the provider states who files the paperwork and what happens to traffic if registration lapses. Ask for the written opt-out path (keyword handling, STOP semantics, how opt-outs propagate to your account) and whether quiet hours or content categories are enforced in that market. None of this is a percentage; it is a checklist per country and traffic type (alerts, 2FA, marketing).
Data handling is the second compliance column. Require a plain retention statement: how long message bodies, metadata, and delivery reports are kept; whether they leave the stated regions; and which subprocessors touch routing. E.164 numbers are at most 15 digits; your side-by-side should note whether the API normalises, rejects, or silently truncates non-E.164 input, because that behaviour affects both compliance logs and deliverability tests later. Prefer providers that publish these rules in durable docs with dates, not only in sales calls.
Evidence to demand: dated help-centre or PDF policy pages; a per-market registration matrix; sample DPA/subprocessor list; explicit opt-out and consent language you can paste into your own flows. Mark “sales-call only” as weaker than “URL with last-updated date.” SMSRoute states registration and retention on published docs the same way—use those pages as the compliance row for us, and equivalent pages for everyone else. Do not accept “we handle compliance” without the market-by-market breakdown.
Deliverability: what you measure in an afternoon
Deliverability belongs in the measured column. In a few hours you can stand up a small matrix: known handsets or SIMs in target networks, a fixed set of sender IDs (alpha and numeric where allowed), and payloads at the standard segment boundaries—160 and 153 characters for GSM-7 single and concatenated parts, 70 and 67 for UCS-2 single and concatenated parts. Log submit timestamp, gateway accept, DLR fields, and handset-confirmed receipt time. Compare sender-ID as submitted versus as displayed. That is your deliverability evidence; it is not a vendor PDF.
Score four observables, not a single “rate.” (1) Handset-confirmed receipt: did the device get the message. (2) Sender-ID preservation: was the ID rewritten, replaced by a short code, or dropped. (3) DLR honesty: do intermediate and final DLRs match handset reality, or do you see success DLRs for messages that never arrived. (4) Latency percentiles: record p50 and p95 from submit to handset receipt (and separately to first DLR) per route and time-of-day. Percentiles matter more than averages; publish your own p50/p95 from the sample rather than asking the vendor for a headline figure.
Evidence to demand from the vendor is narrow: API docs for DLR codes, any stated retry or replace logic, and access to a testing path equivalent in spirit to a testing cluster you control. Evidence you produce: raw logs from the afternoon run, segment-size notes (160/153/70/67), and whether E.164 normalisation affected routing. Point commercial questions at a dated published-rate matrix; point deliverability questions at your testing cluster results. SMSRoute will not publish a self-graded delivery percentage—use the cluster and your handsets. Never treat “guaranteed delivery” language as a data point; omit that cell.
SMSRoute publishes what it refuses to compare, which is the part most comparison pages omit.
Commercial terms and the published-rate matrix
Commercial comparison is again mostly published text, but the failure mode is hidden floors and fees. For each provider, capture: whether the quoted price is all-in or a floor plus surcharges; per-destination variance; monthly minimums; prepay versus invoice; and what happens on failed or unknown-subscriber traffic. Rates vary by destination and traffic class; do not paste a single number into a “winner” column. Instead link each row to a dated rate record and note the date you pulled it.
SMSRoute’s commercial axis is the dated published-rate matrix: use that document for our numbers and the equivalent public or contractual rate sheet for others. If a supplier will not give a dated sheet, the commercial cell is incomplete. Re-pull matrices on a fixed cadence; SMS pricing moves with operator and registration costs, so an undated screenshot is weak evidence. Segment billing should match the same 160/153 and 70/67 boundaries you used in deliverability tests so cost and encoding experiments stay aligned.
Evidence to demand: dated rate card or matrix, currency and billing increment, minimum commitment, prepay/invoice rules, and treatment of DLR-final failures. Refuse to compare on “contact us” alone. Keep commercial scores out of the deliverability column—cheap routes that rewrite sender IDs or emit false DLRs fail the measured tests regardless of floor rate.
Support: paths, status, escalation—and how to sample quality
Support quality is partly published and partly sampled. Published: named channels (ticket, email, chat), stated response paths for auth, routing, and billing, a public status page, maintenance windows, and an escalation path when a route degrades. Sampled: time-to-first-human on a real incident, whether the reply references your message IDs and DLR codes, and whether escalation reaches someone who can change routing. One quiet week of tickets is not a benchmark industry stat; it is your sample—label it as such with dates.
Build a support row that separates documentation from experience. Documentation score: can an engineer find DLR code lists, registration steps, and incident status without a call. Experience score: from your tickets, note whether answers were actionable and whether status-page events matched what you saw on the wire. SMSRoute publishes support paths and status the same way we publish rates—use those entry points; we do not claim a ranked “best support” position. Where we have not measured something in your account, we leave the claim out.
Evidence to demand: URL of status page, written escalation ladder, support hours and channels in contract or docs, and (from you) a small ticket log with timestamps. Do not use anonymous forum lore as a cell value. If a provider has no status page and no documented escalation, record that absence; it is comparable and often decisive for production traffic.
| Axis | Published evidence to demand | What you measure yourself |
|---|---|---|
| Compliance | Per-market registration matrix, opt-out rules, retention/DPA, dated policy URLs | API behaviour on E.164 input; whether opt-out keywords are honoured end-to-end |
| Deliverability | DLR code docs, retry/replace notes, test-route access | Handset receipt, sender-ID preservation, DLR vs handset match, p50/p95 latency |
| Commercial | Dated rate matrix, all-in vs floor, minimums, prepay/invoice | Billed segments vs 160/153 and 70/67 encoding; failure charging |
| Support | Channels, status page, escalation ladder, hours | Ticket time-to-human, actionable replies, status vs observed incidents |
Putting the matrix together without false precision
Assemble one sheet with four axis blocks. In each cell, either a citation (URL + date) or a measurement (method + date + sample size), or explicitly “unverified.” Do not average compliance paperwork with handset p95 into a single score; the decision is usually a veto model—fail registration in a must-have market, fail DLR honesty on a test cluster, or fail escalation on a live incident, and the vendor drops regardless of price. Capacity and coverage lists are inputs to the test plan, not substitutes for handset confirmation.
Re-run deliverability samples when you add markets or sender-ID types; re-pull the published-rate matrix on a schedule; re-check status and policy pages when contracts renew. SMSRoute’s plain facts remain the dated published-rate matrix, the testing cluster for your own deliverability runs, and documented support and compliance pages—no self-graded delivery percentage, no guaranteed delivery claim, no best-in-market language. That discipline is the comparison: same rules for every provider, empty cells where evidence is missing, and your logs as the only source for deliverability and support quality.
Frequently asked
- How do I compare SMS provider deliverability if published rates are not trustworthy?
- Run your own afternoon matrix: target handsets, fixed sender IDs, and payloads at 160/153 (GSM-7) and 70/67 (UCS-2) boundaries. Score handset-confirmed receipt, sender-ID preservation, DLR agreement with handset reality, and p50/p95 latency from your logs. Use vendor DLR docs only to interpret codes—not as the delivery score.
- What compliance documents should I require from an SMS gateway?
- A per-market registration regime matrix, written opt-out and consent handling, dated data-retention and subprocessor statements, and clear API rules for E.164 (max 15 digits) normalisation or rejection. Prefer URLs with last-updated dates over sales-call assurances.
- What commercial terms matter besides the per-SMS price?
- Whether the price is all-in or a floor plus surcharges, monthly minimums, prepay versus invoice, failure billing, and a dated rate matrix per destination. Align segment billing with 160/153 and 70/67 encoding so cost tracks your deliverability tests; rates vary—re-pull dated sheets rather than relying on a single undated number.