Adding RCS to an SMS programme without running two programmes

The pitch for RCS is straightforward: the same address, richer rendering, verified sender. The delivery reality is that a meaningful share of your audience will receive SMS anyway, because their operator has not deployed it, their handset is old, or the capability check failed.

Write the SMS version of the message before the rich one. If the SMS version does not stand alone, the rich version is carrying meaning that part of your audience will never receive.

This is the same discipline as writing the plain-text part of an email first, and it fails for the same reason when skipped: the fallback gets written last, by someone in a hurry, and it shows.

RCS is not a channel you migrate to. It is a capability that some of your recipients have on some of their devices at some moments, and the programme has to work identically for everybody else.

Whether a given number can receive RCS is a lookup, and the answer changes over time. Two consequences:

• Do not cache it forever. A number that could not receive RCS last quarter may be able to now.
• Do not block on it. If the check is slow or fails, send the SMS. A rich message that arrived late is worth less than a plain one that arrived.

Storing "this contact supports RCS" is the mistake that produces the worst failure mode: a rich message that silently does not arrive.

Capability changes when someone changes handset, changes carrier, moves country, or turns the feature off. A cached flag is stale within weeks. Check at send time, accept the extra call, and treat an unknown answer as no.

Anything with a next action. A delivery notification with a tracking button, an appointment with reschedule and cancel, a payment with a pay-now action. The rich render collapses a multi-step journey into one.

Anything where identity matters. A verified sender badge is the closest thing to solving the phishing problem SMS has never solved. If your messages are the ones criminals imitate, that alone can justify the work.

One-time codes. A code is six digits. Rich formatting adds nothing, the recipient wants it fast, and OTP is a large share of A2P volume — which is why the transition to RCS looks slower in aggregate than it does in any individual use case.

Anything you send at broadcast volume. Richer format does not make an unwanted message wanted; it makes it more conspicuous.

Do not compare RCS recipients against SMS recipients. They are different populations — RCS reach skews toward newer handsets and better-served markets, and that difference alone will produce 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.

Two content variants per message, two sets of previews to review, two failure modes to monitor, and a capability lookup in the send path. It is not a large cost, but it is not zero, and it recurs for every message you add.

Budget for the second programme, because you are running one.

Design the SMS version first and completely. Check capability at send time. Apply RCS where the message replaces an interaction. Measure with a holdout inside the capable population. And price the two-variant maintenance, because that is the real cost.