SMS Routing Optimisation: Balancing Cost and Delivery Quality
Route selection sets the rules. Routing optimisation is what happens afterwards, month after month, as prices move, destinations change their requirements and traffic mix shifts. The discipline is less about clever algorithms than about measuring the trade-off honestly enough that a change can be defended.
Eligibility and quality constraints come first
Optimisation inside a constraint set is a solvable problem. Optimisation that quietly relaxes constraints is how services break. Fix the non-negotiables first — permitted traffic types, sender arrangements and registration, content rules, receipt requirements and the throughput you need — and only then optimise price within what remains. If the foundational policy is not written down yet, start with route selection and monitoring rather than with a rate sheet, and confirm what is actually available for your destinations with an SMSC gateway for carriers and SMS aggregators.
Compare matched cohorts, not calendar months
A routing comparison can mislead when the two samples differ in something other than the route. A defensible comparison holds the obvious variables steady: same destination and network, same traffic type, same sender arrangement, similar message length and encoding, comparable time of day and day of week, comparable volume.
It also waits for receipts to mature. Quote a fixed receipt window and apply it identically to both cohorts, because a route that reports final statuses more slowly will look worse in a short window and better in a long one. Provider status models such as these documented message states illustrate why an in-progress message must not be counted as a failure. Report unresolved messages as their own number, always, and never distribute them silently into success or failure.
A cost measure that includes what you paid for
Rate per message is a poor decision metric because it ignores retries, segments and failures you were still billed for. A more useful figure is cost per observed delivered logical message: for one matched cohort, take the total billable spend for every attempt and every segment in that cohort, and divide it by the number of logical messages with a confirmed delivered status in the same cohort and the same receipt window.
- Include all attempts, including retries and messages that failed after being billable.
- Count segments, not API calls, since a long or Unicode message can be several billable parts.
- Count logical messages once in the denominator, not their segments, or a segmentation change will look like a quality change.
- State the receipt window and the unresolved count alongside the figure.
- Label it clearly as observed delivery based on receipts, which is not the same as measured handset arrival.
Segmentation drives both halves of that fraction. Typical GSM-7 encoding allows 160 septets in a single segment and 153 per concatenated part, while UCS-2 typically allows 70 code units, or 67 per part; extended-alphabet characters and emoji can consume more than one unit, and header or route conventions create exceptions. Treat those as common cases rather than universal counts — the mechanics of SMS character limits are documented publicly, but the price units that apply to your traffic are whatever your agreement says they are. Trimming a template from two segments to one is often the least glamorous and most reliable cost improvement available.
A change-controlled experiment checklist
Treat a routing change as an experiment with a stop condition, not a permanent decision made on a hunch.
| Step | What to agree before starting |
|---|---|
| Question | One destination, one traffic type, one hypothesis |
| Baseline | An agreed prior cohort with the same receipt window |
| Sample | A minimum volume large enough that ordinary variation will not decide the result |
| Split | A modest share of traffic first, with the rest unchanged |
| Guardrails | The receipt latency, error-code and unresolved thresholds that stop the test |
| Rollback | Who reverts, how, and how quickly |
| Record | Owner, UTC effective time, result and the decision taken, kept where the next reviewer will find it |
Watch the signals, not the single ratio
During and after a change, watch error-code distribution, receipt latency percentiles, unresolved share and spend together. The monitoring signals argument applies directly: one aggregate number moves too late and explains too little, while percentiles and error breakdowns show a degradation while it is still small.
Also review the things that are not routes at all. Evaluate template length and wording, opt-out text, sending time, list hygiene and duplicate suppression alongside any route change, and compare the likely benefits and risks of each rather than assuming a supplier change is the answer.
The goal of optimisation is not the lowest possible rate. It is a defensible position on cost and quality for each traffic class, reviewed on a cadence, with evidence anyone on the team can reproduce.
Discuss cost and delivery quality together
Bring your destination mix, traffic types, message sizes and the delivery evidence you rely on. We can then discuss how routing choices, price units and reporting would be arranged for your service.
Sources and further reading
Independent references are general context, not evidence of MessageTrade capabilities, partnerships or performance.
Related guides
- SMS Routing Best Practices: Route Selection and Monitoring
A practical route-selection policy: decide eligibility before price, agree what a delivery receipt actually proves, and review routes on evidence rather than labels.
- Carrier Relations in A2P Messaging: Beyond the Rate Card
Carrier relations is where commercial agreements, route suitability, compliance intelligence and incident response meet — and where messaging becomes more predictable when conditions change.
- AI in SMS Routing: Where It Helps and What to Validate
How to read AI routing claims sceptically: what "dynamic" really means, which problems machine learning genuinely suits, and the validation steps that come before any rollout.