Docs

Closing the feedback loop with your users

Why most feedback tools stop at collection, what silence costs you, and the smallest system that tells people what happened.

Feedback tooling is overwhelmingly built for one direction. There are dozens of good ways to collect what users say and almost none for telling them what you did about it. That asymmetry is not an oversight — collection is easy to demo and easy to sell. It is also where most of the value leaks out.

The report is a favour, and favours are conditional

Someone who reports a bug has spent their own time on your product's quality. The decision they make afterwards is not about your product; it is about whether the favour was received.

If nothing happens — no acknowledgement, no answer, no sign the message was read — the rational conclusion is that reporting does nothing. Most people only need to reach that conclusion once.

Why the public board is not the answer

The usual solution is a public roadmap: post the request, let people vote, update the status, and anybody who cares can come and look.

It works for some companies. But notice what it asks of the reporter — that they remember to return to a page and check. That is a poll model, and polling is exactly what people do not do. The reporter wanted to be told, and a board tells nobody.

It also brings costs that arrive later: your roadmap becomes public, every rejection happens in front of an audience, and vote counts start deciding priority on behalf of whoever has the most organised customers.

The smallest system that works

You need three things, and none of them is a board.

A status per item. Something like pending, planned, in progress, completed, rejected. Enough to describe what is actually happening, few enough that nobody has to think about which one to pick.

A contact for each report. Not an account — an address. Either what the person typed, or one your own site already knows and passed along with the report.

An automatic message on the transitions that are news. Shipped is the one people care about. Rejected is the one teams avoid and should not: a clear no is kinder than eighteen months of silence, and it stops the same request arriving four more times.

Say no properly

The transition teams skip is rejection, usually out of a vague sense that saying no is worse than saying nothing. It is not. Silence is read as incompetence; a no is read as a decision.

Two sentences are enough. What you decided, and why it does not fit. You do not owe anyone a debate, and the person who asked would rather know.

What it buys you

The immediate return is a second report from the same person. The larger one is that your feedback channel keeps working: a widget that produces nothing after six months is almost always a widget attached to a team that never replied.

Nobody sets out to build that. It happens by default, because collection ships first and the loop never gets closed.