What is RCS for Business? Test failure first

RCS for Business

The most useful mental model is not “SMS with pictures.” RCS for Business is a gated delivery system. Before one message reaches one person, several independent conditions can matter:

1. the business has an agent
2. the brand is verified
3. the agent is launched on the relevant carrier/network and country
4. the recipient is reachable through RCS and supports the features being used
5. the business has the required user permission
6. the message complies with use-case and opt-out rules
7. if RCS cannot deliver, the application has a safe fallback strategy

Passing one gate does not imply the others.

The agent is the business identity in the conversation

An RCS agent is the programmable entity that represents a brand. It carries the identity and messaging configuration that users see and that the API sends through.

An agent can include the brand’s name, logo and other experience metadata and is created for a declared use case. Google’s current documentation distinguishes use cases such as OTP, transactional, promotional and multi-use configurations. But creating an agent does not mean it can immediately message every RCS user. Creation is the start of onboarding, not global reach.

Launch is carrier/network specific

After creation and verification work, the agent must be approved and launched for the networks and regions where it will operate. Google’s current launch documentation describes both Google-managed and carrier-managed launches. Launch requests include countries/carriers, message triggers, interaction details, opt-out behavior and review material. The agent must demonstrate a working STOP/opt-out flow before launch. A key operational consequence is: agent created ≠ agent globally launched. An agent can be approved on one carrier or country and unavailable on another. Google’s current launch flow also contains network-specific prerequisites, including carrier-managed launch requirements in some Google-managed launch scenarios. A routing system therefore needs launch coverage data, not a single launched=true boolean.

Recipient capability is a separate gate

Even when an agent is correctly launched, a specific phone number may not currently be reachable via RCS or may not support every feature the agent wants to use.

Google recommends capability checks before interaction. The business can determine whether a user is RCS reachable and which features are supported, then adapt the message accordingly. This matters for rich content. A carousel or particular action should not be sent blindly to a device that cannot support it.

Capability can also change over time. A user might switch devices, dizable RCS, change network or move between environments. Treat capability as current routing information rather than permanent profile truth.

Rich experiences are structured, not arbitrary web pages

RCS for Business can support richer message elements such as:

• media
• rich cards with title, description and media
• carousels of rich cards
• suggested replies
• suggested actions such as opening a URL, dialing a number or interacting with another supported action

These elements allow an ecommerce brand to create interactions like product discovery, delivery choices or support menus without forcing every step into plain text.

The richer UI does not remove the need for concise conversation design. Suggested actions should map to clear next steps, and the server must still handle free-form user messages, delivery outcomes and opt-outs.

Consent and unsubscribe are part of the platform model

Google’s current RCS for Business Acceptable Use Policy requires businesses to provide notice and obtain consent before soliciting end users. It describes consent as informed, freely chosen, unambiguous/specific, revocable and recorded.

Google also requires agents to honor opt-out. Current documentation describes an Unsubscribe feature and corresponding events/keywords. The rules limit non-essential messages after unsubscribe while allowing narrower essential messages such as authentication or specifically requested service notifications where the required consent exists.

A sender cannot use a newly created agent or another promotional agent for the same brand to route around a user’s promotional opt-out. Google’s current policy includes brand-level revocation expectations for promotional agents.

Fallback needs delivery awareness

A mature RCS implementation should have a fallback plan for recipients who are not reachable by RCS or for messages that cannot be delivered.

Google recommends capability checks and, where appropriate, fallback to another channel such as SMS. But fallback must not create duplicates. A safe sequence is:

1. check whether the recipient is RCS reachable
2. send through RCS when eligible
3. wait for the relevant delivery/non-delivery signal or apply the platform’s documented delivery logic
4. use SMS fallback only when the RCS message is confirmed not delivered or otherwise safely eligible for fallback
5. reapply SMS permission, quiet-hour and sender-route rules before the fallback send

RCS permission does not automatically create SMS permission if the business’s consent model or applicable rules distinguish channels.

Verification tokens: current versus upcoming

Google has introduced verification-token documentation as part of its brand verification model. The current documentation says that certain carrier launches will require a valid verification token at a later date, with the effective enforcement date still to be announced for the upcoming requirement.

That distinction matters in 2026. Do not write “all RCS agents now universally require verification tokens at send time” if Google still documents the enforcement as upcoming or carrier-specific.

