How to collect feedback from customers

There is no single best way to collect feedback from customers. Support email catches complaints from people who already bothered to write. A public feature request board turns those complaints into a vote count. Surveys, interviews, app store reviews and your own churn data each tell you something different, at a different cost.

This is not a ranked "best tools" list. It is the honest version: what each method actually costs you in time or money, what it tells you that the others do not, and who it genuinely suits. Including when a public board is the wrong answer, which most guides skip.

For the form itself, rather than the choice of method, see a feature request template you can copy.

This page is one part of a larger guide. For the whole subject in one place, see feature request tools.

What is the fastest way to start collecting feedback?

Support email. If your product already has a support address, you already have a feedback channel: no setup, no separate login, no new habit for anyone to learn. The catch is what it does not tell you. An email only arrives from someone annoyed enough, or grateful enough, to write one. Everyone else who wanted the same thing, hit the same bug, or would have said the same, stays silent. You get individual data points with no way to tell how many people share each one, and every reply lives in a private inbox that nobody but you can search later.

Treat it as the baseline every product should already have, not the whole system.

Should you build a public feature request board?

A public board answers the question support email cannot: how many people want the same thing. Instead of one email saying "please add dark mode", a board turns that into a request other customers can find and vote on, so the count itself becomes the signal, and you can sort by what is actually wanted rather than what was last mentioned.

A ticket summary tells you how often something comes up. A voting board tells you how many people actively want a thing built.

Fider

That is also its cost. A board only works if people are willing to visit a page that is not the product itself and, on most tools, create an account to post or vote. GitHub Issues is the clearest example of that barrier: posting needs a GitHub account, which most buyers of a consumer product do not have and will not create just to leave feedback. A board with no visitors looks worse than no board at all, because it makes low demand visible instead of invisible.

Docket's free edition includes guest posting, so visitors are not required to create an account to file a request, which removes that specific barrier. It does not remove the need for an existing audience willing to click through to a separate page in the first place.

Do in-app widgets catch feedback the other channels miss?

A feedback widget sits inside the product itself, so it catches people at the moment something goes wrong or feels missing, rather than waiting for them to leave the product and go find your support email. That timing is the real advantage: the friction is still fresh, so what they type is specific, rather than a vague complaint written from memory a week later.

The cost is screen space, and usually a paid tool to run it. It suits products people already open regularly; it does almost nothing for something used once and never opened again.

Are surveys worth sending?

A survey lets you ask the exact question you want answered, which nothing else on this list does. That is also its limit: you only hear from the people who chose to answer, about the question you chose to ask. It will not surface the thing you did not think to ask about. Use a survey to test a hypothesis you already have, not to go looking for one.

What do user interviews tell you that nothing else does?

A conversation lets you ask a follow-up question, which is the one thing every other method here cannot do. You find out not just what someone wants, but why, and you can watch where they hesitate or get confused, which they would rarely think to write down themselves.

The cost is time, yours and theirs, which is why interviews do not scale past a handful of people. Save them for the decisions where a wrong guess is expensive.

Do app store reviews count as feedback?

Yes, and they arrive already public and already written, with no effort from you at all. The catch is that reviews skew toward the two extremes: people who liked something enough to say so, and people angry enough to leave one star in public. The quiet majority of your users rarely reviews anything. You also cannot reply privately or ask a follow-up question to a star rating.

What does your own churn already tell you?

Data you already have and probably are not reading. If your cancellation flow asks why someone is leaving, or your billing provider records a downgrade reason, that answer is sitting in your account right now, at no extra cost to collect.

It has one real limit: it tells you what made someone leave, not what would have kept them. Someone who cancels because a feature was missing may never have told you they wanted it while they were still paying. Treat churn feedback as a pattern to watch across many cancellations, not the whole picture from one.

Which method should you actually use?

Most products need at least two of these running at once: one channel that catches problems as they happen, and one that shows you what is wanted most, not just what was mentioned loudest or last.

When is a public feature request board the wrong choice?

A public board assumes an audience willing to visit it. Three situations where that assumption fails:

• Pre-launch, with no users yet. An empty board showing zero votes reads as evidence nobody wants your product, which is a worse signal than having no board at all.
• Anything where competitors reading your roadmap is a real cost. A public board is, by definition, public. Anyone can see what you are planning next, including whoever is watching your category closely.
• Audiences who will not create an account anywhere, on principle or by habit: enterprise buyers behind procurement, less technical audiences, or anyone who treats "sign up to tell us what you think" as a wall rather than a door.

In any of those three, support email plus the occasional interview will get you further than a board nobody visits. Build the board once there is a real audience for it to serve, not before.

Frequently asked questions