Role-Based Onboarding for B2B SaaS: 5 Best Routing Patterns

In B2B SaaS, the same product is used by different people. 

For instance, a developer using Stripe’s API has different needs than a finance manager checking dashboards. Or, a workspace admin in Slack has different needs than an individual contributor sending messages. 

So, if you design one-size-fits-all onboarding for all of them, your activation potential will be compromised. 

Today, we’ll cover 5 specific routing patterns from real B2B SaaS products. Each pattern fits a different product structure to help you understand better. 

Summary:
1. 5 dimensions to route on: a) Admin vs end-user, b) Technical vs non-technical, c) Individual vs team buyer, d) By industry, c) By use case. 
2. The routing question has to do real work. If the next screen looks identical regardless of the answer, cut the question. 
3. Single-action products like Loom or Calendly don’t need role-based onboarding. Don’t add it for the sake of personalization. 
4. Notion’s 3-option persona quiz is the gold standard. One intent question that branches the whole experience. 

5 Routing Patterns for B2B SaaS 

Every pattern below routes to a different dimension and B2B SaaS products usually use 1-2 of these. 

Note: Don’t try to combine all 5 because that’ll be overengineering. 

Pattern 1: Admin vs End-User Routing 

Used by: Slack, Asana, Atlassian, many enterprise SaaS 

The user who creates the workspace (admin) has different first-time needs than someone joining an existing workspace (end-user). 

Admins need to set up the workspace, configure billing, and invite their teams, while End-users need to find their team channels and start working immediately. 

Slack handles this by routing based on the action: “Create new workspace” or “Sign in to existing workspace.” 

You probably know the two paths look completely different. Admins see workspace setup, branding, and member invitation, while end-users see the existing workspace, get oriented to channels, and start sending messages. 

When to use: for any product with workspaces, accounts, or shared resources where some users create and configure while others join and use.

Routing question: “Are you creating a new workspace or joining an existing one?” 

Pattern 2: Technical vs Non-Technical Routing 

Used by: Stripe, Auth0, Twilio, many developer-tool SaaS 

Developer tools are usually used by both engineers (who write code) and non-engineers (who use dashboards, configure settings, or run reports). So, they naturally require different onboarding. 

For instance, Stripe’s onboarding branches early. Developers see API keys, code samples, and integration documentation, while non-developers (business owners signing up for Stripe) see dashboards, payment configurations, and KYC steps. The two flows do share infrastructure but they feel completely different. 

When to use: for any developer tool with both engineer and non-engineer audiences. Or, for any product where ‘do you write code’ is a meaningful split.

Routing question: “Are you here to integrate via API, or use the dashboard?” 

Pattern 3: Individual vs Team Buyer Routing 

Used by: Notion, Asana, Figma, Linear, many prosumer-to-enterprise SaaS 

Some users sign up for individual use (personal task management or individual design portfolio); others sign up evaluating for their team (team project tracking or team design system). These two intents need different onboarding because they prioritize different features. 

Notion’s persona quiz handles this elegantly: “Work / Personal / School.” The Work answer routes to team templates and collaborative features, Personal routes to individual workflows, and School routes to study templates. 

When to use: for products with both individual and team value. Or, for products where pricing, features, or templates differ by the use case.

Routing question: “Are you using this for yourself or for a team?” 

Pattern 4: Industry-Specific Routing 

Used by: HubSpot, Mailchimp, Square, Shopify 

Some products serve more than one industry with different workflows. For example, a coffee shop using Square has different needs than a hair salon using Square – the same product but with different starting templates and feature emphasis. 

HubSpot asks about industry and company size during onboarding to highlight relevant templates, workflows, and feature emphasis. 

Here’s the result: a marketing agency sees CRM workflows tuned for agency operations. Or, a SaaS company sees workflows for product-led growth. 

When to use: for products serving a few distinct industries with different workflows. If your product is general-purpose (Notion), you’ll find industry routing is less useful than use-case routing. But if your product is industry-tuned (Square for retail), it’s essential.

Routing question: “What industry are you in?” – but only if the industry changes the product experience. 

Pattern 5: Use-Case Routing 

Used by: Airtable, Miro, Zapier, most general-purpose SaaS 

You’ll find this pattern in general-purpose products that solve many problems. They benefit from asking what the user is trying to do. 

Airtable is used for CRM, project management, content calendars, and inventory tracking. As you can see, there are wildly different use cases that need different starting templates. 

Airtable asks “What do you want to build?” with options like CRM, content calendar, project tracker. The answer determines the starting template and which features to surface first. 

A user who picks CRM never sees content calendar templates; or, one who picks content calendar never sees CRM templates. 

When to use: for general-purpose products with templated workflows where the use case dramatically changes the starting experience. It’s less useful for narrow products with one obvious workflow.

Routing question: “What are you here to build / track / manage?” 

Self-Selection Question Design Rules

Your personalization might fail and you’ll waste user time if you ask bad routing questions.

Follow these simple rules and you’ll be fine: 

Rule 1: Ask Just One Question

Notion’s quiz is one question with three options. “How do you want to use Notion?” That’s it. 

Some products ask five or more questions during sign-up, including role, company size, industry, team size, and primary use case.

The result is sign-up abandonment without any proportional personalization gain. Remember, one well-designed question is more powerful than five generic ones. 

Rule 2: The Answer Must Change the Path

If you ask “What’s your role?” and the next screen looks identical regardless of the answer, cut the question. 

