Product prototype · 2025 · Klaviyo
RCS Setup
A self-serve onboarding flow that lets Klaviyo customers register, verify, and activate an RCS sender identity — reducing setup from weeks of back-and-forth to a guided in-product experience.
Summary
Executive summary
Problem
RCS unlocks richer, verified messaging than SMS, but setup traditionally required weeks of manual coordination between brands, Klaviyo, and carriers — with opaque status and heavy support load.
Approach
Designed a step-by-step in-product wizard that collects brand identity, surfaces verification requirements in plain language, and tracks carrier approval status until the sender is active.
Outcome
Reduced time-to-active from weeks to minutes for the common path, with roughly 90% initial submission success and a measurable drop in setup-related support tickets.
Problem
Diagnosis
SMS was the default channel, but carriers and platforms were moving toward RCS — richer media, verified branding, and interactive buttons. Klaviyo customers wanted access without becoming experts in carrier policy.
Customer research
Senders understood SMS; RCS terminology (agents, verification, carrier approval) read as opaque infrastructure, not product.
Support themes
Setup questions clustered around status visibility — customers did not know whether they were blocked on brand info, verification, or carrier review.
Platform strategy
RCS had to feel as self-serve as SMS onboarding, or adoption would stay limited to accounts with dedicated AM support.
Constraints
What was fixed
External approval timelines
Carrier-side verification sits outside Klaviyo's control. The UI had to set expectations, show pending state clearly, and avoid implying instant activation.
Regulatory and brand requirements
Brand name, logo, and color assets must meet carrier rules. Validation had to happen at input time, not after a failed submission.
Technical jargon
Terms like 'RCS agent' and 'sender identity' needed in-context explanation without forcing users into documentation.
Backwards compatibility
SMS senders already in production could not be disrupted. RCS setup had to be additive — opt-in, parallel, and reversible during rollout.
Principles
Design principles
01
Progress you can trust
A visible step model — brand info, verification, carrier approval, active — so users always know where they are and what happens next.
02
Validate before submit
Real-time checks on brand assets and required fields so the first submission is likely to succeed.
03
Explain the unfamiliar inline
Tooltips and short helper copy at the point of need, not a separate glossary or support article.
04
Status as a first-class surface
A dashboard for pending approvals so users do not reopen tickets to ask 'where are we?'
Recorded demo
Outcome
What shipped
The flow shipped as the primary RCS onboarding path inside Sender preferences.
- Time to active
- Weeks → minutes
- Initial submission success
- ~90%
- Support volume
- Down meaningfully
For the standard self-serve path
After inline validation shipped
Setup-related tickets in first release window
Adoption climbed as AMs could point accounts to a single in-product path instead of coordinating manual setup. The most consistent feedback was clarity — users finally understood what RCS required and where they stood in the process.
Reflection
Looking back
RCS setup is a product design problem disguised as an infrastructure problem. The hard part was not drawing the form — it was making an externally gated process feel owned by the customer. Designing for dependencies you do not control means investing heavily in status, language, and recovery paths. If I were extending this work, I would push further on proactive notifications when carrier review completes and on previewing the verified sender experience before go-live.
Available
Need something similar?
Best fit for platform UX, growth systems, internal tools, and teams that need a senior IC who can shape the problem and ship the details. I respond to most inbound within a day.