What RCS Is, and Why the Console Was Hard
RCS is the upgrade to SMS. Instead of 160 grey characters from an unknown number, RCS lets a verified brand send rich cards, carousels, buttons, images, and read receipts from a name and logo the carrier has vouched for. It is the channel behind the branded, blue-checkmark business messages you now see in your default messaging app. The catch is everything that has to happen before that first message goes out. A brand bot is not a thing you spin up in an afternoon. It has to be created, branded, submitted for verification, validated against a carrier's technical signature, approved, and then launched on each carrier individually, in each country, each with its own pricing and rules. Google's RBM and the GSMA's RBM are different API signatures. A bot live in India is not automatically live on AT&T in the United States. Gupshup sits in the middle of that complexity as a platform, and the brief was to turn it into something a developer could drive themselves. No sales call, no solutions engineer on a shared screen. Sign up, build the bot, test it, launch it, and watch the campaign land. That is a console that has to make a genuinely multi-stage, multi-party, regulated workflow feel like a product. This case study walks the same path a user does: in the front door, through verification, into the workspace, and out to a live campaign with a report.The Spine: A Four-Stage Bot Lifecycle
Before any screen got drawn, the work was naming the journey. Every RCS bot moves through four states, in order, and they never reorder: Bot Creation, Development, Verification, Launch. That sequence became the spine of the entire product. It is the stepper at the top of the bot dashboard. It is why "My Bots" needed a Status column instead of a simple live/offline toggle. It is why there are six different dashboard layouts, one for each in-between state, so a bot that is "Verification in process" looks and reads differently from one that is "Launch Complete." A user should never have to ask where their bot is in the pipeline. The screen should already be telling them.
Anchoring the design to a lifecycle instead of a sitemap is the single decision that shaped everything downstream. Navigation, empty states, status badges, what is editable and what is locked, which support contact shows up: all of it keys off where the bot sits on that four-stage line.
Onboarding a Developer
Getting a developer from curious to set up is its own small funnel, and every extra field is a place to lose them. The onboarding splits in two: a near-frictionless front door, and a heavier details step that arrives only once the user is already invested.In the Front Door
The signup screen had one job that is easy to underrate: tell a developer what they are signing up for in a single breath. The headline does the lifting. "Get access to RBM APIs to send and receive RCS messages to and from users in over 37 countries." Next to it, the platform's actual promise in plain terms: submit your bot and brand for verification, then launch on one or more carriers.
The form itself is deliberately small. Email, a terms checkbox, create account. Everything else waits. Asking for a company address and a timezone on the first screen is how you lose a developer who just wanted to see if the thing is real.
Completing the Details
After email verification and setting a password, the heavier ask arrives, and it is framed honestly: "Please help us with a few details to get started with our RCS platform." Personal details, then business details, split into clearly labelled groups. Phone number carries an inline Verify action and a country code selector defaulted sensibly. Country, state, city, and timezone are dependent dropdowns. None of it is fun to fill in, so the design's job is to make it feel like a short, structured form rather than a wall, and to keep the "why" visible at the top.
Building and Managing a Bot
Once a developer is in, the heart of the product is a loop: create a bot, watch it through verification and launch, govern any changes to it, and test it before a rupee is spent. These are the screens where most of a user's time actually lives.Creating a Bot Is Where the Product Earns Its Keep
The "Submit Your Bot Details" flow is the densest screen in the product, and it had to stay legible while carrying a lot of regulated weight. This is where a brand's public identity gets defined, so almost every field has downstream consequences. A few design decisions I care about on this screen: The bot name has a 40-character ceiling, and the helper text says why. It is "the name of the chatbot that the user will see at the top of the message thread." The constraint is not arbitrary product policy; it is the width of a phone's conversation header. Telling the user that turns a limit into context. Brand colour is validated for contrast, not just picked. When a user chooses a colour, the form computes its contrast ratio against white and warns in line: "Selected color has a contrast ratio of 3.7:1. Please specify a color with a minimum 4.5:1 contrast ratio." Accessibility is usually the thing that gets bolted on at the end. Here it is a gate at the moment of the decision, because once the brand launches, that colour is on every message header.
The form speaks the platform's real vocabulary, carefully. Transactional versus Promotional bot type. A choice between the GSMA RBM API and the Google RBM API. A chatbot webhook with an explicit contract: it "needs to be active and should respond with a 200 OK to POST requests." These are developer truths, and hiding them would not make them go away. The design surfaces them with helper text so a first-timer is taught and an expert is not slowed down.
Universal RCS gets a live preview. RCS does not reach everyone. iPhones and older Android devices do not have it. The platform's answer is Universal RCS, an SMS fallback that gives non-RCS users an RCS-like experience. On the create screen, enabling URCS reveals an SMS content field beside a phone mockup that previews exactly what the fallback recipient will see. The fallback is a first-class part of the design, not a footnote, because for a brand it is the difference between reaching 80% of a list and reaching all of it.
The flow is a two-step stepper, RCS Bot Details then Carrier Selection, with Brand Details handled alongside, so the cognitive load is chunked rather than dumped on one page.
The second step, Carrier Selection, is its own small interface problem. A bot can launch on dozens of carriers across dozens of countries, so the picker is a two-pane filter: countries with flags on the left, a searchable, alphabetised list of that country's carriers on the right, with selected carriers shown as removable chips and a running count. The helper text removes the pressure of getting it perfect now: "you can always add more to this list at the time of launch."
Authoring Templates
A bot is the sender; templates are what it actually says. The template editor is the most "creative" surface in the product, and it pairs a form with a live phone preview so the author always sees the message taking shape as a real RCS card.
The editor handles the full richness of RCS. A template can be a single rich card or a carousel, so cards live behind tabs (Card 1, Card 2) and the preview renders them side by side exactly as a recipient would swipe through them. Each card carries a title, a description, an orientation and height, and an image or video. Text fields offer +Add Variable so a template can be personalised per recipient (a name, an order ID) rather than rewritten per send.
Below the cards sit suggestion buttons, the interactive heart of RCS. Each one has a Type of Action, and the form changes shape to match it: an Open URL action asks for a URL, a Dial action asks for a phone number with a country code, a Simple Reply just needs its reply text. The same fallback discipline from bot creation reappears here too: a "Do you want fallback SMS?" toggle with URCS SMS content, so a rich card always has a plain-text plan B.
Submitting for Verification and Listing
Creating a bot is not launching it. Between the two sits carrier verification, and this is where RCS stops being a normal SaaS product and starts being a compliance process. The "Submit Bot for Verification" flow is a four-step stepper of its own: Bot Details and Experience, Brand Details, Business Verification, Payment.
The first step alone shows how much carriers demand before they let a brand into the messaging channel. Screenshots and a demo video of the bot. A first-message URL that conforms to a strict opt-in pattern. A tester-invite URL. And a set of plain-language questions that are really policy gates: how do you obtain opt-in, what actions trigger messages, what does the bot send when a user texts STOP. Every field carries helper text explaining why the carrier needs it, because a developer who understands the requirement is far more likely to pass review on the first try than one guessing at it.
Listing a launched bot in the public bot store is a separate, lighter submission, screenshots and a long description, kept deliberately distinct from verification so the heavy compliance step is not confused with the marketing one.
The Bot Dashboard: One Screen, Six States
Once a bot exists, its dashboard is home base. The challenge here was that a single layout had to gracefully represent a bot at any point on the lifecycle, from "creation in process" all the way to fully launched and listed in the bot store.
The lifecycle stepper sits up top so state is the first thing you read. Below it, the screen is composed of status cards that each answer one question:
- API Information gives the Bot ID and Client ID with a direct link into full documentation. A developer needs these immediately and should never hunt for them.
- Verification Status carries a hard truth in soft language: to change a verified bot's brand or launch information, you contact support. Verified state is locked for a reason, and the screen says so instead of letting a user discover it through a failed edit.
- Launch Status reports the concrete fact that matters: "This bot has been launched with 2 carriers," with Suspend and Delete kept present but visually quieter than the primary actions.
- Bot Store Listing turns the last mile into a single call to action once the bot is ready.
Governance: The Change-Under-Request Model
This is the part of the system I am most proud of, because it is invisible until you need it and it solves a genuinely hard problem. A live, verified RCS bot is a regulated public identity. You cannot let someone quietly change the brand name or launch settings of a bot that carriers have already approved. But you also cannot freeze the bot forever. People legitimately need to update things. The answer in the console is a second table on "My Bots" called Change Under Request. When a user edits a live bot, the change does not take effect immediately. It becomes a request with its own status, Pending or Rejected, and its own submitted date, sitting alongside the current live version. The live bot keeps running on its approved configuration while the proposed change moves through approval separately. That one pattern reconciles two things that look contradictory: bots are editable, and bots are governed. The user gets a clear mental model. What is live is live, and what I have asked to change is tracked over here, with a status I can watch.Testing Before You Spend
Nobody should fire a campaign at a real audience without seeing the message on a real handset first. The test flow makes that the natural step rather than the responsible-but-skippable one.
A user registers test devices, picks a template, and sends it. The interesting design work is in variables. Templates have placeholders, a customer's name, an order ID, an amount, and the test flow handles three cases: a template with no variables, a template with variables filled in by hand, and a template with variables driven by an uploaded sheet for bulk testing. There is a downloadable table to structure that sheet and a preview of the filled result before anything sends.
It is the same discipline as the contrast check on the create screen. Catch the problem at the cheapest possible moment, which is before a message reaches a single real person.
Campaigns and Reporting
Templates and bots are the setup. Campaigns are the point.Scheduling and Sending
The campaign list is a straightforward, scannable table, name, run time, campaign ID, bot, template, status, with scheduling that supports both Run Now and Run Later, and confirmation dialogs that distinguish the two so an immediate send is never an accident.
The Engagement Report
The Campaign Engagement Dashboard is where the design had to make a dense pile of delivery telemetry tell a story. RCS billing and analytics are genuinely complicated: messages split across RCS and the URCS fallback, then each split into sent, delivered, and read, then user responses split again by channel, then conversion on top.
I structured the report as a funnel that reads top to bottom. Total messages sent, broken into RCS and URCS on a single stacked bar. Then delivery and read rates for each channel with the percentage stated next to the count, never one without the other. Then responses and button-level interactions. Then conversion, leads and lead-conversion rate, as the payoff metric in a donut.
Two details I insisted on:
Failure is shown honestly and specifically. A failed campaign does not just say "Failed." It says "Campaign reached 66% completion before Failure" and names the reason: "Error in Payment Processing." A status without a cause is an anxiety generator. A status with a cause is something a user can act on.
Every percentage carries its absolute number. "Delivered 15,000 (75%)." Percentages flatter and absolutes ground. Showing both is the difference between a dashboard that looks good in a screenshot and one a user can actually reason about when a number looks wrong.
The report ships in three variants for the different delivery mixes a campaign can have, RCS with URCS, and RCS with SMS fallback, because the funnel genuinely differs and pretending otherwise would mislabel the data.
Pricing and Billing
Carrier economics are the most quietly complicated part of RCS, and the console's job was to make them legible at exactly the moments a user has to reason about money.Carrier Pricing
RCS pricing is not one number. It is a matrix: per carrier, per country, per message type, split between domestic and international rates, in the carrier's local currency.
Rather than bury that in a PDF, the Pricing screen presents carriers as a browsable grid of recognisable logos, 9mobile, Airtel, AT&T, Claro, Deutsche Telekom, DOCOMO, and selecting one reveals its rate table: Rich OTP, Single Message, A2P Conversation, P2A Conversation, plus setup and annual fees, each with domestic and international columns. The user picks carriers here in the same place they understand the cost, which is exactly where a launch decision actually gets made.
Reading the Bill
Billing then mirrors that structure with a graphical view, so the spend a user sees maps directly to the carriers and message types they chose. The model stays consistent from the moment you price a launch to the moment you read the invoice.
The Admin Side: A Review Console
Everything so far is the customer's half of the product. There is a second console behind it, the one Gupshup's own reviewers and carrier-relations staff use, and it is the engine that makes the developer side's "Pending" and "Rejected" statuses mean something. Designing both halves was the only way the governance model could actually work, because a status is only as honest as the workflow that sets it.The Review Queues
The admin home for bots is built around queues, not a single list. Submissions are split into Submitted Bots, Pending for Approval by Carrier, Approved Bots, and Rejected Bots, each its own table, so a reviewer always knows what needs their attention versus what is waiting on someone else.
The detail I care about most here is the Due column on the submission queue. Each pending bot shows how long until its review is due, counting down, and turning red when it goes overdue. A review process without a clock is a review process that quietly stalls, and the brand on the other end has no idea why. Putting the SLA on the screen makes the wait everyone's shared, visible problem. The same queue pattern repeats across tabs for Bot Launch, Bot Store Listing, and Template Verification, so a reviewer learns one screen and works all four.
Reviewing a Submission
Opening a submission gives the reviewer the entire bot exactly as the developer built it, rendered read-only. Bot type, branding, colour, contacts, the RCS API and webhook, the URCS preview, and the full list of carriers the developer selected. Logo and banner are downloadable, because a reviewer often needs to check the asset itself against carrier guidelines, not just look at a thumbnail.
The submission is the same data the developer entered, presented through a reviewer's lens rather than an editor's. That symmetry was deliberate: the reviewer is looking at precisely what the developer sees, which keeps the conversation between them grounded in one shared artefact instead of two divergent ones.
Comments and Decisions
A review is rarely a clean yes or no. Usually it is "fix the logo and resubmit." So the heart of the admin console is not the Recommend and Reject buttons, it is the conversation that precedes them.
Each submission carries a ticketed comment thread with its own ID, where the reviewer and the developer talk in line, attach screenshots, and resolve issues against the actual submission. "Logo not as per guidelines, please re-upload." "Done, screenshot attached." This thread is the real mechanism behind the developer side's Change-Under-Request status: what looks like a quiet "Pending" on the customer's screen is this conversation happening on the reviewer's. Recommend, Reject, and View History sit alongside it, and every decision is kept in history so the trail of who approved what, and why, never gets lost.
Team and Roles
Reviewers and customers are not single users; they are teams. So the console carries proper role-based access: an admin invites users by email and assigns each a permission level (View or Edit) and a role (Developer, Product Manager), with the whole lifecycle of an invite, pending, active, resend, edit, remove, designed out. It is the unglamorous plumbing that decides who is allowed to press Reject, and it had to exist for the rest of the governance story to be safe.
The System Underneath
A product this size only holds together if it is built from shared parts. The console runs on a component library: one input with its label, helper, and error states; one dropdown; one table with sortable headers, status pills, row actions, and pagination; one stepper; one set of confirmation and success dialogs; one status-badge vocabulary used identically on every screen. That consistency is what lets the product carry so much complexity without feeling heavy, and it is what lets the developer console and the admin console feel like one product rather than two. A status pill means the same thing on My Bots, on the bot dashboard, on the campaign list, and in the reviewer's queue. A table behaves the same way whether it is listing bots, templates, devices, campaigns, or submissions awaiting review. Once a user learns one surface, they have learned them all.Platform Evolution
Lifecycle
The four-stage spine
Naming the bot lifecycle, Creation, Development, Verification, Launch, before any screen. It became the backbone for navigation, status, locking, and the six dashboard states.
Onboarding
Self-serve front door
A near-frictionless signup, with the heavier personal and business details deferred until the developer is already invested.
Build
Bot creation, templates, testing
The dense bot-creation form with contrast-gated branding and a Universal RCS preview, the rich-card and carousel template editor, and on-device testing before a rupee is spent.
Governance
Verification and Change-Under-Request
The four-step carrier-verification submission, plus the model that keeps a live bot both editable and governed by tracking proposed changes alongside the approved version.
Campaigns
Scheduling, reporting, billing
Run-now/run-later campaigns, the top-to-bottom engagement funnel across RCS and URCS with absolutes beside every percentage, and the carrier pricing and billing matrix.
Admin
The internal review console
The second console behind it: reviewer queues with SLA due-date clocks, read-only submissions, ticketed comment threads, and role-based access that make the developer-side statuses real.
Lessons
- Design the lifecycle before the screens. Naming the four bot states up front gave every later screen a backbone. Navigation, status, locking, and empty states all fall out of "where is this bot on the line." Starting from a sitemap instead would have produced a pile of pages with no spine.
- Surface the hard truths, do not hide them. Webhooks needing a 200 OK, verified bots being locked, the GSMA-versus-Google API choice. These are real and unavoidable. Helper text turns each one from a trap into a lesson.
- Catch problems at the cheapest moment. Contrast validated at colour-pick time. Templates tested on real devices before a campaign. A confirmation that distinguishes Run Now from Run Later. Every one of these moves an error to the point where it costs the least.
- A percentage without its absolute is half a number. The engagement report shows both, always. It is the difference between a dashboard that demos well and one a user can trust when a figure looks off.
- "Editable" and "governed" are not opposites. The Change-Under-Request model let live bots be both. The trick was making the live version and the proposed change visibly separate, each with its own status.
- A status is only as honest as the workflow behind it. "Pending" on the developer side means nothing unless a reviewer somewhere has a queue, an SLA clock, and a comment thread. Designing both consoles together is what made the governance model real instead of decorative.
FAQ
Rich Communication Services is the upgrade to SMS: verified brands send rich cards, carousels, buttons, and images from a named, logo'd, carrier-approved sender, with delivery and read receipts. It is the channel behind branded business messages in your default messaging app.
An RCS bot is a regulated public identity. It has to be created, branded, verified, validated against a carrier's API signature, approved, and then launched on each carrier and in each country individually. The console's job was to make that real multi-stage, multi-party process feel like a single coherent product rather than a paperwork maze.
RCS does not reach every device, iPhones and older Android phones do not have it. URCS is an SMS-based fallback that gives those users an RCS-like experience, so a brand reaches its whole list instead of only the RCS-capable slice. In the design it is a first-class option with its own live preview on the create screen and its own line in every engagement report.
The Submit Your Bot Details form. It defines a brand's public identity, so it carries branding assets, a contrast-validated colour, API and webhook configuration, multiple contact methods, and the URCS fallback, all on one surface. Keeping it legible while it stayed honest about its technical weight was the core challenge.
Through the Change-Under-Request model. Editing a live, verified bot creates a tracked request with its own status rather than changing the running bot immediately. The approved configuration keeps serving while the proposed change moves through approval separately, shown side by side on the My Bots screen.
Yes, and it is half the work. Behind the developer console is an internal review console for Gupshup's own reviewers: bot, brand, launch, listing and template queues with SLA due-dates, a read-only view of each submission, a ticketed comment thread with attachments where reviewer and developer resolve issues, Recommend / Reject / history actions, and role-based user management. It is the engine that makes the developer side's Pending and Rejected statuses real.
A shared component library, one input, one dropdown, one table pattern, one stepper, one set of dialogs, and a single status-badge vocabulary used identically everywhere, across both the developer and admin consoles. Learn one surface and you have learned them all, which is what lets the product carry this much complexity without feeling heavy.