SaaS onboarding questions.
Start with what they were trying to do. Learn about the experience before suggesting the reason.
“What were you trying to do when you stopped?”
Then ask: “What got in the way?”
This opener gives a new user room to describe their goal. They might mention a technical problem, an unclear next step, or something they weren’t ready to do. Follow that answer instead of presenting a checklist of suspected problems.
Choose a follow-up from their answer
| What they describe | Ask next | What to investigate |
|---|---|---|
| A technical block | “What happened when you tried that step?” | Reproduce the error with the same device, input, or account context. |
| An unclear next step | “What did you expect to do next?” | Compare the expected next action with the screen and instructions. |
| Unclear value | “What did you hope to see or achieve first?” | Check whether setup reaches the outcome they signed up for. |
| Payment hesitation | “What made you hesitate at that point?” | Explore the payment step, expectations, and readiness before choosing a change. |
Ask one follow-up at a time. “Was adding a card the problem?” can introduce your explanation before they have described theirs. Keep the first question neutral.
Ask people who stopped and people who finished
Choose Participants who actually reached the setup flow. Keep people who stopped separate from those who completed it: a user who finished may still have struggled, while someone who never began may have had a different goal.
Use an appropriate time for your onboarding cycle. Ask while the experience is still recallable, with enough time to tell a temporary interruption from a meaningful stop. There is no universal number of days that fits every product.
If you don’t know which step they reached, ask: “How far did you get?” Don’t imply that you watched their session or know why they left.
Keep the reported reason separate from the result
Read the original answer
Keep the user’s words and the surrounding question. “Didn’t want to add my card yet” reports hesitation; it doesn’t establish how many users share it.
Clarify what they wanted first
Ask what they hoped to try. If they wanted to see their own data, the useful hypothesis may be about reaching value before a payment step.
Choose a bounded change
For example, test a path that lets users see their own data before adding a card. Compare it with the existing path using your analytics.
Check behavior as well as feedback
A reported barrier, a drop-off in analytics, and an improvement after a test are different evidence. Use them together without treating the conversation as proof of causation.
A short reply can still be useful
Don’t discard an answer because the person didn’t finish the conversation. Preserve what they said, note what remains unclear, and avoid filling the gaps with assumptions.
Compare themes with the original conversations. Keep different goals, setup stages, and customer types visible when deciding whether a pattern deserves a test.