How to use these questions
Every set starts with the question that matters most for that moment, so the two-question version is always usable. Replace the placeholders in curly braces, send it right after the experience you are asking about, and read every answer before you send the next survey.
Surveys are the active half of feedback collection. The passive half is an always-on channel where users can report a bug or request a feature without waiting to be asked, such as a feedback widget. Most teams need both. See how to collect customer feedback for how they fit together.
After onboarding questions
Goal: Find where new users get stuck before they quietly leave. When: Within the first session or right after a user finishes setup.
| Question | Format | Why it works |
|---|---|---|
| What were you hoping to get done when you signed up today? | Open text | Anchors every other answer to the job the user came to do, not to your feature list. |
| How easy was it to get set up? (1 = very hard, 5 = very easy) | Scale 1–5 | A single effort score you can track over time and compare between onboarding versions. |
| What, if anything, almost made you give up during setup? | Open text | "Almost" surfaces friction from users who pushed through, which you would never hear from the ones who left. |
| Was anything confusing or missing from the first screens you saw? | Open text | Points to copy and empty-state problems that are cheap to fix. |
| What would you have to see in the next week to keep using this? | Open text | Tells you what "activated" means to the user, in their words. |
| Where did you hear about us? | Multiple choice: Search, Friend or colleague, Social media, Community (Reddit, Indie Hackers, Discord), Other | Ties onboarding experience to acquisition channel without a separate survey. |
| Is there anything you expected to find that you could not? | Open text | Catches navigation and discoverability gaps. |
| Can we follow up with you about your answers? | Yes / No | Turns a survey into a pipeline of interview candidates. |
- Instead of “How much did you love our onboarding?” ask “How easy was it to get set up?”
- Instead of “Would a video tutorial help?” ask “What, if anything, almost made you give up during setup?”
Clarifying a feature request questions
Goal: Turn "please add X" into the problem, its frequency, and its cost. When: When a user asks for a feature, before you score or reply to it.
| Question | Format | Why it works |
|---|---|---|
| What were you trying to do when you noticed this was missing? | Open text | Moves the conversation from the requested solution to the underlying task. |
| How are you handling it today? | Open text | The workaround tells you how painful the gap really is, and sometimes reveals a cheaper fix. |
| How often does this come up for you? | Multiple choice: Daily, Weekly, Monthly, Rarely | Daily, weekly, monthly, or rarely. Frequency is the Reach input in RICE. |
| What happens if this is never built? | Open text | Separates "nice to have" from "we will switch tools". |
| Who else on your team runs into this? | Open text | Shows whether the request is one person or a whole account. |
| If this worked perfectly, what would it look like? | Open text | Collects acceptance criteria before you design anything. |
| Is this blocking you from buying, upgrading, or renewing? | Yes / No | Flags revenue-linked requests without asking users to inflate urgency. |
- Instead of “Would you use it if we built it?” ask “How are you handling it today?”
- Instead of “How important is this feature, 1 to 10?” ask “What happens if this is never built?”
Bug report questions
Goal: Get enough detail to reproduce the problem on the first try. When: In a bug form, or when replying to a vague "it is broken".
| Question | Format | Why it works |
|---|---|---|
| What did you expect to happen? | Open text | Defines the bug. Half of "bugs" are expectation mismatches, which need a UX fix, not a code fix. |
| What happened instead? | Open text | The actual result, in the user's words, often including the error text you need. |
| What steps did you take right before it happened? | Open text | Reproduction steps are the single biggest time saver for whoever fixes it. |
| Does it happen every time, sometimes, or only once? | Multiple choice: Every time, Sometimes, Only once | Separates deterministic bugs from flaky ones before anyone starts debugging. |
| How much is this blocking you? (1 = minor annoyance, 5 = cannot work) | Scale 1–5 | User-reported severity, which you can compare with your own triage priority. |
| Can you share a screenshot or screen recording? | Yes / No | A picture removes most follow-up questions. TellTide's widget attaches one automatically if the user agrees. |
| Have you found a workaround? | Open text | Lets support unblock other users while the fix is in progress. |
- Instead of “Did you try clearing your cache?” ask “What steps did you take right before it happened?”
- Instead of “Can you describe the bug?” ask “What did you expect to happen, and what happened instead?”
After a new feature ships questions
Goal: Check that the feature solved the problem it was built for. When: One to two weeks after release, to people who have used it.
| Question | Format | Why it works |
|---|---|---|
| Have you tried the new feature yet? | Yes / No | Filters answers to real users and measures awareness at the same time. |
| Did it solve the problem you had? (1 = not at all, 5 = completely) | Scale 1–5 | Judges the feature against the original need, not against taste. |
| What would you change about how it works? | Open text | Invites concrete iteration ideas while the experience is fresh. |
| What did you use before this existed? | Open text | Confirms what the feature replaced and whether it beat the old workaround. |
| Is anything stopping you from using it more often? | Open text | Uncovers adoption blockers such as permissions, pricing, or discoverability. |
| Who else should know this exists? | Open text | Finds internal champions and signals word-of-mouth potential. |
- Instead of “Isn't the new feature great?” ask “Did it solve the problem you had?”
- Instead of “Rate the new feature from 1 to 10.” ask “What would you change about how it works?”
Cancellation and churn questions
Goal: Learn the real reason people leave, and whether it was fixable. When: In the cancel flow, or by email within a day of cancelling.
| Question | Format | Why it works |
|---|---|---|
| What is the main reason you are cancelling? | Multiple choice: Too expensive, Missing a feature I need, Switched to another tool, My project ended, Too hard to use, Other | Too expensive, missing feature, switched tool, project ended, or other. Lets you count reasons. |
| What could we have done differently? | Open text | The open follow-up explains the multiple-choice answer. |
| What are you switching to, if anything? | Open text | Names the competitors who are actually winning your customers. |
| Was there a specific moment you decided to leave? | Open text | Points to the incident or bill that triggered the decision. |
| Did you get the result you signed up for? | Yes / No | Separates "it worked, I am done" churn from "it did not work" churn. |
| Would anything bring you back? | Open text | Gives you a win-back list to email when you ship it. |
- Instead of “Are you sure? We'd hate to lose you.” ask “What is the main reason you are cancelling?”
- Instead of “Was it the price?” ask “What could we have done differently?”
Beta testers and first users questions
Goal: Learn whether the product is useful yet, and for whom. When: Weekly during a beta, or after a user's first real week.
| Question | Format | Why it works |
|---|---|---|
| What did you use the product for this week? | Open text | Shows real usage, which is often different from the use case you designed for. |
| What was the most frustrating part? | Open text | Early users forgive a lot. Asking directly gets the friction they would not volunteer. |
| What is the one thing we should build or fix next? | Open text | Forces a single priority instead of a wish list. |
| How would you describe the product to a colleague? | Open text | Gives you positioning language in the customer's own words. |
| What else did you try before this? | Open text | Maps the alternatives you are really competing with, including spreadsheets. |
| How likely are you to keep using it after the beta? (1 = not at all, 5 = definitely) | Scale 1–5 | An early retention signal you can watch week to week. |
| Would you pay for this today? | Yes / No | Cheap to ask, and a "no" with a reason is more useful than polite praise. |
| Can we schedule 15 minutes to watch you use it? | Yes / No | Observation beats any survey answer at this stage. |
- Instead of “What features would you like us to add?” ask “What did you use the product for this week?”
- Instead of “Do you like the product?” ask “What was the most frustrating part?”
Product-market fit questions
Goal: Measure how much users would miss the product, and why. When: To active users who have used the product at least twice in two weeks.
| Question | Format | Why it works |
|---|---|---|
| How would you feel if you could no longer use this product? | Multiple choice: Very disappointed, Somewhat disappointed, Not disappointed | The Sean Ellis question: very disappointed, somewhat disappointed, not disappointed. 40%+ "very disappointed" is the usual fit benchmark. |
| What is the main benefit you get from it? | Open text | Tells you which value proposition to lead with. |
| What type of person do you think would benefit most from it? | Open text | Users describe your ideal customer profile better than you do. |
| What would you use instead if it disappeared? | Open text | Shows your true substitute, which sets pricing and positioning. |
| How can we improve it for you? | Open text | Read answers from "very disappointed" users first; they define what to double down on. |
- Instead of “Would you recommend us to a friend?” ask “How would you feel if you could no longer use this product?”
Asking for a review questions
Goal: Collect honest ratings and quotable testimonials. When: Right after a success moment, such as a first report sent or a bug fixed.
| Question | Format | Why it works |
|---|---|---|
| How would you rate your experience so far? (1–5 stars) | Scale 1–5 | A low-effort first step. Follow up differently with 4–5 stars than with 1–3. |
| What has improved since you started using it? | Open text | Produces outcome-based testimonials instead of generic praise. |
| What almost stopped you from trying it? | Open text | Objections you can answer on your landing page. |
| Can we quote you on our website, with your name and company? | Yes / No | Get explicit permission before publishing anything. |
| What would make it a 5-star experience? | Open text | Turns a 3 or 4 into a specific improvement instead of a dead end. |
- Instead of “Please leave us a 5-star review!” ask “How would you rate your experience so far?”
Pricing page and not converting questions
Goal: Find out what stopped someone who was close to buying. When: On an exit prompt from pricing, or to sign-ups who never paid.
| Question | Format | Why it works |
|---|---|---|
| What stopped you from subscribing today? | Multiple choice: The price, A missing feature, I need someone else to approve it, I'm still researching, Other | Price, missing feature, need approval, just looking, or other. Countable and quick. |
| What would you need to see to feel confident buying? | Open text | Points to missing proof: docs, a demo, security answers, or case studies. |
| What are you comparing us with? | Open text | Shows the alternatives in the buyer's shortlist. |
| Is the pricing clear? | Yes / No | Confusion converts worse than a high price. A "no" here is an easy fix. |
| Who else needs to approve this purchase? | Open text | Reveals buying committees early, so you can arm your champion. |
- Instead of “Is our price too high?” ask “What stopped you from subscribing today?”
After the answers come in
- Tag each answer by problem, not by the feature the user suggested.
- Count how many different users mention the same problem before you act on it.
- Score the feature requests that survive with the RICE calculator.
- Reply to everyone who answered, and tell them when something they raised ships. That is what closing the loop means, and it is why people answer your next survey.
Questions people ask
How many questions should a customer feedback survey have?
Two to four for an in-product or email survey. Each extra question lowers the completion rate, so ask only what you need for the next decision and save the rest for an interview.
Should I use open-ended or multiple-choice questions?
Pair them. A multiple-choice or scale question gives you something to count, and one open follow-up explains it. A survey of only open questions is hard to analyse; a survey of only scales tells you what but not why.
What makes a feedback question biased?
Leading wording ("How much did you love…"), suggesting a solution ("Would a video help?"), or asking about hypothetical future behaviour ("Would you use it?"). Ask about specific past experiences instead.
When is the best time to ask for feedback?
Right after the experience you are asking about: after setup, after a bug, after a cancellation. Memory fades fast, and context-free surveys collect vague answers.