Fallback is the mechanism that makes an RCS-first programme safe to adopt before every customer is RCS-ready. It answers the objection every marketing team raises first, which is what happens to the people who cannot receive it. The answer is that they still get the message, in the format their phone supports, without anyone building a parallel campaign. It is also why what RCS messaging is can be answered without a reach caveat attached.
What happens at send time
The sequence is short and entirely invisible to both sides.
- You submit one message to one audience, with fallback switched on for that send: the
fallbackToSmsflag on an API send, the fallback steps on a blast. - The platform checks each destination number's capability, which is a live lookup rather than a stored guess, because capability changes as people change device, carrier, or settings.
- RCS-capable numbers receive the rich message: verified sender, images, rich cards, suggestion buttons.
- Everyone else receives a degraded but coherent version over SMS, or MMS where the message carries media.
- Delivery results come back tagged with the channel each message actually went out on.
There is a second kind of fallback worth knowing about. A number can be RCS-capable and the RCS delivery can still fail, for example if the handset never comes online within the message's time-to-live. Falling back in that case has to be driven by delivery state, not by a timer alone, or the customer can end up with the same message twice. The safe sequence is:
- Send the RCS message and wait for its DELIVERED receipt for a set window that suits the message (minutes for a passcode, longer for a promotion).
- If no receipt arrives, revoke the RCS message before doing anything else. Google's RBM best practices describe revoking an undelivered message so it cannot arrive late.
- Send the SMS version only if the revoke succeeds. A failed revoke usually means the RCS message was delivered in the meantime, so sending SMS as well would duplicate it.
- Key every fallback on the original message ID, so a retried job or a late receipt cannot trigger a second SMS for the same message.
When you evaluate a platform, ask which of these steps it performs for you on each send path (API, campaigns, bot replies) and which you configure, and check the answer against the delivery events it actually reports.
What a rich message looks like when it degrades
This is where most of the design work is, and it is worth doing deliberately rather than leaving to a default. A rich card has an image, a headline, a description, and buttons. SMS has none of those things. So the fallback version has to carry the same intent in text: the core message survives, and any suggested action becomes a link.
The practical rule is to write the SMS version as a real message rather than as a stripped card. If the RCS message says "Your order shipped" with a Track button, the SMS should say "Your order shipped. Track it: [link]", not "Your order shipped." with the action silently gone. Check the fallback copy in preview before every campaign, because the failure mode is quiet: the message arrives, it just does nothing.
What fallback does to your bill
Billing follows actual delivery. RCS rates apply to messages delivered as RCS, and carrier SMS or MMS rates apply to the rest. This is exactly why the delivered-as breakdown matters: without it, you cannot reconcile an invoice, and you cannot tell whether your RCS share is growing. Our published rates are on the pricing page and every line of a bill is itemised on billing transparency.
MMS deserves a specific warning here. A media-carrying message that falls back becomes MMS, which is materially more expensive than SMS. A campaign with a large image and a low RCS-capable share can therefore cost more than expected, and the fix is usually to reconsider whether the image is doing enough work to justify carrying it to non-RCS recipients.
Why registration still matters
The SMS leg of a fallback rides a registered 10-digit number, so your 10DLC brand and campaign registration is what keeps that leg deliverable. Leading with RCS does not remove the requirement, it just means fewer messages take that path. 10DLC vs RCS sets out how the two layers fit together.
- Once switched on for a send, fallback is decided per recipient by a capability check at send time, not from a stored list.
- One authored message covers both paths; rich content degrades to SMS, or to MMS when media is attached.
- Billing follows actual delivery, so a provider should report the delivered-as breakdown back to you.
- MMS fallback costs more than SMS, so heavy media on a low-RCS audience is the case to watch.
- On SimplyRCS fallback is set per send: a
fallbackToSmsflag on the API send call, up to three fallback steps (RCS, MMS, SMS) on a blast. The message report records the primary channel, the actual channel and the fallback reason for every recipient, and each leg is billed at its own published rate.