> ## Documentation Index > Fetch the complete documentation index at: https://kero.chat/help/llms.txt > Use this file to discover all available pages before exploring further. # RCS Agent use case examples > Learn how to describe your RCS Agent use case and see examples for Transactional, Promotional, OTP and Multi-use Agents. Your RCS Agent use case explains **why you will message customers and what types of messages they will receive**. When you create an RCS Agent, Kero asks you to describe your intended messaging use case. This information helps Kero and the RCS ecosystem understand how your Agent will be used during the review and verification process. Your use case should accurately describe the messaging you intend to send once your Agent is launched. > [!NOTE] > > A good use case is specific. Explain what triggers the messages, what customers will receive, how they may interact with your Agent and how consent is managed. ## What should I include? Kero asks you three questions when creating your RCS Agent. ### 1. What actions trigger messages to users? Explain **what causes your business to send an RCS message**. For example: * A customer places an order. * A payment is received. * An appointment is booked. * A customer requests a verification code. * A customer opts in to receive promotional offers. ### 2. What types of interactions will the Agent have with users? Describe **the messages customers will receive and how they may interact with your Agent**. Consider: * What types of messages will customers receive? * Will customers be able to reply? * Will messages include suggested replies, buttons or links? * How frequently might customers receive messages? ### 3. How do you ensure consent? Explain **how customers agree to receive your messages**. Your explanation should describe: * Where consent is collected, such as a website, registration form or checkout process. * What customers are told when they provide consent. * How consent is recorded. * How customers can opt out, where applicable. For promotional messaging, make sure you explain how customers specifically agree to receive marketing communications. > [!NOTE] > > You do not need to describe every individual message you may ever send. Describe the customer journey and purpose of the messaging clearly enough for the intended use of the Agent to be understood. ## Transactional use case example Use a **Transactional** Agent when messaging relates to an existing customer relationship, service or transaction. ### Example: Order and delivery updates **Business:** Online retailer **Purpose:** Keep customers informed about orders they have placed. **Example use case:** Customers who place an order with our business will receive RCS messages relating to their order and delivery. Messages may include: * Order confirmations * Payment confirmations * Order processing updates * Dispatch notifications * Delivery updates * Collection notifications * Customer service information relating to the order Messages are triggered by events in the customer's order journey. Customers may also be able to view order information, track their delivery or contact customer support using actions within the RCS message. Customers provide their contact details during checkout and are informed that these details will be used to communicate about their order. This Agent will not be used to send marketing or promotional offers. ## Promotional use case example Use a **Promotional** Agent when the purpose of the messaging is marketing, sales or promotion. ### Example: Retail promotions **Business:** Retailer **Purpose:** Send offers and promotions to customers who have opted in to marketing communications. **Example use case:** Customers who have opted in to receive promotional messaging from our business may receive RCS messages about products, offers and promotions. Messages may include: * Special offers * Discounts * New product announcements * Seasonal promotions * Loyalty offers * Promotional campaigns Customers may be able to view products, visit our website or respond to promotional offers using actions within the RCS message. Customers provide consent by selecting an optional marketing opt-in when registering an account or completing a purchase on our website. We record their consent and only send promotional messages to customers who have opted in. Customers can opt out of promotional messaging using the unsubscribe method provided in our communications. > [!WARNING] > > Only describe a consent process that your business actually uses. If your customers opt in through a different method, explain that method instead. ## OTP use case example Use an **OTP** Agent when the Agent is specifically used for authentication or verification. ### Example: Account verification **Business:** Online service provider **Purpose:** Verify customers when they access their account or perform a protected action. **Example use case:** Customers will receive RCS authentication messages when they request verification while using our service. Messages may include: * One-time passwords * Login verification codes * Account verification codes * Password reset codes * Transaction verification codes Messages are triggered by an authentication or verification request initiated by the customer. For example: **Your verification code is 482913.** Customers provide their mobile number when registering for our service and are informed that verification messages may be sent when they access their account or request a protected action. The Agent will only be used for authentication and verification messaging. ## Multi-use use case example Use a **Multi-use** Agent when the **same Agent** needs to send both Transactional and Promotional messaging. Your use case should clearly describe both types of messaging. ### Example: Retail customer journey **Business:** Online retailer **Purpose:** Provide customers with order updates and, where customers have separately opted in, promotional messaging. **Example use case:** Customers who place an order with our business will receive RCS messages relating to their transaction. Transactional messages may include: * Order confirmations * Payment confirmations * Delivery updates * Collection notifications * Service notifications * Customer support messages These messages are triggered by events relating to the customer's order or existing service relationship. Customers provide their contact details during checkout and are informed that they will receive communications relating to their order. Customers who separately opt in to receive promotional communications may also receive marketing messages from the same RCS Agent. Promotional messages may include: * Special offers * Discounts * Product promotions * Loyalty offers * Marketing campaigns Promotional consent is collected through an optional marketing opt-in during registration or checkout. We record this consent and only send promotional messages to customers who have opted in. Customers can opt out of promotional messaging using the unsubscribe method provided in our communications. Because the same Agent will send both Transactional and Promotional messages, this is a **Multi-use** use case. > [!NOTE] > > For a Multi-use Agent, explain both messaging purposes and how consent is managed for each. > > Selecting Multi-use does not remove the requirement to obtain appropriate consent for promotional messages. ## More use case examples | Business | Example messaging | RCS Type | | - | - | - | | Restaurant | Order confirmation, preparation update and collection notification | Transactional | | Delivery service | Collection confirmation, tracking updates and delivery confirmation | Transactional | | Bank | Account notifications and transaction updates | Transactional | | Healthcare provider | Appointment confirmations and reminders | Transactional | | Retailer | Discounts, product promotions and seasonal offers | Promotional | | Loyalty programme | Rewards, member offers and promotional campaigns | Promotional | | Online service | Login and account verification codes | OTP | | Financial service | Transaction authentication codes | OTP | | Retailer | Order updates plus separately consented promotional offers | Multi-use | | Restaurant | Order updates plus separately consented special offers and promotions | Multi-use | ## Avoid vague use cases Your use case should describe what the Agent will actually be used for. Instead of: **We will use RCS to communicate with our customers.** Describe the messaging more specifically: **Customers who place an order will receive order confirmations, payment updates and delivery notifications. Messages are triggered by events relating to the customer's order.** For a Multi-use Agent, instead of: **We will send transactional and marketing messages.** Explain both journeys: **Customers will receive order and delivery notifications relating to purchases they have made. Customers who have separately opted in to marketing communications may also receive product offers and promotional messages from the same Agent.** The more clearly your use case reflects the actual customer journey, the easier it is to understand how your Agent will be used. ## Match your RCS Type to your use case Your selected **RCS Type** and your use case description should describe the same intended messaging. * Existing transaction, service or customer relationship → **Transactional** * Marketing, advertising, sales or promotions → **Promotional** * Authentication or verification → **OTP** * Transactional and Promotional messaging from the same Agent → **Multi-use** > [!WARNING] > > Do not select Multi-use simply because it appears to provide more flexibility. Select the RCS Type that accurately represents the messaging you intend to send. If you are unsure which type applies, see [RCS Agent types](https://kero.chat/help/product/channels/rcs-for-business/rcs-agent-types.md). ## Before you submit Before submitting your Agent, check that your use case: * Explains the purpose of the messaging * Identifies what triggers messages * Describes the interactions customers can expect * Gives examples of the messages customers will receive * Matches the RCS Type you selected * Explains how consent is obtained and managed * Explains promotional opt-out arrangements where applicable * Reflects how the Agent will actually be used after launch Your Agent should continue to be used consistently with the use case submitted for review. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.