How RCS Business Messaging works

RCS Business Messaging (RBM) agents communicate with users through messages, events, and requests to achieve your business goals. Whether those goals are simple (such as sending delivery notifications) or complex (such as booking a flight), agents use rich cards, media, and suggestions to guide users through fluid conversations that satisfy user and agent needs.

How it works

The flow of conversation between your agent and a user is similar to a conversation between two people, with each party taking turns speaking, listening, and responding to the other.

Your RBM agent initiates conversations with users. Users can't start conversations with your agent, but once the agent starts a conversation, the user can reply at any time.

Your agents sends the first message when it receives an external trigger that you configure. A trigger can be anything and depends on your agent's use case:

  • A package ships
  • It's time to send daily lunchtime sandwich deals
  • A user contacts customer support via chat

An external trigger activates an RBM agent

When your agent receives the trigger, the agent sends a message to the user's device with the RCS Business Messaging API. Your agent sends all messages, events, and other requests to the user through the RBM API as HTTP requests with JSON payloads. The user receives the message in the Messages app on their device.

If the device doesn't support RCS, the RBM platform returns a 404 error, and the agent should fall back to another technology, such as SMS.

The agent sends a message to the user

When the user responds to the message or triggers an event, the Messages app sends the response to Cloud Pub/Sub, which passes the information back to your agent. Cloud Pub/Sub sends all user messages, events, and other requests to your agent as JSON.

The user sends a message to the agent

After your agent receives the message, it decodes the JSON and parses the response. Using internal logic, or relying on a natural language understanding (NLU) module like Dialogflow, your agent decides on a response to the user's message and sends the response to the user's device through the RBM API.

RBM diagram

The conversation continues between your agent and the user until it reaches an intended conclusion or the user stops responding.

Example

The following example shows a simple scenario where a user asks for a weather update.

  1. Your agent receives a trigger from an external service indicating that a user requested a weather update.
  2. Your agent sends a message to the user acknowledging the user's request and asking for the user's location.
  3. In the Messages app, the user reads the message and responds with their address.
  4. Your agent processes the response, fetches weather information, creates a conversational message, and sends the information to the user. Additionally, your agent asks if the user also wants weather information for another location.
  5. The user reads the messages and thanks the agent.
  6. Your agent acknowledges that the user didn't request additional information and ends the conversation.

Encryption

Messages sent between users and agents are encrypted between RBM agents and Google servers and between Google servers and users' devices. Agents can't use their own encryption keys because Google needs to scan messages for malicious content to protect all users and businesses.

Messages received on users' devices are encrypted by any device-wide encryption that users have configured for their devices, and Google deploys on-device security models to protect message data.

What's next?

Once you're comfortable with these concepts, consider what you want your agent to do and build your first agent.