How to ask for customer feedback in a software product
7 min read
To ask for customer feedback in a software product, ask one specific question about something the user just did, in the place where they did it. “How did exporting that report go?” right after an export gets an answer. “Tell us what you think of our product” in a footer gets silence. The rest of this page is the moments, the channels and the exact wording.
Most advice on this topic is written for shops and service desks. A software team knows exactly what the user did a second ago, so the question can be about that.
| Moment | Where to ask | Ready-to-use ask |
|---|---|---|
| Right after a task finishes | In the app, next to the result | “Did that export do what you needed?” |
| After a new feature’s first use | In the app, once | “What were you trying to do with Bulk Edit?” |
| After a support ticket is resolved | In the support thread | “Did that fix it, or is something still off?” |
| After a user stalls or leaves a flow | Email, a day later | “You stopped at step 3 of setup. What got in the way?” |
| After 30 days of regular use | Email from a named person | “What is the one thing you would change?” |
| When a user cancels | In the cancel flow | “What made you decide to leave today?” |
| After you ship something they asked for | Where they asked | “You asked for CSV import. It is live. Does it cover your case?” |
When is the right time to ask for feedback?
The right time is right after the user finishes something, while the detail is still in their head. A question that follows an action gets an answer about that action. A question that arrives out of nowhere gets an answer about whatever mood the person is in, or no answer.
Do not ask at signup, because nobody has used anything yet. Do not ask in the middle of a task, because you are interrupting what you want to learn about. Once a person has answered, leave them alone until you have something to report back.
Where should you ask for customer feedback?
Ask in the place where the experience happened. An in-app prompt suits a question about a screen. The support thread suits a question about a fix. Email suits a question about a week of use, or about a flow the person abandoned. A call suits the questions you cannot predict.
Each channel gets a different kind of answer:
- In-app: short, immediate and specific, but only from people who are present. You hear nothing from users who left.
- Support thread: from people who were already frustrated enough to write in. Good for finding broken things, poor for judging the rest of the product.
- Email: longer answers from fewer people, and the only way to reach users who have gone quiet. Write it as a short note from a named person, with one question in it.
- Interview: the way to learn why people do things. Ask them to show you how they work, and stay quiet while they do.
Feedback signal quality covers how to weigh what each channel tells you.
How do you professionally ask for feedback?
Be specific about the thing, say why you are asking, and make the answer cost under a minute. A professional ask names the moment, makes clear a person will read the answer, and does not apologise for the interruption.
Name the exact action (“the export you just ran”), ask for one thing, use a free-text box with no required fields, and sign with a first name.
What is a good sentence for asking for feedback?
A good sentence is a question about a specific moment that can be answered in a few words. Compare the two columns below. The left ones can be answered with a shrug. The right ones need the person to recall something real.
| Weak ask | Stronger ask |
|---|---|
| “Any feedback?” | “What was the hardest part of setting this up?” |
| “How do you like our product?” | “What did you use this for last week?” |
| “Rate your experience from 1 to 10.” | “Did you get done what you came to do today?” |
| “Tell us how we can improve.” | “What is one thing that slowed you down this week?” |
| “Would you recommend us?” | “Who did you last show this to, and what did you say?” |
Another that works almost anywhere: “What are you using instead when this does not work for you?” It surfaces the real competitor, which is often a spreadsheet.
What are the worst ways to ask for feedback?
The worst asks are broad, early, long or loaded. They share a problem: the person cannot answer without doing the thinking you should have done.
- “Please fill out our 20-question survey.” The people who finish are the ones with the most free time or the strongest opinions.
- A popup on the first page after login. The user came to do something and you blocked it. Dismissing it is the only sensible answer.
- “We would love your feedback!” with no question. It asks the user to invent the topic.
- A leading question: “How much do you love the new dashboard?” You get agreement and learn nothing.
- A rating with no follow-up. A 6 out of 10 tells you the mood. It does not tell you what to change.
- Asking, then going silent. This costs you the next round, which is covered below.
What do we call customer feedback about a product?
Feedback about a product is usually called product feedback, and it sorts into two kinds. A bug report says something does not work as intended. A feature request says something is missing. The distinction decides who looks at it first, and feature request vs bug report draws that line. A third kind, praise, is worth keeping and quoting with permission.
A feedback form that offers “Bug” and “Feature request” as its first choice does that first sort for you.
What do you do with the answers?
Put every answer where the team already works, with the person’s words intact. A single line of quoted text beats your summary of it. Tag it by type and rough urgency, merge repeats, and decide: build it, park it or decline it.
Declining counts as an answer too. “We are not going to build this, and here is why” ends the wait, and declining feature requests has wording for it. For the plumbing, feature request tracking describes how to get requests from five channels into one list. If you take requests in writing, a feature request template keeps them comparable.
Changeloop’s widget files each submission as a GitHub issue, so feedback lands next to the code that will fix it. With any tool the rule is the same: one list, one owner, no answer left in someone’s inbox.
Why tell people what shipped?
It shows the person that answering was worth their time. A user who told you something and later hears “this shipped, thank you” has a reason to answer again. One who hears nothing concludes the box is not read.
So the last step of asking is a reply. Tell each person who asked when their request ships, in their own terms, on the channel they used. Closing the customer feedback loop describes the mechanism: the published changelog entry is what triggers the message, so the requester is only told once the change is live. In Changeloop, when widget feedback became a GitHub issue and the merged pull request closes it, approving the entry posts a “Shipped” comment on that issue and shows the submitter the entry in the widget; issues filed by hand, and GitLab or Bitbucket repositories, get no comment. Our docs list the widget and feed setup.
A reply can be short: “You asked for CSV import in March. It is live today, and here is how it works.” It also gives you the best next question, whether it covers what they needed.
A starting plan
Pick one moment from the table at the top, the one where users most often succeed or give up. Write one question for it, put it in one channel, and read every answer for two weeks before adding a second prompt. Reply to anyone who gave you something concrete.
FAQ
How often should you ask customers for feedback? Tie asks to events, not to a calendar. A user should see at most one prompt a week, and none right after answering one. The next message after feedback should be a reply about what happened to it.
How do you ask for feedback without annoying users? Ask after a task, never in the middle of one, keep it to one question, and make it easy to dismiss. Respect a dismissal for a few weeks.
Should you offer an incentive for feedback? Usually you do not need to. A specific question and a visible reply carry more weight than a gift card, and incentives attract people who want the reward. Save them for interviews, where you are asking for 20 minutes of someone’s time.
What if nobody answers? Narrow the question and move it closer to the moment, for example one screen, asked right after it is used. If it stays quiet, email a handful of users directly and use those conversations to write better prompts.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.