A capability matrix is only as useful as its failure column. Buyers comparing CPaaS stacks can find feature lists anywhere; the choice-critical question is what each channel does when the recipient is unreachable, the sender is not allow-listed, or the handset cannot receive the content type. This post answers that question for the messaging channels Devotel Orbit ships, using the organization-level cross-channel fallback chain as the mechanism, and ends with the matrix table CX-stack evaluators can lift straight into a comparison document.
What happens per channel when the recipient is unreachable
Each channel family fails differently, and the difference decides what a fallback chain can recover.
- WhatsApp. Sends ride approved templates for business-initiated conversations. If the recipient has no WhatsApp account on that number, the send can never become a conversation; if the recipient blocked your business, Meta reports the failure and retries are pointless. An unapproved or mismatched template rejects before anything leaves.
- RCS. The router checks the recipient's RCS capability at send time, using a cached verdict or a live provider probe on a miss. Not-capable recipients short-circuit: without a chain configured the send fails closed with a receipt naming the reason, and no partial render ships.
- Viber. The one-way tier depends on an allow-listed alphanumeric sender per market. When a Viber send fails for a Viber-specific reason, such as the recipient having no Viber installed or the sender ID not being allow-listed in that market, an organization-level fallback chain can retry the message over another channel, typically SMS, with no change to the request.
- Telegram. One bot per organization, connected through BotFather. When a user blocks your bot, the recipient is marked as blocked and the right move is to treat that as an opt-out, not to attempt a different route. Blocked-bot status is a terminal state, not a retryable failure.
- LINE, KakaoTalk, Zalo, WeChat. Three of the four APAC winners are template-only, so an unapproved template rejects outright. LINE is the free-form exception. All four share the connect-send-listen pattern: if the recipient has never followed your official account or added your channel as a friend, several of these channels cannot reach them at all.
- SMS. The universal catch-all. Failure modes are carrier-side: filtering on unregistered sender IDs, 10DLC registration gaps in the US, and handset-level delivery failures. There is no fallback beneath SMS, which is why every sensible chain ends on it.
- MMS. Carrier-side like SMS, limited to a narrower set of markets and handsets. Where MMS is unavailable, the degraded form is an SMS with a link rather than an inline image.
- Email. Failure arrives as bounces and provider-level suppression. Unreachable here means the address does not exist, the mailbox rejected, or your sending domain reputation blocked the delivery.
- Push. Failure means the device token is dead: the app was uninstalled or the token expired. Push has no meaningful fallback to another push provider; the only recovery is a different channel family entirely.
The takeaway from the list: unreachable is not one problem. It is at least three (no app installed, not allow-listed, terminal block), and a fallback chain only solves the ones that are retryable in principle.
Organization-level fallback chains: the shipped mechanism
Fallback on Devotel Orbit is an organization-level routing posture, not a per-request flag. You define an ordered channel chain once under your organization's settings (for example WhatsApp → SMS or RCS → WhatsApp → SMS), and the router applies it to every send path: API, campaigns, journeys, and inbox replies. The send endpoint accepts no fallback field; one you pass is ignored by design, so every caller gets identical behavior.
When the primary send fails for a channel-specific, retryable reason, the router hands the same message to the next channel in the chain. The beyond-sms post describes the same mechanism for the OTT channels: an organization-level cross-channel fallback chain retries the message over another channel, typically SMS, with no change to the request. RCS works the same way, with the capability check as its trigger: the RCS-to-SMS fallback guide walks the configuration, cohort split, and measurement in detail, and the RCS launch checklist treats a defined fallback as a go-live gate.
Two consequences of the org-level placement matter for buyers. First, content is authored once and the router downgrades it: rich RCS cards and WhatsApp interactive elements do not port to SMS, so the SMS leg carries plain text and must read complete on its own. Second, a failure with no chain configured fails closed with a receipt that names the reason. There is no silent partial render and no invisible strand; that is the property auditors ask for.
The capability matrix
Capability × channel × fallback target, as shipped today. "Yes, typical target" marks the chain most programs actually configure; "No" marks a failure the chain either cannot retry or a channel that cannot serve as a fallback hop.
| Channel | Unreachable failure mode | Retryable via chain? | Typical fallback target | Notes |
|---|---|---|---|---|
| No account on number; template rejected | Yes | SMS; RCS where supported | Blocked recipients are terminal, not retryable | |
| RCS | Recipient not RCS-capable | Yes | SMS | Capability verdict caches 24 hours |
| Viber | No Viber installed; sender ID not allow-listed in market | Yes | SMS | Two tiers share one endpoint |
| Telegram | User blocked the bot | No (terminal) | None | Treat a bot block as an opt-out |
| LINE | Not following the official account | Partially | SMS | Free-form content survives the downgrade |
| KakaoTalk | Template rejected; not a friend | Partially | SMS | Alimtalk template-only; Friendtalk followers only |
| Zalo | Template rejected; not following | Partially | SMS | ZNS is template-only |
| Template rejected; not following | Partially | SMS where reachable | Official Account model | |
| SMS | Carrier filter; registration gap | No | None (terminal) | The universal fallback endpoint |
| MMS | Handset or market unsupported | Yes | SMS with link | Degrades to a link, not an inline image |
| Bounce; provider suppression | Yes | SMS for short alerts | Different channel family; no content port | |
| Push | Dead device token | Yes | SMS; email | Token death means the app is gone |
Read the matrix with one rule in mind: a Yes in the retryable column means the failure is channel-specific and the message still has somewhere to land. Blocked, terminal, and not-following states are consent or relationship facts, and no router should route around them.
Consent and opt-out checks re-run on the failed-over channel
The property that separates a real fallback mechanism from a retry loop is what happens to consent on the downgrade. On Orbit, consent and opt-out controls are per-channel tenant settings, and the shipped guarantee is that the failed-over send re-runs the destination channel's checks before it ships. When a Viber or RCS send falls back to SMS, the SMS opt-out and do-not-contact check runs again against the recipient. A customer who opted out of SMS does not receive the SMS fallback, even though they accepted Viber or RCS. The beyond-sms post states this guarantee verbatim, and the fallback strategy guide spells out the same behavior for the RCS → SMS chain.
That guarantee has a configuration consequence buyers should price in: opt-out posture must be aligned across every channel in the chain. STOP keywords, quiet-hours windows, and consent language are per-channel settings your tenant owns. If the RCS agent says "reply STOP" while the SMS sender uses a different keyword, the downgrade changes the compliance posture mid-conversation. Orbit exposes the controls; the tenant sets the posture, and the per-channel check runs on whatever the tenant configured.
How to configure fallback
Configure the chain once at the organization level in the dashboard's channel settings, on the fallback card: add a rule with a primary channel and an ordered fallback list, and save. The setting applies to every send path on the next send with no redeploy.
Per-channel mechanics live in the docs:
- RCS: capability check, chain triggers, sender profile.
- WhatsApp: templates, blocked-recipient handling.
- SMS and MMS: sender registration and the terminal leg.
- Viber, Telegram, LINE, KakaoTalk, Zalo, WeChat: OTT-specific failure semantics.
- Email and push: bounce and token hygiene.
- For SMS-reach questions per destination country, the country capabilities endpoint reports line-type and capability inventory before you search for numbers.
The RCS-to-SMS fallback guide walks a worked mixed-market example, and the beyond-SMS OTT channels post covers the regional-first channel picks the chains attach to.
Frequently asked questions
What is an organization-level fallback chain?
An ordered list of channels you define once in your organization's settings, such as RCS → WhatsApp → SMS. When a send fails on the primary channel for a retryable, channel-specific reason, the router hands the message to the next channel in the chain. It applies to every send path with no per-request flag.
Why does the fallback endpoint ignore a fallback field on the request?
By design. Fallback lives entirely in organization-level configuration so every caller gets identical behavior without remembering a flag. The send endpoint accepts no such field and silently ignores one that is passed.
Does the fallback hop re-check consent on the new channel?
Yes. When the chain falls through to a different channel, that channel's opt-out and do-not-contact check runs again before the message ships. A contact who opted out of SMS is suppressed rather than re-contacted on the SMS fallback leg.
Which channel should be the last hop in my chain?
SMS, in almost every program. It is the only channel that reaches any handset without an app installed, and every sensible chain ends there. Email and push work as fallback targets for some use cases, but neither matches SMS reach.
What failures cannot be fixed by fallback?
Terminal recipient states: a blocked WhatsApp business, a blocked Telegram bot, an opted-out contact on any channel, and dead push tokens where the app is gone. Fallback retries channel-specific failures; it does not route around a relationship or consent fact, and configuring it to do so would be a compliance violation your tenant owns.
How do I measure whether my fallback chain is working?
Count delivered per channel per destination market, never a blended figure. The fallback rate per market (deliveries on the fallback channel over total deliveries) tells you where the primary channel's reach actually holds. The fallback strategy guide walks the measurement pattern on the RCS → SMS chain, and the same split applies to every other chain.
The takeaway
Channel selection is a capability question; channel fallback is a failure-mode question, and buyers who evaluate only the first ship fragile stacks. The matrix above is the whole answer: know how each channel fails, chain it to SMS (or the next-best reachable channel) at the organization level, keep consent checks re-running on every hop, and measure per channel per market so the fallback rate stays visible. That is what a complete CPaaS channel-fallback story looks like, and it is the surface this account ships today.
Published 29 August 2026.