Academy · 2026-06-23 · 7 min read
How to track feature requests properly
By Tom Whitfield, Feedlark co-founder
Key takeaways
- • Route every feature request, from support, sales and onboarding, to one public board instead of a spreadsheet.
- • Triage on a fixed cadence, weekly for most teams, and assign statuses so users see the board is actively monitored.
- • Merge duplicates so vote counts reflect real demand rather than fragmented, repeated posts.
- • Always notify voters when a request ships. It is the single highest leverage step in the whole system.
Every product team loses feature requests. They arrive in support tickets, Slack DMs, sales calls, onboarding conversations and user interviews, and then they scatter. A spreadsheet cannot prioritise them. An inbox cannot surface patterns. Here is the system that does, laid out as five steps you can start today.
Why the spreadsheet fails
A spreadsheet can store requests, but it cannot tell you which ones matter most. It cannot surface the fact that seventeen users all asked for the same thing using different wording. It cannot notify a user when their request ships. It cannot show your users that you are listening. It is a storage mechanism, not a feedback system, and the gap between those two things is where trust is built or lost. One team we heard from tracked requests in a shared document for a year, then discovered during a customer call that a churned account had asked for the same integration four times across four different support tickets, and nobody had ever connected the dots.
The right system: a public feedback board
A public feedback board is the single source of truth for feature requests. Every channel, support, sales, onboarding, routes requests there. Users vote on ideas they share. The team reviews the board on a regular cadence. The highest voted ideas get promoted to the roadmap. Nothing is lost, nothing is duplicated, and the priority order reflects actual user demand rather than recency or volume. Pairing this with proper feature request software means the whole pipeline, from first post to shipped notification, runs without manual copying between tools.
Step 1: create the board and embed the widget
Set up your board at a dedicated URL, feedback.yourproduct.com, and embed the feedback widget inside your product. The widget adds a Share feedback button to every screen, so users can post requests in context, while they are experiencing the thing they want to improve. Our guide to a feedback widget for your website covers placement and setup in more detail. This typically generates significantly more feedback than a standalone board alone, because the friction of navigating away is removed.
Step 2: build the routing habit
When a feature request arrives via support, sales or any other channel, route it to the board. Post it yourself if the user won't, or reply to the channel with a link to the relevant board post so the user can vote. This takes about thirty seconds per request and means the board accumulates signal from every conversation, not just the users proactive enough to find the board themselves.
Step 3: review and triage weekly
Block an hour each week to review the board. Look at posts above a threshold, say five votes, that haven't been triaged yet. Assign statuses: Under Review for ideas you are considering, Planned for things you have committed to, In Progress for active work. Reply to posts with more detail where relevant. Regular triage keeps the board useful and signals to users that it is actively monitored.
Step 4: detect and merge duplicates
As the board grows, the same feature gets requested in many ways. Manually checking for duplicates is exhausting on a busy board. Tools with AI assisted deduplication flag similar posts automatically, you review the suggestions and merge with a click. The result is one clean post with all the votes from its duplicates combined, giving you accurate signal rather than fragmented data.
Step 5: close the loop when you ship
When a feature ships, move it to Shipped. Every user who voted receives an automatic notification: the feature they requested is now live. That moment, between the request and the notification, is where user trust is built. It is the proof that the board is real, not performative. Teams that close the loop consistently see significantly higher board engagement than those that don't, and it pairs naturally with a changelog tool so the same update also appears publicly for anyone who wasn't watching that specific request.
Picking a triage cadence that fits your team
Not every team should triage weekly. A small team with a quiet board might only need a monthly pass, while a fast growing product with hundreds of weekly posts needs something closer to daily.
| Cadence | Best for | Risk if too slow |
|---|---|---|
| Daily | Large boards with high volume | Team burns out reviewing every post |
| Weekly | Most small and mid sized teams | Minor delay in responding to urgent requests |
| Monthly | Very small or early stage products | Board feels abandoned, votes stop accumulating |
Why users expect a fast response
HubSpot's research on customer service found that over half of service leaders say customers now expect resolution within three hours or less. A feature request is not a support ticket, so the same clock does not apply directly, but the underlying expectation is the same: users notice when nobody is watching. A quick reply that says under review costs seconds and buys weeks of patience.
Common mistakes teams make when tracking requests
The first mistake is running two systems at once, a board for show and a spreadsheet for the real decisions. Users notice when a board is decorative, and engagement drops fast once they realise their vote does not actually influence anything. The second mistake is triaging only the newest posts instead of the highest voted ones, which means loud, recent requests crowd out older ideas with much stronger demand behind them. The third is skipping the shipped notification because it feels like a small detail. It is the single highest leverage step in the whole process, and skipping it quietly erodes the trust the rest of the system is built to earn.
Why this connects to retention
Feature request tracking rarely gets framed as a retention tool, but it behaves like one. Bain's research on customer retention found that a five percent improvement in retention can raise profits by twenty five to ninety five percent depending on the industry, and unresolved, unacknowledged requests are a quiet but steady source of churn. Recurly's benchmarking work puts average subscription churn at around 3.27 percent a month, which sounds small until you multiply it across a year of lost customers who each had a specific, fixable reason for leaving.
Making the system stick after the first month
The system above works, but it only stays working if someone owns it. Assign one person, even a rotating owner, to run the weekly triage and reply to posts. Add a recurring calendar event so the review does not quietly fall off the list when a busy sprint arrives. A board that gets triaged for three weeks and then ignored is worse than no board at all, because it trains users to stop trusting it.
A quick note on scope
This system works for products of any size, from a two person startup to a team shipping weekly across several products. The steps do not change, only the cadence and who is responsible for running them. Start with the smallest version, one board, one weekly hour, and let the process grow as the volume of requests grows with it.
What this looks like in Feedlark
Feedlark handles all five steps from one dashboard. The board is public and free for unlimited users. The widget embeds in a single line of code. Statuses update with one click. AI deduplication runs automatically. When you update a status to Shipped, the changelog entry is created and voters are notified without any additional work from your team, and you can see the full workflow for yourself on Feedlark's signup page.
Frequently asked questions
- How often should I triage a feature request board?
- Weekly works for most small and mid sized teams. Boards with very high volume may need daily attention, while a very quiet early stage board can get by with a monthly pass.
- What is the biggest mistake teams make when tracking requests?
- Running a board for show while decisions are still made in a private spreadsheet. Users notice quickly when their vote does not influence anything, and engagement drops as a result.
- Do I need engineering involvement to track feature requests?
- No, triage and status updates can be handled entirely by product or support staff. Engineering only gets involved once an item is prioritised and turned into a ticket.
- Does tracking feature requests actually reduce churn?
- It reduces one specific cause of churn, users feeling unheard, though it will not fix pricing or product fit issues on its own. Combined with regular shipping and notifications, it is a low cost way to build trust.
Tom Whitfield, Feedlark co-founder. Tom co-founded Feedlark and spends most of his week talking to product teams about how they actually triage feedback.