Guides

RCS business messaging for aggregators: agents to fallback

How an aggregator adds RCS: what an RBM agent is and how it is verified, why carriers decide launch, how SMS fallback works, RCS pricing, the partner path.

Reading time9 minPublishedUpdated
Written by the Smppcube teamEngineers building messaging platforms since 2011, not content marketers. About us →
RCS business messaging for aggregators: agents to fallback
In this guide
  1. RCS business messaging for aggregators: where you sit in the chain
  2. Agents: the verified identity that makes RCS worth selling
  3. Carriers decide launch
  4. SMS fallback: the rule that makes RCS sellable
  5. Pricing and reselling RCS
  6. What operators get from the same platform
  7. The honest counterpoint

RCS is the channel that turns a text message into a branded conversation: a verified sender with a logo, images, cards, carousels and suggested replies, delivered into the phone’s default messaging app with no install. For an aggregator it is also the channel with the most moving parts, because it involves the brand, a partner platform, Google and every carrier whose subscribers you want to reach. This guide covers RCS business messaging for aggregators end to end: what an agent is and how it gets verified, why carriers decide when you launch, how SMS fallback keeps campaigns whole, how RCS is priced and resold, and the partner path a self-hosted platform gives you.

RCS business messaging for aggregators: where you sit in the chain

RCS (Rich Communication Services) is the carrier messaging standard that succeeds SMS on modern handsets: typing indicators, read receipts, high-resolution media and group chat between people, and, for businesses, a rich A2P channel called RBM, RCS Business Messaging. RBM is what an aggregator sells. Person-to-person RCS is the carrier’s product; RBM is the business channel built on top of it.

The chain is longer than SMS. A brand wants to message its customers. An RBM partner (a platform registered with Google to create and operate agents) builds the brand’s agent and sends its traffic through the RBM API. Google’s RBM platform routes the traffic to the recipient’s carrier, either through Google’s own hub, which serves many carriers, or through the carrier’s own RCS hub where one exists. The carrier delivers to the handset. Every link in that chain has a say: the partner in whether the agent is well built, Google in whether the brand is verified, the carrier in whether the agent may launch to its subscribers.

An aggregator can sit in two places. As the RBM partner itself, operating a platform registered for the RBM API and creating agents for its own clients. Or as a reseller of an RBM partner’s platform, where the partner holds the registration and the aggregator sells and supports. The first keeps the margin and the client relationship; the second is faster to start. A self-hosted platform that is already a Google RCS partner, which is what Smppcube’s omnichannel layer ships as, is the first model with the registration work done.

Agents: the verified identity that makes RCS worth selling

On SMS a brand is a sender ID, a string that any route can spoof and that regulators fight over. On RCS a brand is an agent: a verified identity with a display name, a logo, a colour, a description, a website and a phone number, shown by the handset with a verification mark. That trust signal is the product. Recipients open a verified agent’s message the way they open a message from a contact, which is why RCS campaign engagement is measured differently from SMS.

Creating an agent is a partner-side task with a brand-side dependency. The partner platform collects the brand’s assets and details, submits the agent, and the brand’s identity is verified against public records and a brand contact who confirms ownership. Get the assets right the first time: a logo at the required dimensions, a name that matches the registered business, a privacy policy and terms URL that exist. Rejections at this stage are almost always a missing URL or a name that does not match the company registration.

An agent is also where the conversation design lives: the rich cards, carousels, suggested replies and actions (call, open URL, share location, calendar) that make RCS more than a long SMS. A client who has only ever sent text will need help here; the aggregator who provides templates for the common uses (order confirmation with a tracking card, appointment reminder with reschedule replies, OTP as a plain message with fallback) sells RCS faster than one who hands over an API and a document.

Carriers decide launch

This is the part SMS aggregators are not used to. On SMS, reaching a carrier’s subscribers is a commercial question: buy a route. On RCS, an agent must be approved for launch by each carrier whose subscribers it will message, or by the hub that carrier has delegated approval to. Some carriers approve within days through Google’s hub; some run their own hubs with their own review; some markets have carriers that have not enabled RBM at all, in which case fallback carries the traffic.

Three consequences for the aggregator’s calendar. Start launch requests for every target carrier in every target country as soon as the brand is verified, in parallel; sequential launches are the slowest possible plan. Keep a per-carrier launch status per agent in the platform, because “is RCS live for this client in this country” is a question you will be asked daily. And say it plainly on the pricing sheet: RCS agent sign-off runs on the operators’ timelines, which is exactly the wording on our own pricing page for a reason.

Carriers also set the rules of the road for their subscribers: which message categories are allowed, opt-in requirements, rate limits per agent, and in some markets content review. An aggregator that already handles A2P compliance for SMS will find the shape familiar and the details different per carrier; record them per carrier in the same place as the launch status.

SMS fallback: the rule that makes RCS sellable

