--- title: "Adding RCS to an SMS programme without running two programmes" summary: "Every RCS deployment is two deployments: the rich one and the SMS fallback. Designing the fallback first, checking capability at send time and measuring honestly keeps it from becoming a second programme." canonical: https://cpaas.co/en/learn/rcs-in-an-existing-sms-programme kind: use-case depth: applied origin: original published: 2026-07-29T16:26:18.899Z updated: 2026-10-14T16:26:19.531Z topics: ["RCS", "Messaging", "A2P"] language: en --- # Adding RCS to an SMS programme without running two programmes RCS Business Messaging promises the same phone number reach as SMS with richer content: a verified brand name and logo, images, carousels and suggested-reply buttons. Since Apple added RCS to iOS 18 in 2024, the potential audience has grown sharply. But the delivery reality is uneven: whether a given person receives the rich version depends on their handset, their operator, the country and whether RCS business messaging has launched there with your brand approved. A meaningful share of your audience will still get SMS. The design problem is to add RCS without ending up maintaining two programmes. ## What has to be in place - **A verified agent.** Your brand is registered as an RCS "agent" (name, logo, colours, description) through a provider, verified and approved — often per operator or per country. Google says launches it manages typically take 1–3 business days; operators that manage their own launches may need their own contact or a contract, so plan approval country by country before you launch. - **Operator and country coverage.** Business messaging depends on operators supporting it; coverage for iPhone users in particular varies by operator and market and is still expanding. - **A billing model you understand.** Google's RBM documentation distinguishes non-conversational traffic billed per message from conversational traffic billed per 24-hour conversation, with a separate model in the US; operators and providers then add their own pricing. Ask how your provider bills in each country. ```diagram:checklist # Before the first rich message A verified agent | Name, logo, colours, description — approved, often per operator or country. Plan it per country. Operator and country coverage | Business messaging depends on operators; iPhone coverage varies and is still expanding A billing model you understand | Per message, per 24-hour conversation, or a separate US model — ask, per country ``` ## Design the fallback first Write the SMS version of every message before the rich one. If the SMS version does not stand alone, the rich version is carrying meaning part of your audience will never receive. It is the same discipline as writing the plain-text part of an email first. RCS is not a channel you migrate to. It is a capability some recipients have on some devices at some moments, and the programme has to work for everyone else. ```diagram:flow # One send, two possible renderings Compose once | Write the message as SMS. Everything richer is an enhancement layered on top, never a rewrite. Check capability at send | Not at import. A number's capability changes with handsets, operators and settings. Render rich, or render plain | Same content, same call to action, same tracking. If the plain version is worse, the design is wrong. Reconcile the receipts | RCS can return read receipts, SMS does not. Two different evidence models in one report. Measure separately | Never blend the two into an average. The average describes nobody. > If you cannot delete the RCS branch and still have a working programme, you have built two programmes and are maintaining both. ``` ## Capability is a runtime decision Whether a number can receive RCS is a lookup, and the answer changes when someone changes handset, changes operator, travels or turns the feature off. - **Do not store "supports RCS" forever.** A cached flag goes stale within weeks and produces the worst failure: a rich message that silently does not arrive. - **Do not block on the check.** If it is slow or fails, send SMS. A plain message that arrives beats a rich one that arrives late. - **Treat "unknown" as "no".** Many providers can do this automatically — send RCS where possible, fall back to SMS after a timeout. Check that fallback is configurable per message type, and that it uses an SMS sender you are registered for. ```diagram:decision # At send time, rich or plain? Has the capability check come back in time? | | Send SMS — a plain message that arrives beats a rich one that arrives late Can the number receive RCS right now? ("Unknown" counts as no) | Send the rich version | Send SMS, from a sender you are registered for > Never a stored "supports RCS" flag: it goes stale within weeks, and the failure is a rich message that silently does not arrive. ``` ## Where RCS pays, and where it does not ```diagram:compare Message type | Gains from RCS | Why Delivery tracking | Substantially | A map, live status and a branded sender do real work here Appointment management | Substantially | Reply buttons remove a whole step; confirmation becomes one tap Boarding passes and tickets | Yes | Images and cards carry information a text link cannot One-time codes | Little | The message is six digits; speed and reach matter more than presentation Fraud alerts | Little | Reach and speed beat presentation, and the plain path is the reliable one Bulk promotion | Marginally | Better rendering does not fix an unwanted message > The pattern: RCS pays where the message replaces an interaction. It does not pay where the message is the interaction. ``` **Identity is a benefit of its own.** A verified sender with your name and logo is a real defence against impersonation, which SMS has never solved. If criminals imitate your messages, that alone can justify the work. One-time codes are a large share of business messaging volume, which is one reason RCS adoption looks slower in aggregate than in individual use cases. ## Measuring the difference honestly Do not compare RCS recipients with SMS recipients. They are different populations — RCS reach skews towards newer handsets and better-served markets — and that alone produces a flattering result. The honest comparison is a randomised split *within* the RCS-capable population: capable users who get rich, against capable users who get plain. Anything else measures your audience, not your message. ## A worked example A parcel carrier sends "out for delivery" notices to 2 million recipients a month. - **Setup:** agent verified in its two main countries (six weeks); SMS sender already registered. - **Message:** SMS version written first — "Your parcel from [shop] arrives today 14:00–16:00. Track or change: [link]". The RCS version adds the logo, a map card and buttons: Track, Change time, Leave with neighbour. - **Sending:** capability checked at send; unknown or slow → SMS after a short timeout. - **Test:** among capable recipients, 90% got RCS and 10% got the SMS version at random. - **Result:** the rich group changed delivery time without calling support noticeably more often, and missed deliveries fell. The team then expanded RCS for that message only; codes stayed on SMS. ```diagram:share # The carrier's test, among RCS-capable recipients Received the RCS version | 90% | Logo, map card, and Track / Change time / Leave with neighbour buttons Received the SMS version | 10% | Chosen at random — the comparison group ``` ## The operational cost nobody quotes Two content variants per message, two sets of previews to review, two failure modes to monitor, agent maintenance across countries, and a capability lookup in the send path. Not large, but not zero, and it recurs for every message you add. Budget for it. ## What to ask a provider - In which countries and on which operators can you deliver RCS business messages today — including to iPhones? - How long does agent verification take per country, and who handles operator approvals? - How do you bill RCS in each country: per message, per conversation, or something else? What happens to the price on SMS fallback? - Is fallback automatic, configurable per message, and reported separately? ## Where to go next For the background, read [what RCS changed](/en/learn/what-rcs-changed). Next in this track: [RCS adoption after iOS](/en/learn/rcs-adoption-after-ios), on what the reach numbers do and do not show. ## Sources [^1]: [Launch approval (RCS for Business)](https://developers.google.com/business-communications/rcs-business-messaging/guides/launch/launch-approval) — Google for Developers, accessed 2026-10 [^2]: [RCS Now in iOS: a New Chapter for Mobile Messaging](https://www.gsma.com/newsroom/article/rcs-nowin-ios-a-new-chapter-for-mobile-messaging/) — GSMA [^3]: [RCS for Business](https://developers.google.com/business-communications/rcs-business-messaging) — Google for Developers [^4]: [RCS for Business billing overview](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing) — Google for Developers --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.