What is an RCS chatbot?

The important difference from a website chat widget is where it lives. A widget only exists while someone is on your site, and it disappears when they close the tab. An RCS conversation sits in the phone's normal messaging inbox alongside their friends and family, persists between sessions, and can be reopened by either side days later. That changes what the bot is for: less "answer a question while browsing", more "carry an ongoing relationship".

How the conversation is actually steered

A well-built RCS bot leans on suggested replies rather than free-form text wherever it can. A suggested reply is a chip the customer taps, and it sends a token back to your webhook rather than a sentence you have to interpret. That removes the entire class of failure where a bot misreads what someone typed.

Suggested actions do the equivalent for tasks: open a URL, dial a number, show a location, add a calendar entry, all in one tap. The design rule that follows is to reserve free text for the places where you genuinely need it, and make every predictable branch a button. RCS suggested reply examples shows the payloads.

Rules-based, AI, or both

The bot's logic can be your own code, a dialogue platform, or a language model, connected to the agent through the provider's API and webhooks. In practice most production programmes are hybrids: deterministic flows for anything involving money, identity, or a promise (order status, appointment changes, RCS payments and payment links), and a model for open-ended questions that would otherwise fall to a human.

The reason for the split is accountability rather than capability. A verified RCS agent carries your brand name and checkmark, and the carriers approve it for a specific use case, so a bot that improvises an offer or invents a policy is a brand and compliance problem, not just a bad answer. RCS and AI agents goes further into that, and which RCS platforms include an AI agent that answers only from your own content compares how each platform keeps the model inside your approved content.

What it takes to run one

• A verified RCS agent approved for the use case the bot serves. See what an RBM agent is.
• A webhook that handles inbound messages and suggestion taps, and that is idempotent, because events can retry.
• A live-agent handoff path, with a clear trigger. Bots that cannot escalate generate complaints rather than deflection.
• The same consent and opt-out handling as any other business message; a bot does not sit outside those rules.

RCS chatbot examples

Three flows that cover most of what production bots actually do. Each one is built from suggested replies rather than free text, so the tap returns a token your webhook can dispatch on directly.

Appointment confirm and reschedule. The highest-yield bot flow in the format, because it attaches to a message people already expect.

1. Outbound reminder card: appointment time, location, and three chips, Confirm, Reschedule, Cancel.
2. Confirm posts back confirm:appt_1043, you mark it confirmed and reply with a one-line acknowledgement plus an Add to calendar action.
3. Reschedule posts back resched:appt_1043, and the bot replies with the next three open slots as chips read live from your booking system.
4. A slot tap books it and confirms. Anything the bot cannot resolve offers Talk to a person and hands the thread to an agent with the transcript attached.

Order status. Replaces the single most common inbound support question.

{ "contentMessage": {
  "text": "Order #1043 shipped today, arriving Friday.",
  "suggestions": [
    { "action": { "text": "Track", "postbackData": "track:1043",
      "openUrlAction": { "url": "https://shop.example/track/1043" } } },
    { "reply": { "text": "Change address", "postbackData": "addr:1043" } },
    { "reply": { "text": "Talk to a person", "postbackData": "human:1043" } }
  ] } }

Change address is the one worth building properly: reply with a Share location action rather than asking the customer to type an address, which is where delivery exceptions come from.

Guided product finder. Two or three questions as chips, then a carousel of the matches, then one tap to the cart. Keep it to three questions. Every additional step loses a share of the people who were willing, and a bot that interrogates performs worse than one that guesses and offers to refine.

Across all three, the same rules apply. Keep money, identity and anything irreversible on a deterministic path rather than a model, since a language model that improvises a refund policy is a liability. Put Talk to a person on every flow where it is visible without scrolling. And design postbackData as intent:record, because that is what lets one handler serve every flow above without branching on message text. The field conventions are in RCS suggested reply examples, and where a model fits alongside these flows is covered in RCS and AI agents.