Ask a product team who their onboarding is for and you'll usually get a singular answer: "new users". But nobody signs up as a new user. They sign up as an IT admin who has been told to evaluate you, or an ops manager who needs one specific report by Friday, or an employee whose manager just added them to a workspace they didn't ask for.
Those three people share a product and share nothing else. They have different goals, different first actions, different definitions of success, and different reasons to abandon. Handing all of them the same five-step checklist is the most common unforced error in SaaS onboarding.
Four people, four first days
Most B2B products serve some version of these four. The labels vary; the shapes don't.
The admin
They're here to make the product safe and connected, not to use it. Their first session is SSO, provisioning, permissions, data residency, and whichever integration the business actually runs on. They will never open your dashboard. If your onboarding opens with "create your first project", you've wasted their time in the first thirty seconds — and admins are the people most likely to conclude that a product is immature.
What activation means for them: the account is configured, secure, and other people can now be let in.
The power user or analyst
They have a concrete job and a deadline. They want to get their data in and build the thing they came to build. They'll tolerate complexity — they'll actively seek it out — but they have no patience for a tour of features they didn't ask about. This is the person most likely to become your internal champion, and the one who churns fastest if the product can't do the specific thing they arrived for.
What activation means for them: they built the thing, with their real data, and it worked.
The invited end user
They didn't choose your product. Someone added them. Their motivation is low, their context is near zero, and their tolerance for setup is minimal. They need to know the three things they'll do weekly and where to find them. Everything else is noise. Onboarding designed for the buyer actively harms this person, and they're usually the majority of your seats.
What activation means for them: they completed one real task without asking a colleague for help.
The evaluator
They're comparing you to two competitors and are unlikely to configure anything properly. They want to see whether the product does the thing, ideally with a shortcut. Making them do full setup before they can see value is how you lose evaluations to whoever offered a faster path.
What activation means for them: they saw the capability that determines the decision.
Why one flow fails all four
A single linear onboarding has to be ordered somehow, so teams order it by product architecture — connect data, then configure, then create, then invite. That order is right for the admin, tolerable for the analyst, and completely wrong for the end user and the evaluator, who both need to see value before they'll invest in setup.
Worse, the compromise flow tends to converge on the lowest common denominator: a short, generic tour that offends nobody and helps nobody. The admin doesn't get the security answers they need. The analyst doesn't get to their use case. The end user gets shown administrative features they lack permission to use. Everyone completes onboarding; nobody is onboarded.
Signup-form segmentation isn't personalisation
The usual attempt at a fix is a "what best describes you?" dropdown at signup, branching into two or three variants. It helps, marginally. But it inherits two problems. First, people lie to dropdowns — they pick whatever sounds closest, or whatever gets them through fastest. Second, a branch is still a static script; it can't respond when the admin turns out to also be the analyst, which in a fifteen-person company they almost always are.
Real personalisation isn't picking one of three pre-written paths. It's building the path around what this person says they need, and adjusting when that turns out to be wrong.
Doing it properly
Role-based onboarding done well has a simple structure:
- Ask, don't infer. Open by asking what they're here to do, in their words. It takes ten seconds and beats any amount of firmographic guessing.
- Sequence by value, not architecture. Get each role to their definition of activation first; do the housekeeping around it.
- Hide what doesn't apply. An end user should never see the SSO settings walkthrough.
- Let them redirect. Roles blur constantly. If the admin says "actually, show me the reporting" the session should follow them there.
- Carry it forward. What you learn in onboarding should shape every later session, so the user never re-explains themselves.
That last point is where role-based onboarding becomes something more durable. A role isn't a one-time branch — it's context that should persist. Once you know someone is an admin who cares about provisioning, that should inform how you train them on new features six months later.
Why this pushes towards conversation
Every requirement above — ask, adapt, skip, redirect, remember — is trivial in a conversation and painful in a UI flow. Building four maintained onboarding paths in software is a serious engineering commitment, and it ossifies the moment your product changes. Asking someone what they need and responding accordingly is just... how talking works.
This is the practical case for a live voice agent handling onboarding: it can ask the role question, tailor the session around the answer, drop the irrelevant steps, follow the user when they change direction, and hand over to a human when something genuinely needs one. Four first days, from one agent, without maintaining four flows. Here's how Sonesse approaches it.
Where to start
You don't need to rebuild anything to test the premise. Take your last hundred churned trials, split them by role, and look at where each group stopped. If admins are dropping at a different step than analysts — and they will be — you've just proved that one flow was never going to work, and you know exactly which two paths to build first.
Want to see role-aware onboarding running against your own product? Book a demo.