Not every recipient can receive RCS. The handset may not support it, RCS may be switched off, the carrier may not have launched the agent, or the phone may simply be offline for longer than a rich message can wait. If the campaign only goes out over RCS, a share of it silently fails, and the client learns that share from their customers.

Fallback fixes this and is the reason RCS belongs on a platform that also carries SMS. The pattern:

  1. Capability check. The platform asks, per recipient, whether the number can receive RCS (the RBM API provides a capability lookup) and stores the answer with a validity window, so a campaign to 100,000 numbers is not 100,000 fresh lookups every time.
  2. Send rich where possible. RCS-capable recipients get the card, carousel or rich text.
  3. Fall back on a rule. Recipients without RCS, and recipients whose RCS message is not delivered within a threshold (minutes for an OTP, longer for a promotion), get the SMS version of the same template: a plain-text rendering you define per template, with the link that the card carried.
  4. Report the blend. Per campaign, the client sees how many went RCS, how many fell back, and the cost of each, so the value of RCS is a number and not a promise.

Because the routing layer, the templates and the ledger are shared, fallback is a rule on the campaign rather than a second integration. The WhatsApp guide describes the same chain for WhatsApp; on a platform with all three channels, a notification can try WhatsApp, then RCS, then SMS, and the client pays for whichever delivered.

Sell RCS as “rich where it can be, delivered everywhere”. The client is buying certainty; the rich card is the bonus.

Pricing and reselling RCS

RCS is priced by the carrier, or by Google on behalf of the carriers its hub serves, per market. The common shape is per message by type: a basic message (plain text, near SMS rates) and a rich message (cards, media, suggested replies) at a higher rate; some markets price per conversation or per session instead. Rates are wholesale to the RBM partner; check the current sheet for each market before you build a rate card, and expect it to change like an SMS supplier’s list does.

For the aggregator, the selling model is the one you already run for SMS. Cost per market and message type from the wholesale sheet; a sell price per client on a rate card, with tiers if you offer them; a margin floor under each row so a wholesale change never routes a client below cost; and, because fallback exists, a blended view that shows what a delivered notification actually cost across channels. Where WhatsApp charges land on your WABA and RCS charges land on your RBM partner account, both are re-billed from your own ledger with your margin visible per client, which is the entire commercial argument for one platform rather than one vendor per channel.

What operators get from the same platform

Carriers themselves are on the other side of this chain, and some want to sell RBM to the businesses in their market rather than only approve agents for others. A self-hosted platform lets an operator run the aggregator side under its own brand: agents for its enterprise customers, SMS fallback on its own network, WhatsApp beside it, and one ledger for all of it. The telecom operators page describes that deployment; the mechanics in this guide are the same, with the carrier approval step happening in-house.

The honest counterpoint

RCS is not yet SMS-universal. Handset and carrier coverage is broad on Android and growing on iPhone, but it varies by country, carrier and OS version, and in some of the markets aggregators care most about, RBM is not live at all. Launch approval is slower than any SMS route, pricing is less standardised, and the rich content that justifies the price needs design work most SMS clients have never done. The sensible plan is the fallback-first one: sell delivered notifications, make RCS the preferred channel where the capability check says yes, and let the blended report show each client what RCS is doing for them. An aggregator who launches RCS that way adds a product; one who launches it as “RCS only” adds a support queue.

QUESTIONS

What is an RCS agent in business messaging?

The verified sender identity a brand messages from over RCS: a name, a logo, a description, colours and contact details that the handset shows in the conversation, in place of a bare sender ID. An agent belongs to a brand, is created through an RBM partner's platform, and must pass brand verification and then launch approval per carrier before it can message subscribers of that carrier. Verification is what gives RCS its trust signal over SMS.

Do I need carrier approval to send RCS messages?

Yes. Unlike SMS, where a route to a carrier is a commercial contract, RCS traffic to a carrier's subscribers requires that carrier to approve the agent's launch (or to have delegated approval to a hub such as Google's). Approval runs on the carrier's timeline, typically days to weeks per carrier, and is the item that decides your calendar. Start it as soon as the brand is verified, for every carrier in every country you sell.

How does SMS fallback work with RCS?

At send time the platform checks whether the recipient's handset and carrier can receive RCS. If they can, the rich message goes out over RCS; if not, or if it is not delivered within a threshold you set, the same content is sent as SMS, as a plain-text version you define per template. Because both channels sit behind one routing layer, fallback is a rule per campaign rather than a second integration.

How is RCS business messaging priced?

By the carrier, or by Google on behalf of carriers it serves, per market. Most markets price by message type, with basic text messages near SMS rates and rich messages (cards, carousels, suggested replies) higher; some price per conversation instead. Rates are wholesale to the RBM partner, which resells with its own margin, so the RCS rate card works like the SMS one: cost per market and type, sell price per client, a margin floor under both.

All guides