Salesforce Onboarding Redesign
Sixty minutes was way too long.
TL;DR
New SMS-Magic customers on Salesforce had to complete two separate steps — install a package in Salesforce, and create an account on our website — with no connection between them. Do it in the wrong order and the O&I team had to manually configure everything from scratch. Mixpanel showed us that the median customer was taking over 60 minutes from signup to sending their first message. I redesigned the entire onboarding flow: a unified AppExchange entry point with SSO, automatic account creation and linking, and a self-serve library of pre-built configuration templates. Time-to-first-message dropped from 60 minutes to 15.
Context
Company: SMS-Magic
My Role: Associate Product Manager — owned the Salesforce onboarding workstream
Outcome: 75% reduction in onboarding time (60 min → 15 min)
SMS-Magic is a messaging platform built for Salesforce and Zoho. A significant portion of new customers came through the Salesforce AppExchange — they'd discover the product there, install it, and then be expected to connect it to an SMS-Magic account. Simple in theory. In practice, it was a setup minefield.
The Problem
What the old flow looked like
Customers had two disconnected paths they had to complete independently:
- Install the SMS-Magic package inside Salesforce via AppExchange
- Create an SMS-Magic account on our website and manually connect it to their Salesforce org
There was no handoff between these two steps. No SSO, no automatic linking, no guided sequence. A customer could easily do them out of order — create an account first, then install the package — and when they did, the Salesforce configuration that should have been auto-applied wasn't. The platform couldn't even reliably detect whether a customer had installed the package or not.
The result: any customer who stumbled on the wrong order or missed a step ended up with a broken setup. The O&I (Onboarding & Implementation) team would get a ticket, jump on a call, and manually configure the entire Salesforce integration from scratch. A task that should have taken minutes was consuming hours — from the customer's side and ours.
How we found it
I had built the Mixpanel analytics infrastructure during my time as a Product Analyst, and one of the metrics we tracked was time-to-first-message — how long it took a new customer to go from signup to actually sending their first message. This is a direct proxy for activation: if you can send a message, the product is working.
The data was stark. Customers were taking 60+ minutes on average to get there. For a messaging platform, that's a serious activation problem. Digging into the drop-off pattern, the O&I team confirmed what the data suggested: a large share of the friction was happening at the very first step — customers getting stuck or missequencing the Salesforce setup before they'd even touched the product.
My Role
- Identified the activation problem through Mixpanel data and O&I team input
- Defined what the redesigned flow should look like end-to-end
- Wrote the PRD covering the AppExchange entry point, SSO integration, account linking logic, Workspace, and trial provisioning
- Defined the pre-built templates scope and selection criteria
- Worked with engineering and the O&I team to validate the new flow before launch
Key Decisions
1. Make AppExchange the single entry point
The core fix was structural: eliminate the two-path problem entirely. Instead of asking customers to figure out the right sequence themselves, we made AppExchange the only starting point. Clicking "Get It Now" on AppExchange would kick off a single guided flow — SSO authentication, automatic account creation or linking, Workspace setup, and trial provisioning — in one connected sequence.
This removed the order-dependency. There was now only one path, and it was the right one.
2. SSO to handle the account linking problem
The old flow required customers to manually authenticate their Salesforce account from within SMS-Magic. With SSO, the platform could identify who the customer was, check whether an SMS-Magic account already existed, and either create a new one or link to the existing one automatically. The customer didn't have to think about it.
For customers with existing accounts (Production or Sandbox), we used an API key authentication step to link accounts cleanly — no duplicate records, no broken configurations.
3. Self-serve pre-built templates instead of O&I calls
Even after fixing the installation flow, customers still needed their Salesforce environment configured with the right templates, message types, and settings before the product felt useful. Previously this was done manually by the O&I team on a per-customer basis.
I looked at what the O&I team was actually configuring across customers and identified the configurations that came up in almost every onboarding — the baseline setups that nearly every customer needed regardless of their specific use case. We packaged these as a library of pre-built templates that customers could browse and install into their Salesforce org with a single click, directly from the Workspace after installation.
Customers with more specific needs could still customise — but the most common 80% of configuration work became self-serve. The O&I team was freed from routine setups and could focus on complex, high-value implementations.
4. Workspace as the control center
The Workspace became the central hub after installation — a single place where customers could manage their production and sandbox accounts, transfer credits and sender IDs, view audit logs, and access account details. This reduced the number of support touchpoints around account management and gave customers the transparency and control that previously required a call.
What We Built
Unified AppExchange onboarding flow
AppExchange → SSO with Salesforce credentials → Account creation or linking → Workspace → One-click app installation → LMA trial provisioning. One path, fully guided.
Automatic account detection and linking
The system identifies whether a customer has an existing Production or Sandbox account and handles the linking automatically, eliminating manual API key setup errors.
Pre-built configuration template library
A curated set of the most commonly requested Salesforce configurations, available post-installation in the Workspace. Customers browse, select based on their use case, and install to their org in one click.
Workspace
Centralised account management for Production + Sandbox accounts, credit and sender ID transfers, audit logs, and consolidated account visibility.
Automated trial provisioning via LMA
Once the account is created and the app installed, the platform automatically sends a request to the License Management App to provision a trial subscription — no manual step required.
Outcome
Time-to-first-message: 60 minutes → 15 minutes (75% reduction)
The activation metric that surfaced the problem became the measure of success. Customers who previously spent an hour navigating a disconnected, error-prone setup were now sending their first message in 15 minutes.
Beyond the metric:
- O&I team was freed from routine configuration calls, reducing internal overhead on standard onboarding
- Error rate from mis-sequenced installation dropped significantly — there was now only one path to follow
- Customers could self-serve the most common setup configurations without waiting for a call
What I'd Do Differently
I'd have instrumented the old flow in more detail before redesigning it. Mixpanel told us time-to-first-message was high, and O&I confirmed where people were getting stuck — but I didn't have granular step-by-step drop-off data for the old flow before we replaced it. That made it harder to know exactly which steps were causing the most time loss. Going forward, I'd always capture detailed funnel analytics on an existing flow before changing it, even if the flow is clearly broken. It helps you prioritise which parts to fix first and gives you a cleaner before/after comparison.
The pre-built templates were a good call, but the selection criteria could have been sharper. I based the template library on what the O&I team said was most common. That was the right instinct, but "most common" and "most needed" aren't always the same thing. Some templates we included were common because customers asked for them out of habit, not because they were actually essential. In hindsight I'd have paired O&I input with usage data from existing customers to validate which configurations were genuinely driving activation vs. which were just frequently requested.