Userback surveys can be triggered at any point in the user journey, for any purpose. The challenge is knowing when to survey, who to ask, and what question to ask. This article covers the most effective use cases for SaaS product teams, beyond the basics.
1. Post-onboarding NPS
The first 14–30 days after signup are when users form their initial impression of your product. An NPS survey at the end of this period tells you whether onboarding is working, and catches users who are already at risk of churning before they go quiet.
When to trigger: 14–30 days after signup, or after the user has completed a key onboarding milestone
Question: "How likely are you to recommend [product] to a colleague?" followed by an open-ended follow-up
What to do with results: Low scores in the first 30 days are almost always an onboarding problem, not a product problem. Read the open-ended responses for specific friction points.
💡Use User Identification to trigger this survey only for users who have actually completed the signup flow, not users who signed up but never activated.
2. Feature validation survey
Before committing to building a feature, ask users directly whether it would be useful to them. This is faster than a full research study and gives you a quantitative signal you can take into a prioritization conversation.
When to trigger: After a user interacts with the area of the product the feature would affect, or via a shareable link sent to a specific segment
Question: "How useful would [feature description] be to you?" with a 1–5 scale, plus an open-ended follow-up
What to do with results: Look at both the score distribution and the written responses. A high average score with weak written justification may indicate respondents answered positively by default. Strong written use cases are the more reliable signal.
3. Post-release CSAT
After shipping a significant feature or update, a CSAT survey targeted at users who have actually used the new functionality tells you whether it landed as intended. This is more reliable than looking at usage metrics alone, a feature can have high usage but low satisfaction.
When to trigger: 3–7 days after a release, triggered for users who have visited or used the updated area
Question: "How satisfied are you with [feature name]?" with a 1–5 scale
What to do with results: Cross-reference with bug reports from the same period. Low CSAT alongside high bug volume confirms a quality issue. Low CSAT with few bugs suggests a design or expectation mismatch.
4. Churn-risk trigger
Users who show signs of disengagement, reduced login frequency, incomplete sessions, or repeated abandonment of key flows, are at risk of churning. A short survey triggered by this behavior can surface the reason before they leave.
When to trigger: Use the JavaScript SDK to trigger based on inactivity signals or specific in-app events that indicate disengagement
Question: "Is there anything stopping you from getting value from [product]?", open-ended only
What to do with results: Treat every response as a support conversation. Follow up personally. The goal here isn't research data, it's saving individual accounts.
💡Keep churn-risk surveys to a single open-ended question. A disengaged user is unlikely to complete a multi-step survey. One question with a text box gets more responses than five questions with a progress bar.
5. CES after a support interaction
Customer Effort Score measures how much work a user had to do to resolve an issue. Triggered after a feedback item is marked resolved, it tells you whether your support process is actually easy for users, not just whether the issue was fixed.
When to trigger: Include a CES survey link in your resolution notification email using the reporter notification email feature
Question: "How easy was it to get your issue resolved?" with a 1–7 scale
What to do with results: High effort scores despite successful resolution indicate a process problem, too many back-and-forths, unclear communication, or slow response times.
