Plan an RCS rollout

Plan an RCS rollout from brand and agent setup to a working rich card, customer reply and configured SMS fallback.

Make the next step easier to see

Explore how an image, a recognizable sender, and a clear action could bring more context into a message.

Worked scenario: Rich messaging · Illustrative concept. The following is an illustrative application workflow, not a live result.

1. Recognize. A branded invitation gives the customer a recognizable place to begin. Observable state: Concept · Invitation.
2. Explore. A rich card puts useful visual context beside the offer. Observable state: Concept · Rich card.
3. Choose. A clear action tells the customer where to go next. Observable state: Concept · Customer action.
4. Continue. Your application owns the destination and records the customer outcome. Observable state: Collection opened.

What this changes

• For your customer: An offer with more context and a visible next step.
• For your team: A branded message connected to a useful customer action.
• Before you launch: Complete sender approval and test the required features on your launch networks and devices.

Explore the illustrative example ↗

Before you call it complete

Confirm each observable state in your own integration. The application must establish the business outcome separately from a successful API request or delivery event. Exercise the relevant unsuccessful case in the product’s working example and follow its technical references.

Start with one useful invitation

RCS is available through Bird. Prepare your brand and network approvals for the launch markets, then test the message on representative devices. Use this guide to record the launch requirements and the results of your test.

Fieldnotes wants to show its coastal collection to customers who asked for product updates. The proposed message contains one image, a short description and one collection link. The destination lets a customer view the collection without requiring a rich-card interaction. The messaging team owns permission and contact policy; the brand owner supplies sender evidence; the web team owns the collection page and its recorded outcome.

1. Define the audience. Record intended countries, networks, device/client assumptions, permission source and opt-out handling. “Has a smartphone” is not reach evidence. Start with a small explicitly authorized test audience using your configured RCS channel.
2. List required features. This concept needs a supported image/card and URL action. Mark carousels, replies or other actions optional until evidence supports them. Keep an authored plain-text alternative for a separately eligible channel.
3. Assign brand and sender work. Name the legal/brand owner, agent identity, logo/domain evidence, review status and approved network launch scope. A brand approval does not by itself prove every destination is launched.
4. Check the exact recipient requirements. Keep Bird access, sender/network launch, feature capability and customer permission as four separate decisions. Record source, date and responsible person for each. Capability can change; a campaign estimate does not certify an individual device's full feature set.
5. Choose a pilot outcome. The web team records a valid collection view, with the campaign reference and permitted measurement context. Use the Channels API message status for delivery and interactions for reads or clicks. Record a purchase in the application that completes it.

Completed planning decision: the collection concept is ready for a device test. The fictional team still needs brand and network approval for its launch markets before sending to customers. A visually complete rich card does not establish launch approval.

Connect and test your Bird channel

Open your Bird workspace and follow the RCS agent and channel setup. Create the brand's agent, provide its verification details, and connect the RCS channel to that agent.

Add your own device in the agent’s Test Agent tab and accept its tester invitation. Run the first-message walkthrough to send a card through the Channels API in Node.js, Python or cURL, open its destination and inspect its delivery and click records. For reusable content, follow the rich-message template procedure. Complete Launch Countries with the business contact, opt-in/opt-out experience and target carriers before moving the customer cohort.

Retain the sender, template, message and destination references with the test result. A failed delivery should lead back to that record, so another send is a deliberate decision.

Give unsupported and unknown reach different answers

Known unsupported recipient

A confirmed capability result lacks the required rich feature. Stop this RCS path. The messaging owner checks separate SMS permission, sender readiness and destination requirements, then decides whether an authored text invitation is appropriate. If those are absent, keep the collection available in the customer's existing app/web journey without another outbound contact. For automatic delivery fallback, enroll the RCS channel in a Bird Navigator, scope its launch countries and configure the SMS senders. The navigator records each attempted channel and the chain’s final result.

Unknown reach or launch

An unresolved capability check cannot be relabeled “unsupported phone.” Google's platform response can also reflect an agent not launched on that network. The sender owner checks launch scope; the integration owner resolves the capability result. Keep the audience segment on hold while evidence is missing. An RCS-capable device with an unlaunched sender does not pass readiness.

A contact’s RCS subscription is separate from device features and sender launch scope. The documented Journey subscription branch chooses content from a contact property; the Navigator handles delivery fallback after a failed attempt. Use the capability and fallback guide to choose the right workflow.

Do not turn silence into a second message

Suppose the pilot accepts an invitation at 10:00 but the recipient is offline. The messaging owner records the navigator message ID and the invitation’s useful deadline. Acceptance is not delivery, and a timer alone cannot prove failure. Keep observing that send instead of launching another SMS from the application.

Bird Navigator advances after an attempt reaches sending_failed or delivery_failed. Recipient opt-out or holdout rejections stop the chain. Monitor navigator.outbound for its overall outcome and navigatorData.attempts for each channel result. An RCS leg can fail while the chain succeeds through SMS; report both scopes clearly.

Keep original and alternate attempt references under one application task. Author plain SMS content with the same useful destination; a carousel cannot become a useful SMS by changing the channel name. Use a platform-specific RCS template alongside the navigator’s text body when the two routes need different content. Follow the Navigator configuration and monitoring reference.

Rehearse the readiness decision

Open the existing illustrative rich-card example. Explore the eligible concept, then select unsupported device and unknown reach: the rich action is blocked with a different next decision. Prepare the brief, enter your market, moment and alternate-route owner, and record the four prerequisites. Export the local brief. Checked boxes are your statements, not verified access or a send.

Before a real pilot, the messaging owner must replace each statement with dated evidence and a controlled test result: eligible card/action, unsupported feature, unresolved launch, expired usefulness and uncertain delivery. Stop if approval, consent, current reach or duplicate-contact ownership is missing. The platform example does not register a brand or transmit a message.

Build the complete path

Copy this record and the exported example into your rollout brief. Each unknown needs an owner and a next check.

Use case / audience / useful destination:
Countries / networks / device and client assumptions:
Permission source / preferences / opt-out handling:
Workspace / RCS channel / access-key owner:
Brand owner / agent / evidence / approval / network launch:
Required card and action features / dated capability evidence:
Unsupported result / separately eligible route / contact owner:
Unknown result / launch or capability owner / next check:
Navigator / original attempt / deadline / delivery evidence:
Alternate decision / consent / authored content / duplicate guard:
Application outcome / denominator / observation window:
Authorized pilot evidence / stop rule / owner / go or hold:

Fieldnotes' filled disposition is complete brand and network approval before customer sending. The brand owner collects sender evidence, the messaging owner retains permission and alternate-contact policy, and the web team validates the collection destination. Follow the RCS channel setup procedure to configure the approved sender.

Connect the next step

• RCS planning example: eligible, unsupported and unknown cases with a local brief.
• SMS sending procedure: a separately authorized route with its own sender and permission requirements.

Your application owns the customer relationship and business actions. Preserve the appropriate identity, consent, and outcome when you move between products.

Questions to resolve

Does RCS support mean every rich action works?

No. Record the specific features and sender/network scope needed for this experience.

Who handles people RCS cannot reach?

Configure Bird Navigator to attempt RCS before SMS, with launch-country scope, applicable preferences and content for each route. The navigator handles delivery fallback; your application owns the customer task and avoids starting duplicate sends.

Go deeper in the documentation

• First RCS send: executable card send and result inspection.
• Navigator fallback: channel order, country scope, content and attempt outcomes.
• RCS channel setup: configure your agent and channel.
• Talk to the RCS team: discuss launch markets and messaging requirements.

Explore RCS and its interactive example ↗