Rich Communication Services only earns its place when it degrades cleanly. Receiver-side RCS support is split by carrier, market, and handset, so every real traffic mix has recipients who cannot resolve an RCS session — and what happens to those recipients is a design decision, not an accident. Devotel Orbit's channel router evaluates each recipient's RCS capability at send time and falls back along the chain you define on your organization. This guide walks the configuration, a worked mixed-market blast, the analytics reads that keep the fallback honest, and the pitfalls that strand sends.
The short answer
Configure RCS-to-SMS fallback once at the organization level (Settings → Channels → Cross-Channel Fallback, rule Primary: RCS → Fallback: SMS), and the router applies it to every send path — API, campaigns, journeys, inbox replies — with no per-request flag. Split destinations into three cohorts (RCS-supported, RCS-unsupported, unknown), measure delivered-on-RCS and delivered-on-SMS as two separate numbers per market, and keep opt-out language aligned across both channels. Never disable fallback to force RCS: an unsupported recipient with no fallback receives nothing.
Where fallback happens: at send time, not at the template layer
Fallback is a routing decision made per recipient at send time — not a template variant and not something your campaign code handles. When an RCS send goes out, the router checks the recipient's capability (a cached verdict, or a live provider probe on a miss). Unsupported recipients short-circuit and the router hands the same message to the next channel in the chain. Supported recipients stay on RCS.
That placement has two consequences. First, you author content once and let the router downgrade it — the rich card renders on RCS-capable handsets, and SMS-ineligible content (carousels, suggestion chips) simply never reaches the SMS leg because the SMS path carries plain text with the chain re-checking consent before it sends. Second, there is no per-request override: the send endpoint accepts no fallback field, and one you pass is ignored. Fallback is an org-level posture precisely so every send path behaves identically without callers remembering a flag. The RCS docs describe the chain, the capability check, and the failure triggers in full; the RCS launch checklist treats defining and monitoring fallback as a go-live gate.
What you configure vs what the router auto-picks
The fallback design splits into a small decision surface you own and routing logic the product owns.
You configure:
- The fallback chain. The ordered channel list under your organization's settings —
RCS → SMS, or a longerRCS → WhatsApp → SMS. One rule per primary channel; the chain is tried in order. - Sender profiles per channel. RCS sends under your verified agent (brand, logo, verified name); the SMS leg sends under your SMS sender. A recipient who flips between the two should still recognize you — align display identity so the downgrade does not look like a different sender.
- SMS text for the downgrade. The SMS leg needs content that reads well as plain text. Keep the SMS message complete on its own; recipient-facing meaning must survive without chips and cards.
- Opt-out posture per channel. STOP keywords, quiet-hours windows, consent windows — set per channel by your tenant for your jurisdictions. The controls are yours; Orbit exposes them, the tenant sets the posture.
The router auto-picks:
- Per-recipient channel. Capability resolution at send time — supported recipients get RCS, unsupported recipients get the next chain channel.
- Consent re-check on downgrade. When the chain falls through to SMS, the router re-runs the SMS opt-out and do-not-contact check against the recipient. A contact who opted out of SMS is suppressed rather than re-contacted there.
- Failure triggers. A capability check that returns not-capable, or every RCS provider path failing for an RCS-specific reason, advances the chain. Without a chain configured, a not-capable send fails closed with a receipt that names the reason — no silent partial render, no invisible strand.
Worked example: a promo blast in mixed markets
A retailer sends a seasonal promo to 100,000 opted-in customers across three destination markets, with realistic capability mix:
| Destination | Recipients | RCS-capable | Unknown (first contact) |
|---|---|---|---|
| Market A (strong carrier + iOS RCS) | 60,000 | 78% | 4% |
| Market B (patchy carrier coverage) | 30,000 | 35% | 10% |
| Market C (no receiver-side RCS) | 10,000 | 1% | 6% |
With the chain set to RCS → SMS, the blast runs as one campaign:
- Supported cohort (roughly 58,000 recipients across the three markets) resolves an RCS session and receives the rich card with the offer and a shop-action chip. Read receipts and chip clicks come back as RCS events.
- Unsupported cohort (roughly 36,000 recipients) fails the capability check, the send short-circuits, and the router submits the SMS version under the SMS sender — after re-checking that the recipient has not opted out of SMS.
- Unknown cohort (roughly 5,000 recipients, first contact or stale capability cache) is probed live at send time and sorted into one of the two cohorts above; verdicts cache for 24 hours, so the second blast in the window costs no extra probes.
The dashboard's per-recipient message log shows which channel actually carried each send. The blended top-line "98,000 delivered, 2% suppressed" is true but useless — Market C is a 99% fallback market, and you only see that when you read the cohorts apart.
Analytics: count per-channel, never a blended number
The measurement rule is one sentence: report delivered-on-RCS and delivered-on-SMS as two separate numbers per destination market, and never publish a blended "delivered" figure for a mixed-channel blast.
- Fallback rate by market. delivered-on-SMS ÷ (delivered-on-RCS + delivered-on-SMS). Market C above sits above 95% — that market is effectively an SMS market paying RCS attention, and budget should follow that fact.
- Read and interaction rates, RCS-only. RCS read receipts and chip clicks have no SMS counterpart; blending them with SMS delivery deflates the rich channel's real performance and hides whether the rich content earns its template overhead.
- Suppression on downgrade. If the SMS opt-out re-check starts suppressing a growing share of the fallback leg, the two channels' opt-out postures have drifted — recipients consented to RCS but not SMS. That is a cohort problem to fix, not a routing defect.
A sustained fallback rate in a market is information, not failure: it means receiver-side registration never happened there, and your cost model for that market is SMS until the carriers catch up.
Common pitfalls
Disabling fallback to "force" RCS. The most damaging misconfiguration. An unsupported recipient with no fallback receives nothing — the send fails closed while your campaign dashboard still shows it attempted. Fallback being off is invisible until someone checks the receipts. Keep the chain on.
Assuming iOS support resolves the cohorts. iOS RCS support broadened reach well beyond the old Android-only footprint, but actual capability still depends on the recipient's carrier and market. "iPhone users are covered now" is not a capability signal — the per-market probe and the fallback rate are. Run a reach scan on the segment before you allocate rich-content effort.
Letting opt-out language drift between channels. Opt-out keywords, quiet-hours windows, and consent language are per-channel tenant settings. If the RCS agent says "reply STOP" while the SMS sender uses a different keyword, or quiet-hours apply on one channel and not the other, the downgrade changes the compliance posture mid-conversation. Audit both channels' settings as one posture.
Frequently asked questions
Where do I enable RCS-to-SMS fallback in Orbit?
Under Settings → Channels → Cross-Channel Fallback: add a rule with Primary set to RCS and Fallback set to SMS, and save. The org-level setting applies to every send path — API, campaigns, journeys, inbox replies — and takes effect on the next send with no redeploy.
Can I pass a fallback flag on a single send?
No. The send endpoint accepts no fallback field, and one you pass is ignored. Fallback behavior lives entirely on your organization-level configuration, so it stays consistent across every send path without callers having to remember a flag.
How do I see how many recipients fell back to SMS?
Read per-recipient channel in the message log and split campaign analytics by destination market: count delivered-on-RCS and delivered-on-SMS separately. The fallback rate per market (SMS deliveries over total deliveries) is the number that tells you where RCS reach actually holds.
What happens if I leave fallback disabled?
A recipient whose device or carrier cannot resolve an RCS session receives nothing — the send fails closed with a receipt naming the reason, instead of downgrading. Disabling fallback strands exactly the recipients fallback exists for.
Does the SMS downgrade re-check opt-outs?
Yes. When the chain falls through to SMS, the SMS opt-out and do-not-contact check runs again against the recipient. A contact who opted out of SMS is suppressed at that point rather than re-contacted on the fallback leg.
Should RCS-to-SMS fallback change my pricing model?
Both channels bill per message and the fallback draws on the same account and wallet, so a downgraded send is a same-domain rate shift, not a different billing model. The cost impact shows up as the per-market fallback rate, which is why that split matters. The full channel-selection comparison is in the RCS vs WhatsApp guide.
The takeaway
Fallback is a designed posture, not a safety net you hope never fires: define the org-level chain once, align sender identity and opt-out posture across both channels, split destinations into cohorts, and measure delivered-per-channel per market so the fallback rate tells you where RCS reach actually holds. The RCS launch checklist gates go-live on exactly this; the RCS docs carry the chain, capability, and analytics reference.
Published 27 August 2026.