How to collect feature requests from users without a spreadsheet

A spreadsheet works until two people edit it. The same request shows up in several wordings. The decision cell is blank. Support and sales each hold another copy.

Use one board, a short field list, a status on every item, and a weekly half hour. The tool can be FlatVote or another product.

What the spreadsheet was actually doing

Before you retire the sheet, name the jobs it was covering. If the new board misses one, people will quietly go back to the sheet.

The sheet held the request in the user's words, who asked, and whatever decision you had written down. It was also what you searched later, when you needed to know if you had already said no.

A board has to do those jobs in public. The next person with the same request should find the existing post instead of starting a new row. A private sheet cannot do that. Every new email starts from zero.

If you keep a private sheet for the team and a public board for users, you have two lists. They will drift. Pick one list both sides can open. Internal notes can sit on the post. They should not be a second copy of the request.

The fields worth keeping

Keep the list short. Extra columns feel thorough, and then nobody fills them in. A blank column teaches the team that the board is optional.

Keep the request in the user's words. Do not rewrite it into roadmap language before you store it. You can add a summary above it, but the original wording is the part you will misunderstand if you delete it. People describe the wall they hit, not the feature name you would have chosen. "I need to get this report to finance every Monday" is a better record than "export improvements."

Record who asked, with an email or an account id. You need that to tell one person from several, and to reach them when the request ships. A ticket link or a page can sit beside it, but do not block a post when context is missing.

Status is not optional. An empty status is how a board rots. Keep an internal note off the public post for effort, risk, or a dependency. The public post gets a status and one sentence.

Skip a score column at the start. Count first, then decide in a conversation. A companion guide covers how to count customers rather than votes.

One URL, and replies that point at it

Pick one address and use it everywhere you already talk to users: in the product, in the help menu, and in the docs. If you publish a changelog, link the board from there too. The board should be the obvious place, not a link you remember on good days.

When a request arrives by email, do not paste it into a sheet and answer "I wrote it down." Send the board link. If the request exists, point at that post and add their vote. If it does not, post it in their words and send the link back. The record they can check later should be the record you check later.

Change the support macro. "I'll add it to the sheet" becomes "Here is the board. Here is the existing post. I added you to it." A sales note can point at that post. It should not be the only copy of the request. If a deal depends on the feature, say so in the internal note, not in a private file nobody else can find.

Duplicates are normal

People will post the same idea more than once. They did not search, or your title did not use their words. Treat that as ordinary.

Keep the clearer post. Point the other one at it. Move votes if the tool can move them. If it cannot, ask people to vote on the post you are keeping, then close the duplicate so new votes do not land in the wrong place.

Do this in public. One sentence is enough: "Same request as the other post. Closing this one so the count stays in one place." A merge that only happens in a private sheet looks like you ignored someone.

Write titles in the words users already use. If they say "export" and the post says "data portability," they will not find it. A vote means "me too." It does not mean the idea is fully specified, and it does not mean you should build whatever is on top.

Statuses you will actually maintain

Open means you have seen it and have not decided. Planned means you are willing for a customer to repeat that you intend to build it. Building means someone is on it now. Shipped means the people who asked can use it. If it shipped for only one plan, say so. Declined means you will not build it, with a reason. "This fights the way permissions work" is a reason. "Not now" is a delay, so leave the post open.

Skip labels that report nothing, such as "under consideration" and "someday." Change the status when the decision changes. A post that says planned while nobody is working on it is a decision you have not admitted. FlatVote does not require these exact words. You do need a shipped state that can send the notice below.

Close the loop

The people who asked should not have to watch a changelog to learn that you built their request. Email the voters. Say what shipped and link to it. Do not attach a discount or a newsletter opt-in. They asked about a feature. Answer that, and stop.

On FlatVote, that email goes out when you mark the request shipped. On another tool, name whose job the notice is. "Someone will remember" means it will not go out.

Leave a reason on anything you decline. Silence gets the same request again. Move bugs to the issue tracker and questions to the docs, and leave a pointer. Left on the board, they turn it into a second inbox.

A weekly half hour

Once a week, one person who is allowed to say no reads new posts, merges duplicates, sets missing statuses, moves bugs off the board, and writes one sentence on anything they decline. If nobody has that job, the board becomes the spreadsheet again. They do not need to be the founder. They do need a real no the same week. "I will ask" recreates the blank cell. A quiet week still gets the review. Skipping it is how a duplicate sits untouched.

When a spreadsheet is still fine

If you are the only person who hears requests, and there are only a handful in a month, a sheet is still honest. Move when a second teammate needs the list, when users ask each other whether you saw an idea, or when you can no longer tell duplicate rows apart. Do not open a public board until someone will maintain it. Move the rows, stop adding to the old file, and announce the new URL once.

Where FlatVote fits

FlatVote is a hosted board for this workflow. People post ideas and vote. You set statuses. Voters get an email when a request ships. The price does not follow the voter count. Starter is $19 a month for 1 board. Team is $49 a month for 5 boards, SSO, a custom domain, and unlimited admins. There is no free plan. CSV import covers a spreadsheet. The Canny API covers a board that already lives in Canny.

The product has not shipped. The ship date and pre-order terms are on the home page. If most of the audience is on a free plan, the next guide is about running the board without paying per voter.