Omnichannel transactional notifications without duplicates

An omnichannel notification system selects a channel using urgency, consent, contact availability and the observed outcome of earlier attempts. Sending SMS, push and email at the same time without coordination is not omnichannel design; it is duplication, unnecessary cost and a poor customer experience.

A durable architecture separates business events from delivery providers. An application publishes an intent once, and an orchestrator applies channel policy, templates, deduplication and escalation.

The transactional event is the source of truth

Do not let every CRM, store or backend construct provider-specific messages. Publish a normalised event:

{
  "eventId": "evt_01...",
  "type": "order.ready",
  "recipientId": "customer_123",
  "occurredAt": "2026-07-13T10:15:00Z",
  "expiresAt": "2026-07-14T10:15:00Z",
  "data": { "orderNumber": "A-1042" }
}

eventId supports deduplication, type selects policy and templates, and expiresAt prevents stale delivery after a queue recovers. Prefer resolving personal contact data inside a protected boundary by recipientId rather than copying it into every event.

Our API integration architecture guide covers contracts, queues and adapters in more detail.

Give each channel a role

Channel	Strength	Constraint	Suitable use
SMS	No app or mobile data required	Cost, length and variable delivery time	OTP, critical status, fallback
Push	Fast and inexpensive for an active app	Tokens expire and users disable it	Order status, in-app action
Email	Rich content and an archive	May be read late	Receipt, document, non-urgent confirmation
In-product	Context within the service	User must open the product	Notification centre and history

SMS remains an important universal route. Use the SMS platform selection checklist to evaluate routing, status and SLA, and use QuickTel, Logic Telecom’s SMS platform, for the SMS delivery layer.

Express channel choice as policy

Policy should be data, not repeated if statements across applications. For each event type, define:

• required and permitted channels;
• sequential or parallel delivery;
• status wait time;
• total workflow TTL;
• maximum attempts;
• quiet hours;
• consent requirements;
• conditions that stop fallback.

For example, send push first. If no delivery confirmation arrives within two minutes and the event is still relevant, submit an SMS. An email receipt can run in parallel because it fulfils a different purpose.

Do not treat message opening as a universal delivery signal. Channels expose different evidence, while privacy controls and client behaviour can distort read events.

Build one internal status model

Provider codes differ, so map them to a stable internal state machine:

• queued — accepted by the local queue;
• submitted — accepted by the provider;
• delivered — a terminal positive result arrived;
• temporary_failure — retry may succeed;
• permanent_failure — retry needs changed data or policy;
• expired — the TTL passed;
• suppressed — policy blocked delivery;
• unknown — no terminal result is available.

Retain the raw provider code alongside the normalised state for diagnosis. For SMS, an API or SMPP response proves acceptance rather than handset delivery; our SMPP versus HTTP API guide explains that boundary.

Prevent duplicates at two levels

Deduplication belongs in at least two places:

1. Business event: republishing the same eventId does not create another workflow.
2. Channel attempt: retrying an attempt with the same key does not create another message.

A key can combine eventId + policyVersion + channel + recipient. Keep it beyond the maximum TTL and replay window. When content genuinely changes, create a new event version deliberately.

Use a transactional outbox: the business transaction writes an event in the same database commit, and a separate publisher relays it to the broker. This closes the gap where an order is committed but its event disappears between two independent operations.

Retries and channel fallback

Retry only temporary failures such as a network interruption, rate limit or provider outage. An invalid address, suppressed channel or expired event should stop or follow a different branch.

Fallback should react to status, not only a timer. If the first provider reports delivery late, the orchestrator should try to cancel the pending alternative. Races cannot always be eliminated, so policy must define acceptable behaviour.

The standardised Web Push protocol in RFC 8030 includes TTL and acknowledgement at the push-service layer. That acknowledgement still does not prove that a person read the notification.

Templates and data

Store templates by event type, channel, language and version. Text changes need review, and required variables need validation.

Checklist:

• test SMS length with encoding and segmentation;
• use a trusted link domain and expose no secret;
• keep OTP out of email or push unless the threat model permits it;
• escape all parameters;
• provide a fallback when a translation is unavailable;
• preserve which template version was sent.

Consent and preference

Separate required service communication from marketing in policy, templates and consent audit. User preferences may not apply to a message essential to transaction security, but every exception needs a verified basis.

Store consent scope, source and timestamp. Apply opt-out before a marketing attempt enters the queue. The legal classification of a particular message should be reviewed by a qualified specialist.

Operational measures

• end-to-end delivery before TTL;
• p50, p95 and p99 by channel;
• fallback ratio and trigger reason;
• permanent contact failures;
• duplicate-message rate;
• age of oldest queued event;
• cost per successfully completed event;
• conversion only where a sound definition exists.

Reconcile provider reports with product events. The broader correlation model appears in our infrastructure observability guide.

Launch checklist

• Applications publish each event once.
• Every event has an ID, type and TTL.
• Channel policies are versioned.
• Consent and preferences are checked centrally.
• Provider statuses map to one model.
• Retry does not produce a duplicate.
• Fallback stops after success.
• Personal data is masked in logs.
• Tests cover latency, provider outage and queue buildup.
• Critical journeys have a documented manual mode.

How we can help

Logic Telecom can help design the orchestrator and integration adapters, while QuickTel can provide the SMS part of the route. A practical first step is one event, an explicit policy and a verifiable outcome; channels can then be added without changing the producing application.