Sending RCS from a Journey

Use journeys to send RCS messages, handle replies and subscriptions for inbound keywords such as STOP and HELP, and send a fallback message on another channel when RCS cannot be delivered.

# In this article

# Before you begin

To add an RCS message tile to a journey, you need to have the following in your project:

• A message type for the RCS channel. See Message Channels and Message Types Overview for more information.

• An RCS sender in a launched state (Partially approved, Update required, or Approved). See RCS Registration Statuses.

  NOTE

  Senders in Resubmission required status are not available for use in journeys until they are resubmitted and return to an active launched state.

You can create a new RCS message template from scratch, or use an existing template that you've prepared in advance. See Creating RCS Templates for more information.

# Permissions

To add and configure an RCS message tile in a journey draft, you need the Draft Journeys, Campaigns, and Experiments project permission.

To publish or activate a journey that sends RCS messages, you also need the Manage and Launch Campaigns permission, with RCS selected as an allowed message medium. RCS uses its own message medium permission—users with SMS access cannot publish or activate journeys that send RCS messages.

To create or edit the RCS template you attach to the tile, you need the Create and Manage Templates and Creative Library permission. See RCS permissions for the full list of RCS-related permissions.

# Adding an RCS message tile to a journey

To add an RCS message tile to a journey:

1. Open the journey and drag the RCS tile into the journey canvas.

2. Configure the campaign in the tile settings. For the settings available on the RCS tile, see RCS tiles in Message Tiles.

3. Connect the RCS tile to a step above it (such as a start tile or a filter tile) so it is triggered when the condition is met.

4. Proceed to creating the rest of the journey, and remember to test before you publish.

# Using RCS across journeys

You can use RCS system events to build journey logic related to RCS. The following sections describe which events are available in each journey tile.

Journey tile	Available RCS events
Start tile (event entry source)	RCS Click (rcsClick), RCS Reply (rcsReceived)
Filter tiles and segmentation	RCS Send (rcsSend), RCS Seen (rcsSeen), RCS Click (rcsClick), RCS Send Skip (rcsSendSkip), RCS Bounce (rcsBounce), RCS Reply (rcsReceived)
Hold until (Event occurs)	RCS Seen (rcsSeen), RCS Click (rcsClick)
Hold for Reply	RCS Reply (rcsReceived)

# Filter tiles

Filter tiles support the same RCS events as segmentation. You can add event-field conditions—for example, filter on errorCode or messageStatus on an RCS Bounce event to identify users who cannot receive RCS. See Building segments for RCS events for examples.

# Start tile

On the start tile, the following RCS events are available as event entry sources:

• RCS Click (rcsClick) — enter users into a journey when they click a shortened, tracked link in an RCS message.
• RCS Reply (rcsReceived) — enter users into a journey when they reply to an RCS message.

To branch on other RCS events, such as RCS Bounce (rcsBounce), enter users into the journey and then use a filter tile.

# Hold until tile

On the hold until tile, select Event occurs to pause the journey until a user performs a specific action. These RCS events are available in the Event occurs list:

• RCS Seen (rcsSeen)
• RCS Click (rcsClick)

Other RCS events—including RCS Send (rcsSend), RCS Send Skip (rcsSendSkip), and RCS Bounce (rcsBounce)—are not available here.

Keep these behaviors in mind when you use RCS events on a hold until tile:

• RCS Seen depends on the recipient's device reporting a read receipt. Not every user generates this event. See RCS Seen in the system events guide.
• RCS Click is logged only when the recipient clicks a shortened, tracked link. Enable Shorten and track on the RCS template, or Iterable does not log click events. See RCS Click in the system events guide.

# Hold for Reply tile

The Hold for Reply tile waits for an inbound reply to a prior message. For RCS, the tile releases users when they send an RCS Reply (rcsReceived) to a prior RCS message in the journey.

When a recipient replies to an RCS message—including when they select a reply button—Iterable logs an RCS Reply (rcsReceived) event. You can use that event to enter users from the start tile, pause on Hold for Reply, or filter and segment users who have replied.

To learn more about this tile, see Hold for Reply tiles.

# Recommended journeys for RCS

Create journeys that handle fallback delivery and STOP/HELP compliance replies. These can be separate journeys. You do not need to combine them in one flow.

# Sending welcome messages for new RCS opt-ins

Send a welcome or opt-in confirmation shortly after a user subscribes. Carriers expect a single confirmation that includes the program name, frequency, data-rate disclosure, and STOP instructions. See Best Practices for RCS Compliance.

A typical flow:

• Enter users when they subscribe to the RCS message type—for example, with a start tile that uses the Subscribe to message type entry source and your RCS message type, after a Subscription Preferences tile in an opt-in journey, or from a custom event you send when they opt in on your site.
• Send the confirmation from an RCS message tile.
• Do not treat this confirmation as a transactional registered use case. If you registered a Multi-use sender, include a separate transactional example in your approval materials.

# Handling STOP and HELP replies

Iterable does not automatically process STOP, HELP, or START keywords for RCS. Use journeys to identify those replies, update the RCS subscription status, and send a confirmation message.

A STOP/HELP flow typically includes:

• Entry on reply, or a Hold for Reply after an outbound RCS send. Use a start tile with RCS Reply when you need to listen for keywords at any time. Use Hold for Reply when you are waiting for a reply in an active conversation.
• Keyword branches for STOP and HELP (and START, to support re-opt-in by keyword).
• A Subscription Preferences tile that unsubscribes (STOP) or subscribes (START) the RCS message type the user opted in to. See Subscription Preferences tiles.
• A confirmation send that includes the opt-out, opt-in, or HELP information that your compliance policy requires. For STOP, send the confirmation before the Subscription Preferences tile unsubscribes the user. For START, send it after the tile subscribes the user.

Keep these behaviors in mind:

• Keywords are lowercase in Hold for Reply. When you configure replies, Iterable converts each keyword to lowercase, so you don't need to enter different capitalizations. To match other words that users send with the same intent, add each one as a separate keyword—for example, unsubscribe, cancel, and quit in addition to stop.
• Hold for Reply is session-based. A Hold for Reply tile only waits for users already in that step, for up to 7 days. To handle STOP, HELP, or START at any time, create a separate journey whose start tile always listens for RCS Reply events.
• Match the RCS message type. The Subscription Preferences tile must update the same RCS message type you used for opt-in.

For compliance considerations, see Best Practices for RCS Compliance.

# Sending fallback campaigns for users who cannot receive RCS

Iterable does not automatically send a fallback message when RCS delivery fails. Use a journey to send a message on another channel after a failed RCS send. Iterable logs an RCS Bounce (rcsBounce) event when delivery fails.

Trigger fallback messages when a bounce includes errorCode 7002. This code indicates the recipient cannot be reached through RCS—for example, their device does not support RCS, RCS is disabled, or they are not registered to receive RCS messages. For filter and segment criteria, see Identifying users who cannot receive RCS.

A fallback journey typically includes:

• An RCS message tile for the primary send.
• A Time Delay tile with a short hold period so delivery reports can arrive before you evaluate bounce status.
• A filter tile (such as Yes/No split) on RCS Bounce with errorCode equal to 7002 to identify users who cannot receive RCS.
• A message tile that sends the fallback message from another channel.

Your own journey flow may vary. Test and validate the journey before you publish it.

# Next steps

• RCS Audience and Segmentation — build a 7002 bounce audience for fallback.
• RCS Campaign Analytics — open analytics from the RCS tile.