# Channel fallback and omnichannel orchestration

> Channel orchestration delivers one logical message across several channels by cascading: check capability, try the preferred rich channel (RCS or WhatsApp), and fall back to SMS on non-capability, failure or timeout. Routing balances least-cost against best-experience, retry and timeout rules bound each hop, and a unified DLR reconciles status across channels.

- Canonical URL: https://www.broadnet.me/reference/channel-fallback-and-orchestration
- Language: en
- Last updated: 2026-07-18
- Publisher: BroadNet (https://www.broadnet.me)

How omnichannel delivery cascades across channels: capability checks, RCS→SMS and WhatsApp→SMS fallback, least-cost versus best-experience routing, retry and timeout rules, and a unified delivery-receipt view that reconciles status across every channel.

## Why orchestration exists

No single channel reaches everyone, and each has different cost, richness and delivery characteristics — so a business that wants both reach and experience has to use several channels for the same logical message. Omnichannel orchestration is the logic that turns one intent ("tell this customer their order shipped") into the right sequence of channel attempts for that specific recipient: try the richest, most branded channel the device can receive, and fall back through progressively simpler channels until one delivers. The orchestrator hides that complexity behind a single send, so the sender expresses intent and policy while the platform handles capability, routing, retries and reconciliation.

## The cascade: capability check then fallback

A cascade is an ordered list of channels with a rule for advancing to the next. It begins with a capability check — is this device RCS-reachable, is this user WhatsApp-opted-in — because sending to an unreachable channel just wastes a hop. The orchestrator attempts the first eligible channel and advances to the next on a defined trigger: the channel is not capable, the send is rejected, or delivery is not confirmed within a timeout. Common cascades are RCS→SMS (rich branded first, universal text as the floor), WhatsApp→SMS (opted-in app channel first, SMS otherwise) and RCS→WhatsApp→SMS. SMS almost always sits at the bottom because it is the universal, always-reachable floor.

*RCS → WhatsApp → SMS cascade with capability and timeout gates*

```text
deliver(order_shipped, +15551234567):
  if rcsCapable(msisdn):
      send RCS rich card;  await DLR up to T_rcs
      if delivered: DONE
  if whatsappOptedIn(msisdn):
      send WhatsApp template; await status up to T_wa
      if delivered/read: DONE
  send SMS (universal fallback);  await DLR up to T_sms
  record final status on the unified message id
```

## Routing: least-cost vs best-experience

Choosing the order of the cascade is a routing decision, and two objectives pull against each other. Least-cost routing prefers the cheapest channel and route that will deliver — useful for high-volume, low-urgency traffic where a per-conversation RCS charge, a per-message WhatsApp charge or a cheaper SMS route wins. Best-experience routing prefers the richest, most branded, most trusted channel the recipient can receive — useful where engagement, branding or interactivity matter more than unit cost. Most policies blend the two per message class: transactional receipts might optimise for experience and branding, bulk notifications for cost. The orchestrator applies the policy together with capability and per-market rules (sender-ID registration, WhatsApp categories, RCS availability) to pick the actual first hop.

*Routing objectives and where each fits*

| Objective | Prefers | Best for |
|---|---|---|
| Least-cost | Cheapest capable channel/route | High-volume, low-urgency notifications |
| Best-experience | Richest verified capable channel | Branded, interactive, engagement-led messages |
| Reliability-first | Highest guaranteed-delivery channel | OTPs, critical / time-sensitive alerts |
| Compliance-gated | Only channels allowed in the market | Regulated destinations, sender-ID rules |

## Retry, timeout and de-duplication

Each hop in a cascade needs bounded behaviour so the whole delivery is deterministic and never double-charges the recipient. A per-channel timeout defines how long to wait for confirmation before advancing — long enough for a legitimate delivery, short enough that the fallback still arrives usefully (an OTP that arrives an hour late is worthless). Retries within a channel handle transient failures, but must distinguish a permanent reject (advance immediately) from a transient one (retry, then advance). And because a message may have been sent on a rich channel while a fallback fires, the orchestrator de-duplicates against a single logical message ID so the customer does not receive the same notification twice. Idempotency keys on the send make retries safe.

## Unified delivery receipts across channels

Every channel reports delivery differently — SMS returns an SS7/SMPP delivery report, WhatsApp posts sent/delivered/read/failed webhooks, RCS emits delivery and read events — so an orchestrated send needs a unified DLR that maps them all onto one status model against the logical message ID. That lets a sender ask a single question, "did this reach the customer, and how," and get one answer that names the channel that ultimately delivered, the channels that were tried and skipped, and the read/engagement signal where the channel provides it. The unified view is also what feeds routing analytics — which cascades deliver, at what cost, in which markets — closing the loop from policy to outcome.

*Per-channel status mapped to a unified model*

| Channel | Native status | Unified status |
|---|---|---|
| SMS | SMPP/SS7 delivery report | sent / delivered / failed |
| RCS | Delivery + read events | sent / delivered / read / failed |
| WhatsApp | sent / delivered / read / failed webhook | sent / delivered / read / failed |
| Cascade result | (composite) | delivered-via-<channel> / exhausted |

## Frequently asked questions

### What is channel fallback?

Channel fallback delivers one logical message by trying channels in order and advancing when one is unavailable or does not confirm delivery. A typical cascade is RCS→SMS or WhatsApp→SMS: attempt the rich, branded channel first, and fall back to SMS — the universal floor — on non-capability, rejection or timeout.

### How does the orchestrator decide which channel to try first?

It combines a capability check (is the device RCS-reachable, is the user WhatsApp-opted-in) with a routing policy. Least-cost routing prefers the cheapest capable channel; best-experience routing prefers the richest verified one; reliability-first prefers guaranteed delivery. Per-market rules like sender-ID registration and WhatsApp categories further constrain the eligible channels.

### What is least-cost vs best-experience routing?

Least-cost routing picks the cheapest channel and route that will deliver, suited to high-volume, low-urgency traffic. Best-experience routing picks the richest, most branded, most trusted channel the recipient can receive, suited to engagement-led messages. Most policies blend the two per message class — receipts for experience, bulk alerts for cost.

### How does fallback avoid sending the same message twice?

By tying every hop to one logical message ID and de-duplicating against it, with per-channel timeouts and idempotency keys so retries are safe. A permanent reject advances immediately to the next channel; a transient failure is retried before advancing. The recipient sees the notification once, on whichever channel ultimately delivered.

### What timeout should each channel hop use?

Long enough to allow a legitimate delivery confirmation, short enough that the fallback still arrives usefully. A one-time passcode that arrives an hour late is worthless, so its per-hop timeouts are short; a non-urgent notification can wait longer on a rich channel before falling back to SMS.

### What is a unified DLR?

A unified delivery receipt maps each channel's native status — SMS delivery reports, WhatsApp sent/delivered/read/failed webhooks, RCS delivery and read events — onto one status model against the logical message ID. It lets a sender ask a single question about whether and how a message reached the customer, and feeds routing analytics.

## Sources

- [GSMA — RCS Business Messaging and capability discovery](https://www.gsma.com/solutions-and-impact/technologies/networks/rcs/)
- [WhatsApp Business Platform — message status webhooks](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks)
- [3GPP TS 23.040 — SMS status reports](https://www.3gpp.org/dynareport/23040.htm)

## Related

- [Omnichannel](https://www.broadnet.me/products/omnichannel)
- [RCS vs SMS vs WhatsApp](https://www.broadnet.me/reference/rcs-vs-sms-vs-whatsapp-channels)
- [RCS Business Messaging and MaaP](https://www.broadnet.me/reference/rcs-business-messaging-maap)
- [WhatsApp Business Cloud API](https://www.broadnet.me/reference/whatsapp-business-cloud-api)
- [SMS API](https://www.broadnet.me/products/sms-api)
- [CPaaS platform](https://www.broadnet.me/platforms/cpaas)