# RCS best practices
With RCS rich messaging, you can create conversational, interactive experiences that go beyond traditional SMS. This topic provides guidance for designing effective RCS messages, including suggestion strategy, rich card and carousel layout, media optimization, message expiration, fallback planning, and monitoring.
For details on individual features, see [Configuring RCS suggestions](rcs-suggestions.md), [Sending RCS rich cards](rcs-rich-cards.md), [Sending RCS carousels](rcs-carousels.md), [Configuring RCS message expiration](rcs-message-expiration.md), [Configuring per-message SMS or MMS fallback](rcs-fallback-per-message.md), and [RCS message events](rcs-events.md).
## Conversational and interactive design
RCS messages support interactive elements such as suggested replies, suggested actions, rich cards, and carousels. To use these features effectively, treat each message exchange as part of an ongoing conversation rather than a one-way notification.
Open with context and options
Include a clear greeting, state what the user can do, and provide suggested replies to guide the next step. This sets expectations and reduces friction.
Keep messages concise
Aim for fewer than 300 characters per text message. Break complex information into multiple messages or use a rich card for structured content.
Avoid dead ends
Every message should lead to a next step. Offer follow-up suggestions, a main menu option, or a path to a human agent.
Address the user directly
Use second person. Write "Your appointment is confirmed" rather than "The appointment has been confirmed."
## Suggestion strategy
Suggestions (both replies and actions) appear as interactive chips below your message. They reduce typing, increase engagement, and let you route responses through structured `PostbackData` values. For the full list of suggestion types, see [Configuring RCS suggestions](rcs-suggestions.md).
### Write concise action labels
The `Text` field has a 25-character limit. Use action-oriented language that tells the user exactly what happens on tap.
**Suggestion label examples**
| Avoid | Prefer |
| --- | --- |
| "Option 1" | "Book for Monday" |
| "Click here" | "View order status" |
| "More info" | "See pricing details" |
### Offer 3 to 5 options
Three suggestions is ideal for most interactions. You can include up to 11 suggestions per message (4 per rich card), but more than 5 options at a time tends to overwhelm users. If you need more choices, use a carousel or split the flow into multiple steps.
### Route on PostbackData
Use `PostbackData` for backend routing logic instead of parsing the display text. This approach supports localization (you can change the user-visible `Text` without modifying your routing) and provides structured context for your application.
Encode the action, entity, and context in the postback value. For example:
```
confirm_order_12345
cancel_appointment_20260615
nav_main_menu
```
Use consistent prefixes (such as `book_`, `confirm_`, `cancel_`, `nav_`) to simplify routing in your backend.
**Important**
Handle stale postbacks gracefully. A user might choose a suggestion hours after receiving it. Check that the referenced entity still exists and inform the user if the action is no longer valid.
## Rich card and carousel design
Rich cards and carousels present structured content (images, titles, descriptions, and suggestions) in a visual format. For implementation details, see [Sending RCS rich cards](rcs-rich-cards.md) and [Sending RCS carousels](rcs-carousels.md).
### Standalone rich cards
+ Use `VERTICAL` orientation for the most consistent rendering across devices.
+ Use `TALL` media height to give images adequate display space on both Android and iOS.
+ Keep title and description text concise. Some clients crop text beyond three lines.
+ URLs in the description text do not work as links on all clients. Use an `OpenUrl` suggested action instead of embedding links in descriptions.
+ Include one clear call-to-action suggestion per card. Multiple competing actions reduce conversion rates.
### Carousels
+ Place the recommended or most relevant option in the first card position. Users engage most with the first visible card.
+ Use outer (message-level) suggestions for navigation actions such as "Back to menu" or "Help." Reserve card-level suggestions for actions specific to that card.
+ Keep card content more concise than standalone cards because carousel cards have less vertical space.
+ Carousel card media height is limited to `SHORT` or `MEDIUM` (`TALL` is not supported in carousels).
+ Ensure the combined media across all cards stays under 100 MB. Optimize images before uploading.
## Media best practices
Media files (images, videos, PDFs) enhance message engagement but add payload size and rendering variability. For file format and size requirements, see [Sending rich RCS messages](rcs-rich-messaging.md).
+ Compress images before uploading. Use JPEG for photographs and PNG for graphics with transparency.
+ Keep video files under 5 MB for reliable delivery across carriers and devices.
+ Provide a `ThumbnailUrl` for video and large-file messages. Thumbnails display while the full media loads and improve the user experience on slow connections.
+ GIF animations play on Android but display as a static first frame on iOS. Do not rely on GIF animation to convey critical information.
+ Host media on HTTPS URLs or in Amazon S3 (using `s3://` URIs). All media URLs must match the pattern `^(https://|s3://).+$`.
## TTL and fallback strategy
Time to live (TTL) and fallback configuration work together to ensure your message reaches the user even when RCS delivery fails. For implementation details, see [Configuring RCS message expiration](rcs-message-expiration.md) and [Configuring per-message SMS or MMS fallback](rcs-fallback-per-message.md).
### Setting TTL values
Always set a `TimeToLive` value for time-sensitive content. Match the TTL to the content relevance window.
**Recommended TTL values by content type**
| Content type | Recommended TTL |
| --- | --- |
| One-time password (OTP) or verification code | 30 to 120 seconds |
| Flash sale notification | Duration until sale ends |
| Appointment reminder | Time until appointment |
| Delivery update | 1 to 4 hours |
**Note**
The API minimum is 1 second, but a TTL of at least 10 seconds is recommended to allow sufficient delivery time. The maximum is 172,800 seconds (48 hours).
### SMS or MMS fallback
Configure a `FallbackConfiguration` for critical messages (OTPs, order confirmations, security alerts) so the content reaches the user if RCS delivery fails or expires.
+ Set the `Channel` field to `SMS` or `MMS` depending on whether you need media in the fallback.
+ Keep the `MessageBody` within 1,600 characters (the fallback limit, which is shorter than the 3,072-character RCS text limit).
+ Test fallback delivery end-to-end by sending to a phone number that does not support RCS and verifying that the SMS or MMS message arrives.
## Monitoring and events
Use event destinations and delivery events to monitor message performance and optimize your messaging strategy. For details on event types and configuration, see [RCS message events](rcs-events.md).
+ Configure event destinations before you begin production sending. This ensures you capture delivery, read, and expiration events from the start.
+ Monitor message expiration rates to determine whether your TTL values are appropriate. A high expiration rate suggests the TTL is too short or that many recipients do not have RCS-capable devices.
+ Track read receipts for relative comparison (A/B testing) rather than as an absolute metric. Not all clients report read status.
+ Use delivery confirmation events to cancel redundant fallback timers in your application logic if you manage fallback externally.
## Device and client rendering variance
RCS messages render differently across Android and iOS clients. Design for the lowest common denominator and test on both platforms before launching a campaign.
**Rendering differences between Android and iOS**
| Feature | Android | iOS |
| --- | --- | --- |
| GIF images | Animated | Static (first frame only) |
| Link previews in text | URL anywhere in message | URL must be the last element |
| Card media heights | Respects SHORT, MEDIUM, and TALL | Might ignore the height property |
| Suggestion chip order | Preserved as sent | Might reorder chips |
Design recommendations based on these differences:
+ Use `VERTICAL` card orientation for consistent layout.
+ Place URLs at the end of text messages to ensure link previews render on iOS.
+ Do not depend on GIF animation to communicate essential information.
+ Test suggestion ordering on both platforms if the sequence is meaningful to the user flow.
## Opt-out handling
Respect user opt-out preferences immediately and consistently across all messaging channels.
+ Honor STOP and UNSUBSCRIBE keywords by ceasing all non-essential messages immediately after the opt-out request.
+ Send a brief opt-out confirmation that includes your brand name so the user knows which sender they unsubscribed from.
+ Maintain your own opt-out database and synchronize it across channels (RCS, SMS, MMS) to prevent sending on one channel after the user opted out on another.
+ Consult your legal team regarding which message types (such as OTPs or fraud alerts) might still be sent after an opt-out.
**Note**
AWS End User Messaging provides opt-out list management for SMS and MMS. For RCS, coordinate your opt-out handling with both the AWS End User Messaging opt-out lists and your own application-level records.