The point of asking is to personalize. So, if you can’t or won’t personalize, asking is friction without value. 

Ask only when the answer changes templates, defaults, feature visibility, or content. 

Rule 3: Use Plain Language

Avoid industry jargon and use the language users use about themselves. For instance, Notion asks “Work / Personal / School” – words even a 12-year-old would understand. 

On the other hand, bad questions use industry jargon: “Are you using this for B2B SaaS PLG motion or enterprise sales-led?” 

Rule 4: Limit Options to 3-5

Too many options will create choice paralysis for sure. 

If you have 10 use cases, group them into 3-5 categories. Specificity will come later in the journey. 

The first routing question is about high-level intent, not granular categorization. 

Rule 5: Make Answers Reversible 

Users sometimes pick the wrong answer or change their mind. 

We’ve noticed the best products let users switch personas mid-flow. 

Notion lets users add several workspace types after the initial answer. Locking users into the wrong path based on a 5-second decision is bad UX. 

Which Dimension Should You Route On? 

Product type	Recommended routing
Workspace-based SaaS (Slack, Asana)	Admin vs end-user
Developer tools (Stripe, Auth0)	Technical vs non-technical
Prosumer-to-enterprise (Notion, Figma)	Individual vs team buyer
Industry-tuned (Square retail, HubSpot)	Industry-specific routing
General-purpose (Airtable, Miro, Zapier)	Use-case routing
Single-action products (Loom, Calendly)	No routing needed

When Role-Based Onboarding Overcomplicates Things

Role-based onboarding isn’t applicable to these SaaS product categories: 

Single-Action Products

Loom records videos or Calendly creates booking links. For them, the activation event is the same regardless of the user’s role. 

Adding a persona quiz before “Start recording” will waste the user’s valuable time without producing any differentiation. Just give them the button. 

Products With One Dominant Use Case

Some products technically serve many use cases, but in practice, 80% of users want the same thing. 

Adding routing to differentiate the 20% creates friction for the 80%. we recommend that you default to the dominant case;i.e., offer alternatives in the product, not in onboarding. 

Early-Stage Products With Small User Bases

Building 5 personalized onboarding flows for a product with 200 users isn’t worth the engineering cost. 

Wait until you have evidence that personas have measurably different needs before you think of investing in routing. Start with one good flow and add routing later when you have the data to design it well. 

How to Build Role-Based Onboarding for B2B SaaS 

Routing is conceptually simple but engineering-heavy when implemented well. 

Layer 1: The Routing Question UX

Where does the question appear? 

Don’t put it on a separate “welcome” screen between sign-up and product. That’s fine but adds a step. 

Here’s an alternative: bake the question into sign-up itself. Slack does this with workspace creation vs joining. 

It’s best for the fastest TTV: defer the question completely, watching user behavior to auto-route, and only ask explicitly if behavior is ambiguous.  

Layer 2: The Branching Infrastructure

Every persona path needs different default content, different feature visibility, and sometimes different navigation. 

Don’t build this without a feature-flag system or a content management system. Start with one branch point and one or two personas until you have evidence that all five matter. 

Layer 3: The Measurement Infrastructure

Track the activation rate per persona separately. If admin-path users activate at 60% but end-user-path users activate at 30%, you have data to redesign the end-user path specifically. 

Without persona-level metrics, you’ll optimize the average and miss the real problems. 

Edge Cases in Role-Based Onboarding

The “I’m both” User 

Some users are both the admin and the end-user e.g. founders setting up Slack for their team are both or engineers using Stripe both write the API code and manage the dashboard. 

So, forcing them into one path will create friction. 

Here’s the fix: allow users to switch contexts after the initial routing, or design the admin path to also serve dual-role users since they need admin access and full functionality. 

The “I lied on the quiz” User 

Some users pick the wrong answer on the persona quiz. Sometimes, they do that deliberately (“I’ll just say Personal to skip the team setup”), and sometimes, accidentally.

Make the routing decision reversible and don’t lock features behind the quiz answer. Since the quiz personalizes the start, it shouldn’t constrain the user’s permanent path. 

The “I’m evaluating, not using” User 

Some sign-ups aren’t users at all but buyers evaluating for someone else. Their persona is “evaluator,” which doesn’t match the typical admin or end-user paths. 

We know many products handle this poorly because evaluators don’t fit the activation model. 

The fix is a path explicitly for evaluators that focuses on demos, sample data, and security/compliance information rather than personal activation. 

Our Role-Based Onboarding Self-Audit

Question 1: Do different user personas have measurably different activation rates? 

If yes → routing might help. If no → don’t add complexity. 

Question 2: Have you mapped which dimensions (admin/user, technical/non, etc.) actually differentiate your audience? 

If no → start here. Routing the wrong dimension wastes effort. 

Question 3: If you ask a routing question, does the next screen look meaningfully different per answer? 

If no → cut the question. The answer must change the path. 

Question 4: Is your routing question in plain language users actually use? 

If it has industry jargon → rewrite for clarity. 

Question 5: Can users change their persona/role mid-flow? 

If no → users picking wrong on the first screen are stuck. Make it reversible. 

Want a Fresh Look at Your Role-Based Onboarding? At Pixxen, we’ve designed routing flows for B2B SaaS products with admin/end-user splits, technical/non-technical splits, and use-case branching. We’ll review your existing flow and tell you whether routing is worth the engineering investment. 30 minutes, no pitch. Book a Free 30-Min Consultation

FAQs