Designing a Multi-channel Fallback Chain

Channels are not interchangeable

Most multi-channel pitches treat SMS, RCS, WhatsApp, and email as parallel options the user can pick between. In production messaging, that's the wrong mental model.

The right model is a fallback chain: try the cheapest channel that's likely to work for this user, fall back to the next one only if the first fails or doesn't deliver in time.

Done well, this cuts costs by 20–40% and improves reach. Done badly, it sends the same message four times to the same person.

The economics that drive the chain

Per-message costs vary by an order of magnitude:

• Email: fractions of a cent
• WhatsApp utility template: ~1–2 cents (varies by market)
• RCS: similar to SMS in most markets, sometimes cheaper for rich content
• SMS: 0.5–10 cents depending on country

So the cost-optimal order is usually: email → RCS (if user has it) → WhatsApp → SMS. The reach-optimal order is the reverse: SMS first because every handset can receive it.

A real fallback chain trades these against the cost of a missed message.

A concrete chain for transactional traffic

For a high-value transactional message (order shipped, delivery confirmation):

1. Try RCS (if device capable, ~2s timeout for read receipt)
2. If no read receipt → try WhatsApp Business template
3. If no read receipt within 60s → fall back to SMS
4. Always send email in parallel as a passive copy

Critical design points:

• Read receipts, not delivery receipts, drive the fallback decision for rich channels. RCS and WhatsApp expose this; SMS doesn't.
• Time bounds at every step. A fallback that takes 5 minutes is worse than no fallback for time-sensitive messages.
• Email is a passive copy, not a fallback step. Sending email last and waiting for it to fail is meaningless — there's no real "delivery" signal.

The OTP exception

For OTPs, the fallback chain is much shorter and faster:

1. SMS (always, immediately)
2. Voice call with read-out (only if user opts in or after 60s no entry)

Why no RCS or WhatsApp? Because:

• Latency on rich channels is less predictable
• Read receipts add a step you can't afford in a 60-second TOTP window
• SMS reach is universal; rich channels aren't

OTPs should be optimised for time-to-deliver, not cost.

When parallel beats serial

There are cases where sending on multiple channels in parallel is correct:

• Marketing announcements where the goal is awareness, not single-touch delivery
• Critical alerts where the cost of a missed message far exceeds the cost of a duplicate (security, account compromise)
• Multi-device users where the email might be read on desktop and the SMS on phone

The rule of thumb: parallel when the message is critical and the user won't object to duplication; serial fallback otherwise.

Operational requirements

A fallback chain requires three things most messaging stacks don't have out of the box:

1. Channel capability lookup per user — does this number have RCS? Is there an opted-in WhatsApp number?
2. Cross-channel state tracking — within one logical message, what was sent on what channel and what was the response?
3. Per-step timeout handling — the chain must move on automatically when a channel doesn't respond.

Building this in-house is non-trivial. It's one of the things a managed gateway is supposed to handle for you.

What to measure

Don't just measure delivery per channel. Measure:

• Cost per converted message — total spend across the chain divided by users who acted
• Channel attribution — which step of the chain actually delivered the read
• Fallback rate — how often the second and third channels are needed (high rates suggest the first channel is wrong)
• Total time-to-read across the chain, not per channel

These numbers tell you whether the chain is working or whether you're paying for redundancy you don't need.

Common mistakes

Three patterns we see repeatedly:

1. Sending on every channel "for safety" — burns budget, annoys users, dilutes engagement signals.
2. No timeouts between steps — fallback that takes 10 minutes makes the message irrelevant.
3. Treating email as a fallback — there's no real delivery signal, so the chain can't make decisions on it.

---

If you're designing or rebuilding your fallback logic across channels, book a 30-minute messaging review. We'll share patterns that work in production.