Use a 2-3 question welcome survey to personalise onboarding

Most products serve more than one kind of user. A project tool might have marketers, engineers and agencies. A fitness app might have beginners, runners and people recovering from injury. A welcome survey asks two or three quick questions right after signup and uses the answers to tailor what each person sees first: the template, the checklist, the sample content and the emails that follow. It fits SaaS products and apps with several distinct use cases or skill levels.

Why it works

A generic onboarding has to speak to everyone, so it ends up speaking clearly to no one. Users scan for the bit that applies to them and often give up before finding it. When the first screen reflects their stated goal, they see right away that the product understands their situation. The path to their first useful result gets shorter.

Answering also builds a small commitment. A user who has just said “I want to plan my team’s content calendar” is primed to do exactly that. The survey doubles as research: you learn who is signing up and why, which helps marketing, sales and product decisions.

How to do it

1. List your main user groups. Look at your best customers and group them by goal, role or experience level. Aim for three to five groups that need noticeably different first steps.
2. Decide what changes for each group. For every group, pick the template, checklist, sample data or feature to show first. If two groups would see the same thing, merge them.
3. Write two or three questions. Typical questions ask what the user wants to do, their role and their team size. Use tap-to-pick answers with icons. Avoid open text fields.
4. Place the survey right after signup. Show it before the first screen of the product, on one or two short pages. Keep a visible skip link.
5. Route each answer to a path. Load the matching template or workspace, set the checklist and preselect relevant settings. Tell users why: “Since you’re planning events, we set up an event template.”
6. Personalise the follow-up. Use the answers in your welcome emails and in-app tips. Send a marketer marketing examples and an engineer technical guides.
7. Pass answers to sales and support. Large team sizes or specific roles can trigger a sales follow-up. Support can see the user’s goal when they write in.
8. Review the answers monthly. Check activation by answer. If one group activates poorly, its path needs work. If an “Other” option gets many picks, you may be missing a group.

Example

A hypothetical online whiteboard sees that new users stare at a blank canvas and leave. It adds a welcome survey with two questions: “What will you use this for?” (brainstorming, planning a project, running a workshop, teaching) and “Are you working alone or with a team?” Each use case opens a ready-made board: sticky-note grids for brainstorming, a timeline for planning, a timed agenda for workshops. Team users see an invite option on the board, and solo users do not. The team watches activation by answer and finds the “teaching” path performs worst, so they add a lesson template library.

A mobile example: a hypothetical home workout app asks about fitness level and available time. A beginner with 10 minutes gets a short starter routine. An experienced user with 45 minutes gets a full programme. Both reach their first workout in under a minute.

Metrics to track

• Survey completion rate. The share of new users who answer all questions. A sharp drop at one question means it is confusing or too personal.
• Activation rate by answer. The share of each group that reaches your activation action. Weak groups need a better path.
• Time to first value by answer. How long each group takes to reach its first result. This should fall after personalisation.
• Activation of skippers versus answerers. If answerers activate much better, consider making the survey harder to skip. If not, your paths may be too similar.

When it backfires

• Questions that change nothing. Asking for information you never use wastes the user’s time and trust. Every question needs a visible effect.
• Too many questions. A long survey before the product feels like a form to fill in. People drop off before they ever see the product.
• Wrong paths. If a group lands on a template that does not fit its goal, the personalisation does more harm than a generic start.
• Locked choices. Users change their minds and teams change goals. Let people switch paths easily.
• Sensitive questions. Asking about income, health or age without a clear reason makes people uneasy and may raise privacy issues.

Questions people ask

How many questions should a welcome survey have?

Two or three is usually enough. Each question should change what the user sees next. If an answer would not change anything in the product, drop the question.

Should the survey be optional?

Offer a skip link and give skippers a sensible default path. Most people answer short, tap-to-pick questions, and forcing answers leads to random clicks that pollute your data.

What if users pick the wrong answer?

Let them change their choice later from settings or the onboarding checklist. Treat the survey as a starting guess that the user can correct at any time.