RCS vs SMS: what's actually different, and why it's worth a look now
RCS has been circulating in vendor decks for years, and for most of that time it had one problem: it effectively only worked on Android. A channel that reaches half your customers is a curiosity, not a channel.
That changed. So it’s worth knowing what RCS is — and more importantly what not to claim about it, because it’s easy to say one sentence too many here.
What it is, in one paragraph
RCS (Rich Communication Services) is a GSMA standard that replaces SMS inside the phone’s default messaging app. It isn’t a separate app. Your customer installs nothing, creates no account, accepts no invite — the message arrives where they’ve always received texts, except now it can carry an image, buttons, a product carousel, and your company’s name instead of an unfamiliar number.
Short version: SMS is 160 characters from an unknown number. RCS is a conversation with a signed sender.
What changed in 2026
Two things, both this year:
- 26 March 2026 — the GSMA finalised Universal Profile 4.0, the largest update to the standard in years.
- 11 May 2026 — end-to-end encryption between iPhone and Android went live in beta (iOS 26.5 plus the current Google Messages), built on Universal Profile 3.0 and the MLS protocol.
The practical upshot is simple: RCS stopped being “the Android channel”. That’s what makes it worth discussing as a route to customers rather than as an experiment.
The part to be honest about
Given headlines saying “RCS now has end-to-end encryption”, somebody will inevitably tell customers their conversations with the business are end-to-end encrypted.
They are not.
The E2EE in Universal Profile 3.0 covers P2P conversations — person to person. Business messaging (A2P), meaning anything a company sends through a gateway, is not in scope. The trust mechanism for A2P is the verified sender profile: the recipient sees a confirmed brand name and logo, not cryptographically sealed content.
That’s still worth a lot. A verified sender solves the problem SMS never solved — the customer knows they’re talking to you and not to somebody spoofing your number. But it’s a different promise from encryption, and the two shouldn’t be blurred together.
What RCS isn’t
Three mix-ups I hear most often:
It isn’t WhatsApp. WhatsApp needs an app and an opt-in to be contacted. RCS lives in the default messenger — lower barrier to entry, less control over formatting, different rules on the operator side. Chatmerce runs both channels, so you don’t have to pick one.
It isn’t a replacement for website chat. Website chat catches someone mid-purchase, looking at a product. RCS catches them later — order status, a cart reminder, an appointment confirmation. Different moments, different intent. Both make sense; not one instead of the other.
It isn’t a channel you simply switch on. Business RCS runs through a carrier or an aggregator. In Poland, Chatmerce goes through SerwerSMS — and that’s the integration work you don’t have to do yourself.
When it makes sense for you
Briefly, because this isn’t a channel for everyone:
- You have repeatable, transactional notifications that customers reply to (“where’s my order”, rescheduling, confirmations).
- You already send SMS and know it works, but the limits hurt: 160 characters, no branding, no buttons.
- Your customers are on a phone and will not install an app to talk to you.
If your customer engagement starts and ends on your website, start with the widget and come back to RCS later.
How we handle it
In Chatmerce the same agent — same prompt, same knowledge base — serves both the website widget and RCS. That’s the whole product thesis: configure once, rather than maintaining two separate bots that drift into answering the same question differently.
If you’re weighing up RCS and want to see how it would work for your case, get in touch.
A note on dates: this reflects late July 2026. RCS moves fast — iOS–Android encryption is still in beta and carrier support varies. If you’re reading this much later, check what has shifted since.