How does RCS routing work?

This capability-aware routing is what lets an “RCS-first with SMS fallback” program work as a single send: the system picks the best channel per recipient automatically. A good provider exposes the delivered-as-RCS-vs-fallback outcome back to you so you can measure and reconcile.

In sequence, a single send resolves like this:

1. The platform authenticates the request and confirms the agent is approved for the use case.
2. It looks up the destination’s capability, from cache if the entry is fresh, otherwise from the backend.
3. If the recipient is RCS-capable and supports the features the message needs, it routes over IP through Jibe or the carrier.
4. If they are not capable, or the message needs a feature they lack, it converts the payload and routes it as SMS or MMS.
5. If RCS delivery is accepted but then fails or expires, it retries on the fallback channel.
6. The final delivered-as channel is reported back on the event stream and on the invoice.

Step four is the one that costs money quietly. A message can be routed to fallback not because the recipient lacks RCS but because the specific message needs something they cannot render, so a carousel campaign will fall back more often than a plain text campaign to exactly the same audience list. If fallback rates jump between two sends, compare the message formats before you suspect the list.

The delivered-as outcome is also the number your finance team needs, because RCS, SMS and MMS are billed at different rates and one send can produce all three. Reconcile on the reported channel per message rather than on the count of messages submitted. SimplyRCS reports this per message and rolls it up in analytics, and the rate for each channel is published on the pricing page.