The short version
- Nine types, split by whether the person had already hit the problem when they told you.
- The count on a feature request is worth less than it looks, and there are numbers for that.
- What people say and what they did are different kinds of evidence.
- A bug, a feature request and a cancellation reason need three responses and three fates.
The useful way to sort the types of user feedback isn't by channel. It's by what decision the feedback can support, because two comments arriving through the same form can be evidence of completely different things.
The nine below are sorted by that. At the top are the types that record what somebody did. At the bottom are the types that record what somebody predicts they would do. Everything gets less reliable as you go down, and the two most collected types are near the bottom.
Which kinds of feedback are there?
Nine, and the split that matters is whether the person had already hit the problem when they told you.
| Type | What it is evidence of | What it cannot tell you | How much to trust it | |
|---|---|---|---|---|
| 1 | Cancellation reasons | A decision that was made and paid for | How many people nearly did the same and stayed | Highest. The only feedback that arrives with a price attached |
| 2 | Support conversations | A problem somebody hit while trying to do something real | Whether the problem is common, since most people do not write in | High, and it is the most underread source in most companies |
| 3 | Bug reports | Something that is broken, with the situation attached | Its importance. A rare bug reported well outranks a common one nobody bothered to report | High for the fact, low for the priority |
| 4 | Feature requests with a count | How many people said the same thing unprompted | How badly any of them want it, or whether they would pay | Moderate, and the count is smaller than it looks |
| 5 | Sales objections | What stopped somebody buying, in their words | Whether building the thing would have closed them | Moderate, and reliably overweighted by whoever heard it |
| 6 | Reviews left publicly | What somebody is willing to say in front of others | The median opinion, since reviews come from the two tails | Moderate for the wording, weak for the proportions |
| 7 | Survey answers | What people report about themselves | What they actually do, which is often different | Low, and lower the further the question is from last week |
| 8 | Rating scores | That a number moved | Why. A score with no comment attached is not actionable | Low on its own, useful only as a trigger to go and ask |
| 9 | Unprompted praise | That somebody is happy | Anything you can build from | Lowest, and pleasant, and worth reading anyway |
Rows seven and eight are the two most collected and the two least load bearing. Rows one and two are usually free, already happening, and read by nobody in particular.
There's a board carrying the fourth type open without an account.
Want somewhere to put all of this? Twenty eight feedback tools, the price and the unit each one bills on, read on one day.
Why is the count on a feature request worth less than it looks?
Because the numbers on real boards are far smaller than the word count suggests.
Thirty six public feedback boards belonging to real companies were read on 27 August 2026. On the median one, the median request visible on page one had nine votes. On nineteen of the thirty six the median request had fewer than ten.
On the median board the most voted request held sixteen per cent of all votes on page one, so the head of the board carries real information and the body of it's a long tail of ones and twos.
That's an argument for reading the top of a board as a signal, not an argument against collecting requests, and the middle of it as a list.
The difference between the third and the eighth request, at nine votes each, is one person having a bad afternoon. The measurement, with everything it can't tell you, is on its own page.
What is the difference between what people say and what they did?
One is a memory or a prediction. The other is a record.
Everything in rows one to four of the table happened. Somebody cancelled, somebody wrote in while stuck, something was broken, somebody agreed with a request that was already there. Rows five to nine are reports, and reports are shaped by who is asking, when, and in what mood the person is.
The practical version of this rule is to ask what somebody did last time rather than what they would do next time. A question about last Tuesday produces a fact. A question about next quarter produces a polite guess, and the guess is consistently more optimistic than the behaviour.
The mistakes that make all nine types useless
Mixing them in one inbox. A bug, a feature request and a cancellation reason need three different responses and three different fates. In one shared address they get the same one, which is a reply and then nothing.
Counting comments instead of people. Five messages from one very engaged customer are one person's opinion, and they routinely outrank fifty silent accounts.
Reading only the channel you built. A feedback form reaches the part of your audience that fills in feedback forms. That group is small and unrepresentative, and it's not the group that cancels.
Never closing the loop. The single largest cause of a feedback channel drying up is that nothing came back. People file once, hear nothing, and stop. Whatever else you do with the nine types, tell the person when the thing they raised changes.
How to sort feedback without a tool
Three destinations and one weekly hour.
A spreadsheet with one row per piece of feedback, a column for which of the nine types it is, a column for who said it, and a column for the situation, not the request. Sort by type, and read the top four types first.
The situation column is the one that does the work. A row saying add a billing address field records somebody's proposed solution. A row saying they could not find where to change their billing address records the problem, and the problem is the thing several people will turn out to share.
What a spreadsheet can't do is the loop. Telling forty people that the thing they asked for shipped means keeping a list of who asked for what, and doing that by hand is the job every tool in this category exists to remove.
How our own board handles the fourth type
By keeping two counts on every card, and by knowing who is behind each vote.
Both numbers are on every card in the picture above. The plain count answers how many people want it. The weighted total beside it in blue multiplies each vote by the weight of the tier the voter sits in, and answers what's behind the want.
Keeping both is the point, because a board showing only one of them can't tell you which question you're reading.
The multiplier per tier is set on one screen, and it's the only configuration weighting takes.
Two honest limits. Weighting doesn't manufacture a signal out of nine votes, and if everybody voting on your board pays you roughly the same then it has nothing to weigh.
And a request board only collects the fourth type. The first two, which the table puts above it, arrive through support and through cancellation conversations, and no board will fetch them for you.
The price doesn't change with how many people you collect from. It's $9 or $39 a month by plan, not by the number of people whose feedback you hold. How the board is wired is written up here, and ten board shapes with their columns are on their own page.
14 days, a card at signup, then $9 or $39 a month.
