Segment user onboarding when the job, available actions, or starting data differ. If two questionnaire answers lead to the same screen and result, you don't yet need separate segments. Start with a “job — role — data — next step” matrix, then decide which question is worth asking.
A job title helps describe an audience but doesn't fully determine intent. A manager might set up the product, read a finished report, or evaluate a purchase. The journey should reflect the current work and let the person change their choice without losing data.
Separate the first jobs within an account
Suppose a company is trying a purchasing service. The requester needs to create a request, the approver needs to make a decision, and a finance employee needs to check limits. Show everyone how to create a request and some people receive instructions for someone else's work. Ask everyone to set limits and the requester encounters access restrictions before the first attempt.
For each job, describe the starting materials, action, and result. The requester has a need and an amount; the work should produce a valid request. The approver already has a link to the request and needs context for a decision. The finance employee needs a reliable budget structure. These are different starting conditions, not just different welcome text.
This hypothetical purchasing-service matrix helps determine whether separate paths are needed at all.
| Current job | Role and authority | Starting data | Next step |
|---|---|---|---|
| Create a purchase | Requester with submission rights | Item, amount, justification | Open a draft request |
| Approve a purchase | Approver for this request | Existing request and documents | Show the request and available decisions |
| Check the budget | Finance employee with access to limits | Current budget structure | Open the relevant limit or explain the preparation |
| Evaluate the service before setup | Viewer without working data | Only a question for the product | Offer a labeled example with clear limits on what it can demonstrate |
Here, “How many people are in your company?” changes none of the rows. Remove it from the start. “Create a new request or review an existing one?” is only needed without reliable context. A link to a particular request already answers it. The product must still check approval permissions separately.
Connect the start to where the person came from. An invitation to a specific task already gives a strong signal of intent. Asking “What do you want to do?” again only delays the work. A self-service signup provides less context, so a short choice of job may be justified.
Remove questions that don't change the path
Company size is useful if the answer changes how work starts. If it only serves a marketing report, don't put it before the request. The person hasn't evaluated the product yet, but the team is already collecting a full profile. Only the team understands why that helps.
Offer clear actions: “Create a request,” “Review a request,” “Set up a budget.” Don't make newcomers choose between internal module names. Test the wording with real people: can they pick the right path without an explanation and say what they expect to see next?
Don't turn the choice into a fixed role assignment. Access decisions must follow product rules and the person's authority, not an answer in a welcome questionnaire. You can recommend a path without granting access. If someone chooses an unavailable task, explain who can help obtain permission and what they can do now.
Keep common steps and access conditions
The general B2B team onboarding journey needs to preserve handoffs between roles. Some actions are genuinely common: accept access terms, open the right organization, and confirm that the data belongs to the right company. They don't need separate versions without a reason. The cost of branching is worth paying only where it helps people do different work.
In the Participation Studio case study, researchers describe users bypassing a general setup journey to pursue their own specific task. The source supports studying intent; it doesn't prove every product needs a questionnaire or complex personalization. Sometimes changing the entry from an invitation and removing an unnecessary common screen is enough.
Draw a short map: common entry, divergence point, different first results, and the route back to the normal interface. Name a content owner and availability conditions for each branch. A similar check applies when choosing an announcement audience: interest and access don't automatically coincide. If a branch differs only by the job title in its heading, you probably don't need to create it yet.
Let people switch jobs and continue working
Someone may misunderstand a question, receive a new task, or work in several roles at once. The journey should let them return to the choice without losing data. Moving from request creation to the budget shouldn't clear the purchase description already entered. That small detail quickly turns “personalization” into a source of irritation.
Don't hide the other capabilities forever. A recommended start helps set the order but doesn't need to change the whole product's navigation. Keep other tasks accessible and explain which require additional rights. This matters particularly in small companies, where one person performs several functions.
Check the return visit too. If a user has already created a request, its status matters more on their next visit than repeating the welcome choice. If an approver arrives from a new link, open the related work. Product state should carry more weight than an answer given at signup a month ago.
Check the result of each branch and the whole account
For requesters, measure valid request submission; for approvers, a decision made with sufficient context; for finance employees, checking or setting a limit. Fix the window and eligible audience for each branch. A user with no request to review cannot fail the approver journey: the condition for acting doesn't exist yet.
Track the overall account result alongside these measures, such as the first completed purchasing cycle. The rules for activation of an account with several roles help keep people and teams distinct. This prevents improvements to individual branches at the expense of handoffs. If requesters submit faster but approvers lose the request because the invitation is unclear, team onboarding still isn't working.
With a small flow, start with observations rather than a dozen separate experiments. Walk through each branch with someone who has the corresponding job and check their understanding and the handoff points. For measuring return, PostHog recommends defining the initial and return events explicitly; in your analysis these should also match the role, not just any visit.
Test the choice language with participants from different companies. Role names can match while authority and work differ. It's better to ask what action someone wants to take today and show the available options. If two different answers lead to the same first result, combine them. The branching stays clear to the user and doesn't require maintaining copies of identical content.
Track the share who switch paths separately. It doesn't always mean an error: someone may have finished one job and moved to another. Study early switches before the first action, returns after an unavailable step, and repeated “I don't know” answers. They can show where questions describe the product department instead of the customer's work.
Choose two jobs currently forced through the same awkward start. Split only their next step and check whether the work became easier. You don't need to complicate all of onboarding in advance: you'll have to maintain it afterward.
