View a markdown version of this page

RCS best practices - AWS End User Messaging SMS
Conversational and interactive designSuggestion strategyRich card and carousel designMedia best practicesTTL and fallback strategyMonitoring and eventsDevice and client rendering varianceOpt-out handling

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, Sending RCS rich cards, Sending RCS carousels, Configuring RCS message expiration, Configuring per-message SMS or MMS fallback, and RCS message events.

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.

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 and Sending RCS carousels.

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.

  • 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 and Configuring per-message SMS or MMS fallback.

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.

  • 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.