The durable product design is to store verification-token capability/state separately so enforcement can be tightened when the platform actually requires it.

Capability checks should be feature-aware

Reachability alone is not enough for a rich campaign. The device may support RCS but not every interaction the creative expects. Build the message from the capability result, not from a design-time assumption.

For example, an ecommerce carousel can degrade to a simpler rich card or plain text link when a feature is unavailable. If the user is not RCS reachable at all, the orchestration layer can consider another channel. Keep creative fallback separate from channel fallback:

• feature fallback: RCS still sends, but with a simpler supported format
• channel fallback: RCS does not send, so another channel such as SMS is considered

These have different analytics and permission implications.

Delivery and fallback need a deduplication key

When the system sends RCS and later decides whether to fall back, assign one logical communication ID across routes. If a delayed receipt arrives after SMS fallback was queued, the deduplication layer can prevent 2 messages from reaching the customer for the same event.

This is especially important for time-sensitive order notifications where duplicated “Your package is ready” messages look like separate events.

Launch coverage belongs in routing data

Represent coverage as a set of approved regions/carriers associated with the agent, not as a single yes/no status. A routing lookup can then explain a failed gate precisely: > agent verified; US launch approved on Carrier A; recipient mapped to Carrier B; RCS route unavailable. That explanation is much more actionable than a generic “RCS send failed.”

Offline RCS changes the meaning of “fallback”

Google’s current capability documentation says RCS messages can remain queued for delivery when a previously reachable device is offline, for up to 31 days under the documented conditions. That makes naive timeout fallback dangerous.

A system should not conclude “no immediate delivery receipt, therefore send SMS now” without understanding the RCS delivery state. The RCS copy may still arrive later, creating a duplicate or badly ordered message. Fallback policy should therefore distinguish at least:

• not RCS reachable / agent not launched on the user’s network: another channel may be considered immediately if its own rules pass
• RCS accepted but device offline/queued: use the platform’s delivery state and the business event’s expiry to decide whether to wait, revoke where supported, or take another documented path
• message expired or definitively failed: consider channel fallback with deduplication and permission checks

For a one-time password, a 31-day queue is useless, so the business event needs a short expiry and an immediate alternative strategy. For a non-urgent loyalty update, waiting may be reasonable. “Fallback” is therefore partly a product-SLA decision, not merely a protocol feature.

Capability results are current observations, not permanent traits

Google documents conditions around how recently a number/device has connected to RCS and notes that device/SIM changes alter capability state. Cache results for efficiency, but attach an observation time and refresh policy.

A profile field such as supports_rcs=true without freshness is misleading. The routing question is “is this user reachable for this agent, on this network, with the required features now enough for this message?”

What does this page teach beyond a generic glossary definition?

It teaches RCS for Business as 6 separate gates: agent, brand verification, network launch, recipient capability, permission and message/fallback eligibility. That model prevents the 2 most common conceptual errors: treating a created agent as globally live, and treating a verified brand as recipient consent.

Worked example

A retailer wants to send an interactive delivery message with buttons for “Leave at door” and “Change delivery day.”

• The platform checks:

• the retailer’s agent is verified
• the agent is launched on the recipient’s carrier/network
• the recipient is RCS reachable and supports the needed actions
• the retailer has permission for the requested delivery updates
• the user has not opted out of the relevant messages

If all gates pass, the RCS message is sent. If the recipient is not RCS reachable, the system can consider an SMS fallback containing a simpler delivery link. That fallback must pass its own SMS permission and route checks. The fact that the RCS agent is verified does not approve the SMS sender route, and the fact that the recipient can technically receive RCS does not establish consent.

What passes and what does not

• Google’s verification process is designed to establish that the agent represents the claimed brand and that the party managing it is authorized to do so. Verified agents can display a verification checkmark in Google Messages
• That checkmark answers a trust question for the recipient: “Has this business identity been verified?”
• It does not answer: “Did I consent to receive this promotion?” Google’s Acceptable Use Policy separately requires notice and consent before soliciting users, with consent that is informed, specific, revocable and recorded. Promotional opt-out must also be honored
• So:
• verified sender ≠ recipient consent
• The platform should keep brand verification state and user permission state in separate data structures