How to collect feature requests from users without a spreadsheet
Many teams start collecting feature requests in a spreadsheet: someone asks for something, you add a row. It works for a few weeks. Then it stops, and the stopping point is predictable enough to plan around before it happens.
Where the spreadsheet starts to break
A shared spreadsheet has no way to stop the same idea from being entered several different times by several different people who worded it slightly differently. Someone has to periodically scan the rows, decide which ones are duplicates, and merge them by hand. As the sheet grows past a few dozen rows, that review step tends to get skipped, and duplicate entries start splitting whatever signal you had about demand.
There is also no natural way for the people who asked for something to find out it happened. A spreadsheet lives inside your company; the user who requested a feature months ago has no reason to go check a document they were never given access to. Either someone has to track down each requester by hand when a feature ships, which does not scale past a handful of requests, or nobody follows up, and the feedback loop that would have made people feel heard never closes.
A third problem is that a spreadsheet has no voting mechanism unless you build one, and most ad hoc versions of "voting" in a spreadsheet are really a tally someone updates by hand after reading through support tickets or sales calls. That is a reasonable starting point, but it reflects whoever did the counting that week more than it reflects actual demand, and it rarely gets updated once the backlog grows.
What a dedicated system needs to do
Stepping back from the spreadsheet problem, a workable feature-request system needs to do four things that spreadsheets do not do well on their own.
Give every request one place to land. If requests come in through support tickets, sales calls, social posts, and direct messages, and none of them end up in the same system, you cannot compare them to each other. The fix is not to ban other channels; it is to have someone responsible for moving anything that arrives elsewhere into the shared system, so the comparison stays apples to apples.
Let people search before they post. The single biggest source of duplicate entries is that the person submitting a request has no visibility into what has already been asked for. A public or semi-public board where people can search existing ideas before adding a new one cuts duplicates substantially, because people tend to upvote an existing post once they see it instead of writing a new one.
Make status visible without anyone having to ask. When a request moves from "under review" to "planned" to "in progress" to "shipped," that should be visible to whoever is watching it, not something they have to contact support to find out. Visible status also cuts down the number of "any update on this?" messages your team answers one at a time.
Close the loop automatically when something ships. The highest-leverage habit in feedback handling is telling people when the thing they asked for is done. It costs almost nothing if it is automatic, and it is the main thing that makes users trust that submitting a request was worth their time the next time around.
Setting it up in practice
If you are moving off a spreadsheet, the mechanics are straightforward.
- Export what you have. Most teams can turn an existing feature-request spreadsheet into a CSV in a few minutes: title, description, and a rough status column are usually enough to carry over. You do not need to clean it up fully first; deduplication gets easier once requests live somewhere with voting, because duplicates surface naturally as people vote on the existing post instead of filing a new one.
- Pick a small set of statuses and stick to them. Under review, planned, in progress, and shipped cover most workflows without needing a glossary. Adding more statuses than that mostly adds work for whoever updates them, without giving requesters much more information.
- Decide who triages, and how often. New requests need a person to sort them into a status at least once a week, or they pile up looking ignored even if someone is quietly planning to get to them. A regular, brief triage session is more useful than an occasional deep cleanup.
- Make the board visible to the people it is for. If it is customer-facing, embed it somewhere customers already are, rather than a separate destination they have to be told about repeatedly. If it is internal, link it from wherever your team already looks for priorities, such as a wiki or planning document.
- Keep voting friction low. Requiring a full account signup before someone can vote on an idea will suppress votes from people who would have voted with one click. An email address is usually enough to identify a voter and notify them later.
What changes once it is running
Once requests, votes, and statuses live in one place, you get a few things a spreadsheet cannot give you: a rough but real signal of relative demand, read alongside who is voting; fewer duplicate asks because people can see and upvote existing ones; and a notification loop that closes the conversation when something ships. None of that requires a complicated tool. It requires one place that supports search, voting, visible status, and an automatic update when something is done.
The spreadsheet is not a bad starting point. It is a weak long-term home, specifically because it has no built-in way to prevent duplicates, show status, or notify anyone. Those are structural gaps, not a matter of being more disciplined about updating the sheet. A dedicated board closes them by design, which is the main reason teams move off a spreadsheet once the backlog grows past the size one person can hold in their head.