Designing an SMS test matrix: destinations, encodings and sender types
A single test SMS that lands is not evidence your campaign will succeed. Delivery, displayed sender, and content integrity shift with destination market, encoding, sender type, and wording. Design a pre-sendout matrix on those four axes, record handset outcomes per cell, prioritise the traffic you will actually send, and re-test when routes or templates change—using free SMSRoute test credits and dashboard delivery-testing tools before you pay.
Why one lucky message is not a test plan
Teams often fire one SMS to a familiar handset, see it arrive, and green-light a sendout. That sample is confounded: it usually shares the tester’s home market, a single encoding path, one sender form, and non-representative copy. Carriers and intermediate routes apply different sender-ID regimes, character-set handling, and content filters by country. A pass on one path says nothing about the paths your real traffic will take.
A test matrix treats those differences as deliberate factors. You define cells along the axes that change outcomes, send a small controlled message into each cell you care about, and record what the handset actually shows. The goal is not statistical coverage of the entire world. It is qualitative proof for the combinations you will bill against—before volume, before templates freeze, and before support tickets arrive.
SMSRoute accounts include free test credits that prove delivery before you pay, and delivery-testing tools are available in the SMSRoute dashboard. Use those to populate the matrix; do not burn production budget on ad-hoc checks. Keep E.164 destinations (up to 15 digits) consistent, log API outcomes (HTTP 200 versus 429 or 500) separately from handset outcomes, and treat SMPP state identifiers from the pipeline as transport signals—not as substitutes for “displayed on device.”
SMSRoute's country fact sheets carry the sender-ID regimes and charset classes that define the destination axis of this matrix.
The four axes that actually change outcomes
Destination market is the first axis. Sender-ID regime and default charset class differ by country and often by operator within a country. Some markets accept alphanumeric origins with little friction; others rewrite, drop, or require registration-style handling for alphanumeric identities. Numeric long codes and shortcodes, where available, follow different rules again. Charset class matters because a template that is pure GSM-7 in one language can force UCS-2 as soon as a single non-GSM character appears—common when localised names, currency symbols outside the GSM set, or certain punctuation enter the body.
Encoding is the second axis. GSM-7 segments at 160 characters for a single part and 153 per part when concatenated. UCS-2 segments at 70 and 67 respectively. The same human message can therefore fragment differently, hit different filter paths, and display with different truncation behaviour depending on whether the template stays inside GSM-7. Test both the GSM-7 form of a template and the UCS-2 form if your copy can leave the GSM alphabet—do not assume the gateway’s automatic upgrade path matches what you intend users to see.
Sender type is the third axis: alphanumeric versus numeric versus shortcode where the market supports it. Alphanumeric senders carry brand recognition but are the most regime-sensitive. Numeric senders behave more like ordinary MSISDNs on many routes and may improve consistency where alphanumeric display is unstable. Shortcodes are market-specific and not universally available; only include them in cells for destinations where you actually hold or will use that origin form. Never invent a sender type the route cannot originate.
Content variant is the fourth axis. Transactional-style wording (concise, identity or receipt oriented, minimal marketing language) and promotional-style wording (offers, urgency, calls to action) are filtered differently in many markets. Links versus no links is a further split: URL presence changes length, encoding pressure, and scam-filter exposure. Build variants that mirror what you will really send—not sanitized lab copy that never appears in production.
What each cell records
Every matrix cell is a contract between a chosen destination market, encoding, sender type, and content variant. For each cell, record four handset-level fields. First: delivered on handset yes or no—observed on a real device in that market, not inferred from a submit ack alone. Second: displayed sender—the exact string or number shown in the inbox, including whether an alphanumeric identity was rewritten to a numeric or generic label. Third: content intact—body matches the intended template, including character fidelity, segment reassembly, and link integrity if present. Fourth: latency—time from accepted submit to handset visibility, captured so you can compare p50 and p95 across cells rather than relying on a single stopwatch reading.
Alongside handset fields, keep transport notes: HTTP status on submit (200, 429, 500), any SMPP-related state identifiers your integration surfaces, segment count implied by 160/153 or 70/67 rules, and the exact payload bytes you sent. Separate “accepted by API” from “shown on device.” Acceptance without handset confirmation is an incomplete cell. If a cell fails, change one axis at a time on the re-run so you know which factor moved the outcome.
Do not claim guaranteed delivery from a green cell. A pass means that combination worked under the route and time you tested. Routes change. Record timestamp, route or account context available to you, device model if relevant to display quirks, and template version hash or label so later complaints can be matched to a known cell.
SMSRoute's country fact sheets carry the sender-ID regimes and charset classes that define the destination axis of this matrix.
Prioritising cells when the budget is small
When test credits are limited, do not build the full Cartesian product of every market, encoding, sender, and variant. Prioritise destination × content cells for the traffic you will actually send. If ninety percent of planned volume is transactional notifications to one market with links in some templates and not others, those destination–content intersections come first. Encoding and sender type then fan out only inside the destinations you have already justified.
Practical order: (1) each live destination market with the dominant content variant and the sender type you intend to productionise; (2) the same destination with the secondary content variant if you will mix transactional-style and promotional-style traffic; (3) encoding splits where templates may leave GSM-7; (4) alternate sender types only if you have a fallback plan to use them. Skip shortcode cells entirely unless shortcodes are in scope for that market.
Qualitative guidance beats fake coverage targets. A thin matrix that mirrors real traffic is more honest than a wide matrix filled with markets you will never message. Prefer one real handset observation per critical cell over many automated submits with no display check. Use free SMSRoute test credits to clear the critical path first; expand only when a cell fails or when a new market joins the plan.
Worked example: Germany and Poland, two templates
Consider a two-country campaign aimed at Germany and Poland, with two templates: T-txn (transactional-style, no link, GSM-7-safe copy) and T-promo (promotional-style, includes a tracking link, may introduce characters that push UCS-2). Both markets are EU destinations where alphanumeric sender display and filtering are operator-sensitive; treat sender-ID regime as registration-or-rewrite class rather than assuming open alphanumeric passthrough. Charset class for planning is GSM-7 default with UCS-2 fallback when non-GSM characters appear in names, subjects, or URLs.
Sender types in scope: alphanumeric brand origin as primary; numeric long-code fallback if alphanumeric display is rewritten or unstable on a given path. Shortcodes are out of scope for this example unless you already operate them in-market. Encoding cells: GSM-7 for T-txn; for T-promo, one GSM-7 attempt if the link and copy stay inside the alphabet, plus an explicit UCS-2 cell if localised characters or symbols force it. Content cells: T-txn versus T-promo as written for production—not paraphrased lab text.
The table below is a design matrix, not a result log. Leave delivered, displayed sender, content intact, and latency empty until handset checks complete. Do not invent pass/fail outcomes. Populate using SMSRoute free test credits and dashboard delivery-testing tools, one controlled submit per cell, real devices in-market or equivalent destination termination you control for observation.
After runs, promote only cells that show handset delivery, acceptable displayed sender for your brand rules, intact body and link, and latency within your operational tolerance on p50/p95. If Germany alphanumeric T-promo fails display but numeric T-promo passes, that is a sender-type finding—not a reason to skip Poland cells. Re-run changed axes only.
| cell_id | destination | template | encoding | sender_type | content_notes | delivered_handset | displayed_sender | content_intact | latency_notes |
|---|---|---|---|---|---|---|---|---|---|
| DE-T-txn-GSM7-alpha | Germany | T-txn | GSM-7 | alphanumeric | transactional-style, no link | ||||
| DE-T-txn-GSM7-num | Germany | T-txn | GSM-7 | numeric | fallback origin if alpha rewritten | ||||
| DE-T-promo-GSM7-alpha | Germany | T-promo | GSM-7 | alphanumeric | promotional-style, with link; GSM-safe copy | ||||
| DE-T-promo-UCS2-alpha | Germany | T-promo | UCS-2 | alphanumeric | same promo intent; non-GSM characters present | ||||
| PL-T-txn-GSM7-alpha | Poland | T-txn | GSM-7 | alphanumeric | transactional-style, no link | ||||
| PL-T-txn-GSM7-num | Poland | T-txn | GSM-7 | numeric | fallback origin if alpha rewritten | ||||
| PL-T-promo-GSM7-alpha | Poland | T-promo | GSM-7 | alphanumeric | promotional-style, with link; GSM-safe copy | ||||
| PL-T-promo-UCS2-alpha | Poland | T-promo | UCS-2 | alphanumeric | same promo intent; non-GSM characters present |
Re-test triggers and closing the loop
A completed matrix ages. Re-test when the route or upstream path changes, when you add a new destination market, when complaint or non-delivery reports spike for a template you previously cleared, or when you rewrite a template enough to change encoding class, link presence, or tone (transactional-style versus promotional-style). Sender-ID regime shifts in a market—new registration expectations, new rewrite behaviour—are also triggers even if your copy is unchanged.
On re-test, replay the affected destination × content cells first, then encoding and sender-type variants that previously mattered. Compare displayed sender and content integrity against the prior log, not only binary delivery. Watch segment boundaries again: a small copy edit can move a GSM-7 message across the 160/153 boundary or flip GSM-7 to UCS-2 at 70/67, altering both user experience and filter exposure.
Keep the matrix as a living artefact next to your template repo. Version templates, note which SMSRoute test credit runs map to which cell_id, and require a handset-confirmed pass before production senders and bodies are unlocked for volume. Uncertainty remains—mobile termination varies by operator and time—but a disciplined matrix replaces superstition with documented, repeatable checks along the axes that actually change outcomes.
Frequently asked
- What should an SMS pre-sendout test matrix include?
- Define cells on four axes—destination market (sender-ID regime and charset class), encoding (GSM-7 versus UCS-2, mindful of 160/153 and 70/67 segment limits), sender type (alphanumeric, numeric, shortcode where available), and content variant (transactional-style versus promotional-style, links versus no links). Per cell record handset delivery yes/no, displayed sender, content intact, and latency (including p50/p95 when you have enough samples), plus transport notes such as HTTP 200/429/500.
- Which SMS test matrix cells should I prioritise on a small budget?
- Prioritise destination × content cells for the traffic you will actually send, using the sender type you intend to productionise. Add encoding splits where copy may leave GSM-7, and alternate sender types only if they are real fallbacks. Skip markets and shortcodes outside scope. Use free SMSRoute test credits and dashboard delivery-testing tools to clear that critical path before wider exploration.
- When should I re-test SMS delivery after the initial matrix?
- Re-test after route changes, new destination markets, complaint or non-delivery spikes, and template rewrites that alter encoding, links, or promotional versus transactional tone. Also re-test when sender-ID regime behaviour in a market changes. Replay affected destination × content cells first and confirm handset display, not only API acceptance.