What RCS Is
RCS is the upgrade to SMS. Instead of 160 grey characters from an unknown number, a verified brand sends rich cards, carousels, buttons and images from a name and logo the carrier has vouched for. It is the channel behind the branded, blue-checkmark business messages in your default messaging app. The catch is everything that has to happen before that first message goes out. A bot has to be created, branded, submitted for verification, validated against a carrier's technical signature, approved, 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, and the brief was to turn it into something a developer could drive alone: sign up, build the bot, test it, launch it, watch the campaign land. That means making a genuinely multi-stage, multi-party, regulated workflow feel like a product. The spine is a four-stage bot lifecycle. Every RCS bot moves through four states, in order, and they never reorder: Bot Creation, Development, Verification, Launch. That sequence became the stepper at the top of the bot dashboard, the reason "My Bots" needed a Status column rather than a live/offline toggle, and the reason there are six dashboard layouts, one per in-between state, so a bot that is "Verification in process" reads differently from one at "Launch Complete." 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: all of it keys off where the bot sits on that line.
Onboarding
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. The signup screen tells 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." The form is deliberately small: email, a terms checkbox, create account. 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.
Building a Bot
The "Submit Your Bot Details" flow is the densest screen in the product, and it had to stay legible while carrying regulated weight. This is where a brand's public identity gets defined, so almost every field has downstream consequences. The bot name has a 40-character ceiling because that is the width of a phone's conversation header, and the helper text says so, turning a limit into context. Brand colour is validated for contrast, not just picked: choosing a colour computes its contrast ratio against white and warns in line when it falls below 4.5:1, because once the brand launches that colour is on every message header. Accessibility is a gate at the moment of the decision, not a bolt-on. The form speaks the platform's real vocabulary: Transactional versus Promotional, the GSMA RBM API versus the Google RBM API, a webhook that "needs to be active and should respond with a 200 OK to POST requests." Helper text teaches a first-timer without slowing an expert.
The Bot Dashboard
A single dashboard layout had to represent a bot at any point on the lifecycle, from "creation in process" 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, status cards each answer one question. API Information gives the Bot ID and Client ID with a direct link into documentation. Verification Status carries a hard truth in soft language: to change a verified bot's brand or launch information, you contact support, and the screen says so rather than letting a user discover it through a failed edit. Launch Status reports the concrete fact that matters, "launched with 2 carriers," with Suspend and Delete kept present but quieter. Bot Store Listing turns the last mile into a single call to action. Beneath the status row sit an RCS Message Templates table and a Test Devices table with a real "No Test Devices" empty state, a better first experience than an empty grid that looks broken.
Campaigns and Billing
Campaigns are the point, and templates and bots are the setup. The campaign list is a 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 Review Console
A second console behind the developer side makes its "Pending" and "Rejected" statuses mean something. This is the one Gupshup's reviewers and carrier-relations staff use, and 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 admin home is built around queues, not a single list: 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 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. 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 moves an error to where it costs the least.
- "Editable" and "governed" are not opposites. The Change-Under-Request model let live bots be both, backed by a reviewer with a queue, an SLA clock and a comment thread. The trick was making the live version and the proposed change visibly separate, each with its own status.
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.