For the complete documentation index, see llms.txt. This page is also available as Markdown.

RCS best practices

This guide collects best practices for running effective RCS campaigns and conversations with Bird: designing for a mixed Android and iOS audience, measuring results correctly, and writing conversations that users want to engage with.

Reach every recipient with a fallback

Not every device can receive RCS — some recipients have RCS disabled, unsupported devices, or carriers without RCS support. Always pair RCS sends with a fallback channel such as SMS, so those recipients still get your message. See Create an RCS lead nurture journey with a fallback.

Design for both Android and iOS

Android and iOS render RCS differently: media heights, card widths, suggestion buttons, and text truncation all behave differently on iPhone. If a meaningful share of your audience is on iOS, design templates in cross-platform optimization mode. In short:

  • Rich cards: media height Tall, up to 1 action + 3 quick replies per card, no suggestion chips under the message, and keep title plus description under ~150 characters to avoid truncation on iOS.

  • Carousels: card width and media height Medium, same per-card button limits.

  • Rich messages: quick replies only.

  • Follow the media recommendations — aspect ratios and the 5% safe zone matter more on iOS, which crops and scales media differently.

You can't tell which platform a recipient is on

There is no way to determine whether a recipient is on Android or iOS — neither before sending nor from delivery events. RCS capability lookups tell you a number can receive RCS, not which operating system or messaging client it uses.

This has two practical consequences:

  • You can't segment your audience by platform. For any broad audience, assume a mix of Android and iOS and design in cross-platform optimization mode rather than trying to send Android-optimized content to Android users only.

  • You can't split campaign metrics by platform. Differences in how the platforms report engagement (see below) can't be corrected for afterwards, because you don't know which recipients were on which platform.

Measure engagement with clicks, not reads

Delivery receipts are reliable on both platforms. Read receipts are not:

Because of this:

  • Treat read rates as a floor, not a measurement. Don't compare read rates between campaigns with different audience mixes, and don't conclude a campaign underperformed because reads are low.

  • Use clicks as your primary engagement signal. Suggestion buttons (quick replies and actions) report taps back on both platforms, so give every button a distinct payload and measure engagement from button interactions. Link clicks can be tracked with short links.

  • Replies are also platform-independent — a campaign designed to elicit a reply or button tap gives you far better data than one that relies on read tracking.

Write conversations, not app screens

RCS agents work best as focused, natural conversations — don't try to reproduce your app or website UI in a message thread, and don't build phone-tree menus where users reply with numbers. Guide users with plain language, suggestion buttons, and clear next steps.

Start strong. The first message sets expectations:

  • Greet the user and introduce your brand. If your agent has a persona, make clear it's a virtual assistant, not a real person — and never use a photo of a real person as the agent avatar.

  • Say what the agent can do, and offer suggestion buttons that lead into those capabilities.

Keep every message clear and moving:

  • Don't create dead ends — every message should offer a meaningful next step.

  • Acknowledge user input ("Got it", "Great choice!") and use markers like "Now…", "And…" to guide multi-step tasks.

  • Address the user as "you" (or by name); keep button labels within the 25-character limit.

  • Use sentence case for titles and labels, write numbers as digits, use contractions, and keep exclamation points and emoji for use cases where a playful tone fits.

  • If the conversation hands off to a person or another channel, acknowledge the transition ("Alright, your account manager will take over from here").

Use suggestions deliberately:

  • Prefer quick replies whenever a specific response is expected — free-text input is where conversations stall.

  • Keep suggestions relevant to the current message, few in number, and clearly worded.

  • Inside a rich card, suggestions should relate directly to that card's content.

Support HELP. Respond to "help" messages with a short summary of what the agent can do, plus suggestion buttons — it turns a lost user into an engaged one.

Respect opt-outs

When a user asks to stop receiving messages, honor it. Bird handles the standard keyword flow on RCS for you: inbound messages are checked against built-in compliance keywords — STOP, STOPALL, END, QUIT, CANCEL, UNSUBSCRIBE and localized equivalents (ARRET, DETENER, PARAR, 停止, and more) — and a match records the opt-out and sends a localized confirmation automatically. HELP and opt-in keywords (START, RESUME, and variants) are handled the same way, and you can add your own custom keywords per workspace.

You remain responsible for compliance overall:

  • Automatic keyword handling doesn't cover every way a user can express an opt-out — a plain-language "please stop messaging me" still needs to be honored, and market regulations (such as CTIA guidelines in the US) apply to you, not the platform.

  • If you operate in languages beyond the built-in set, add the corresponding keywords for your markets.

  • If a user deletes the conversation with your agent, treat that as the end of the engagement: they need to opt in again through another channel (a sign-up form, SMS keyword, or website opt-in) before you message them again. See Grow RCS subscribers with a sign-up form.

Make your branding display well

Your agent's logo, hero (banner) image, and brand color appear throughout the conversation UI. Set them when creating your RCS agent, and get them right the first time — agent information can't be edited after the agent is submitted for verification, and once launched, any change needs carrier re-approval.

Logo (224 × 224 px):

  • Logos are cropped into rounded squares everywhere they appear — even if your source image is rectangular. Center the logo and keep it equidistant from all four edges; a logo that fills the full width or height gets its corners cut off.

  • Avoid transparent backgrounds: a logo without sufficient contrast blends into dark-mode backgrounds. If transparency doesn't suit your logo, use a solid white background.

  • Preview the rounded-square crop before submitting with Google's logo preview tool, in both light and dark modes.

  • Verified agents automatically get a verification checkmark next to the agent name; it can't be added manually.

Hero image (1440 × 448 px, a 45:14 aspect ratio):

  • Any other aspect ratio gets cropped, usually badly — export at exactly 45:14.

  • The logo partially overlaps the hero image on the agent's info screen — keep key elements (text, faces, product shots) away from the overlap area.

Brand color:

  • The agent color is used for UI elements above your phone number in the conversation. Pick a color with at least a 4.5:1 contrast ratio against white (the WCAG minimum for text) — check it with a tool like the WebAIM contrast checker.

Contact details:

  • At least one of phone number, website, or email is required to launch, but provide all three with clear labels ("Customer care number", "ABC website") for the best user experience — this is what users see when they check whether your agent is legitimate.

  • Valid Privacy Policy and Terms of Service URLs are required for launch.

Last updated

Was this helpful?