SMS deliverability: DLR, latency and quality metrics

SMS deliverability cannot be reduced to one percentage. A business needs the final delivery report, end-to-end latency, delivery within a useful window, failures by operator and route, and the user’s intended action. A message delivered after an OTP expires or an appointment begins may be technically successful but no longer useful.

What a DLR means

A Delivery Receipt is a message-state report returned through the delivery chain to the communications platform and then to the customer system. Operators and providers use different codes, so the application should have its own normalized state model.

A practical minimum is:

• created — the business system created the message;
• accepted — the platform accepted and initially validated the request;
• submitted — the message was handed to the next route participant;
• delivered — a final positive report was received;
• failed — a final negative report was received;
• expired — the delivery lifetime ended;
• unknown — no final result arrived within the defined period.

accepted confirms API processing, not handset delivery. Even delivered does not prove that a person read the message or completed the intended action.

Timestamps to retain

Troubleshooting needs more than the final state. Store several timestamps with consistent clock and time-zone rules:

1. creation of the business event;
2. entry into the application queue;
3. request submission to the platform;
4. platform response;
5. operator or downstream-route submission;
6. receipt of the DLR;
7. the user’s target action when relevant.

This separates delay in the application, queue, transport and delivery network. A single “SMS time” metric hides the cause and makes incidents harder to investigate.

Core indicators

Delivery rate

The share of messages with a final delivered status among messages accepted for sending. Define the denominator explicitly: excluding requests rejected for technical reasons can make a report look artificially better.

Delivery within target

The share of messages delivered within the business-defined time. An OTP may have a short window, while an order update can allow longer. This indicator usually represents the usefulness of a transactional message better than the eventual DLR.

Latency percentiles

An average hides uncommon but damaging delays. Use P50 for the typical experience, P95 for the majority and P99 for the distribution tail. Calculate percentiles separately for creation to acceptance, acceptance to DLR and the complete path.

Failure rate

The share of final non-deliveries grouped by normalized cause. Invalid address, unavailable subscriber, expiry, filtering and technical route failure require different responses.

Conversion rate

The share of messages followed by the intended action: OTP verification, order confirmation, opening the relevant screen or completing an appointment flow. Marketing measurement and its legal basis differ; a technical DLR never replaces product analytics.

Normalizing error codes

Raw operator and aggregator codes are essential for investigation but awkward on a shared dashboard. Keep the original value and map it to an understandable group:

• invalid or unavailable number;
• temporarily unreachable device;
• delivery expired;
• rejected sender name or template;
• restriction or filtering;
• route or platform failure;
• unknown cause.

Version the mapping because the same value can have different meanings across connections. Do not treat every temporary error as a reason for an immediate resend; this can create duplicates and additional load.

Useful reporting dimensions

An overall rate can stay stable while one important segment deteriorates. Metrics should be filterable by:

• scenario: OTP, service or marketing;
• destination operator and country;
• route or route group;
• sender identity and template;
• hour and day of week;
• application, customer or business process;
• initial versus repeated send;
• message length and SMS segment count.

Dashboards should not expose phone numbers or message content to users who do not need them. Aggregated data and controlled access to an individual message record are sufficient for quality analysis.

Connecting delivery to business outcome

Use a correlation ID from the business event through the message and target action. It reveals conditions that an operator report cannot:

• the code arrived but could not be used;
• the DLR was delayed although verification had already succeeded;
• a resend increased cost without improving conversion;
• a template delivers normally but creates more support requests;
• the fallback channel activates too often.

For OTP, build a funnel from request to platform acceptance, delivery within TTL, entry started and successful verification. Our secure SMS OTP guide covers the architecture behind this workflow.

SMS SLIs, SLOs and alerts

An SLI should represent recipient value, such as “percentage of OTP messages delivered within 20 seconds of request” or “P95 end-to-end latency for service notifications.” Select the actual SLO from observed data, provider agreements and process criticality rather than copying another system’s target.

Useful actionable alerts include:

• delivery within target below threshold for several intervals;
• a material P95 increase from the normal baseline;
• a rise in unknown or one failure group;
• one operator diverging from the rest;
• more resends without more successful verifications;
• the send queue ageing faster than it is drained.

Apply rolling windows and minimum sample sizes so small traffic volumes do not create constant false alarms.

Comparing SMS platforms

Ask providers for more than an overall delivery percentage. Review the state model, webhook availability, history depth, original-code export, timestamps and event-redelivery rules. Compare platforms using the same lawful traffic, templates and time periods.

Absolute delivery cannot be promised because number quality, device state, network conditions, filtering and operator rules all contribute. The guide to choosing an SMS platform covers technical and contractual criteria.

Quality-dashboard checklist

• Platform acceptance is separate from final delivery.
• Delivery within target is available alongside eventual DLR.
• P50, P95 and P99 are shown instead of only an average.
• Original error codes are retained and mapped to normalized groups.
• Initial sends are separate from resends.
• Traffic is segmented by scenario, operator, route and template.
• A correlation ID connects delivery with the intended action.
• Personal data is hidden from aggregate reports.
• Alert rules require a meaningful sample size.
• Operators can locate a message by identifier without searching a plain phone number.

Practical conclusion

Good SMS analytics answers three separate questions: was the request processed, did the message arrive in time and did the business workflow achieve its user goal? Combining these levels produces an attractive but unhelpful number.

QuickTel provides an interface and API for enterprise SMS. Before integration, agree on DLR states, webhooks, history retention, reporting and fallback rules, then validate the indicators on your own traffic and target workflows.