You have 400 pieces of feedback. Now what?

Collecting feedback is the part everyone gets right. The failure comes later, at the point where there is more of it than one person can hold in their head, and the honest state of most feedback inboxes is that nobody has read the last two hundred messages.

Why reading everything stops working

Reading is perfect up to a point. Under fifty pieces a month you should just read them, and no tool will beat that.

What breaks is not the reading, it is the counting. You will remember that several people mentioned the export being slow. You will not remember whether it was four or fourteen, whether it is worse this month than last, or whether the people saying it are on your most expensive plan. Human memory over a stream of text produces impressions, and impressions are systematically biased toward whatever you read most recently and whoever complained most vividly.

Why tagging fails differently

The standard fix is a taxonomy: tag each piece, then count tags. It works, briefly.

• It decays. Tagging is unrewarding work competing with shipping, and it is always the first thing to slip. A half-tagged inbox is worse than an untagged one because the counts look authoritative and are wrong.
• It encodes your assumptions. You built the tag list from what you expected to hear, so anything genuinely surprising lands in “other”, which is precisely where the valuable feedback goes to die.
• It splits on words rather than problems. “Export is slow” and “the download never finishes” are one problem and two tags, so the count under-states it.

Group by the problem, not the wording

What you want is for those two sentences to end up in the same bucket without anyone deciding they should. That is a semantic judgement, which is the one thing language models are genuinely reliable at: not writing your roadmap, just recognising that two differently-worded complaints describe one underlying thing.

The output is a much shorter list. Four hundred messages is not four hundred decisions, it is usually fifteen or twenty problems with wildly different weights behind them.

Then rank by impact, and make the ranking checkable

Three inputs, and you want all three:

• Volume. How many people. Alone, it over-weights whatever is easiest to complain about.
• Sentiment. How unhappy. Alone, it hands your roadmap to the angriest person who wrote in.
• Recency. Whether it is still happening. Alone, it chases noise and forgets long-standing problems.

Multiply them and you get something defensible. The important property is not that the formula is clever, it is that it is arithmetic anyone on the team can inspect and disagree with. A ranked list nobody can interrogate gets ignored the first time it disagrees with someone senior.

Close the loop, at least sometimes

Anyone who left an email address on something you fixed is worth replying to. It is a short message and it does two things: it turns a complaint into goodwill, and it teaches people that writing to you has an effect, which is the only reason anyone writes a second time.

Make it a habit, not a project

Fifteen minutes a week beats a quarterly deep-dive, because the point is noticing changes and you cannot notice a change you only look at four times a year. A weekly summary in your inbox does most of the work of remembering to look, which is why Voicebox sends one on Mondays and sends nothing at all on quiet weeks.

Common questions