To prioritise feature requests, collect them on one board, attach the account behind every vote, score each request on value, confidence and effort, and tell the people who asked what you decided. Most teams do not have a prioritisation problem. They have a data problem: the requests live in six places, nobody knows which accounts asked, and the spreadsheet that was supposed to fix it went stale three sprints ago. Prioritisation only becomes easy once every request has votes, an owner and a revenue number attached to it.
Stop scoring what you have not centralised
A scoring model applied to an incomplete list produces confident nonsense. Before you rank anything, consolidate intake: support conversations, sales calls, in-app submissions and internal ideas all land on one board with one set of categories.
Centralising is also what makes duplicates visible. Three tickets that each look minor are often one theme with more demand behind it than the feature you were about to build.
Weight votes by who is voting
Raw upvote counts favour whoever is loudest, which is usually your free tier. Attach plan, MRR and renewal date to each voter so a request with eleven votes from enterprise accounts outranks one with sixty votes from trials.
Context like this is what lets engineering trust the board. 'Forty-two votes' is an opinion; 'forty-two votes representing $310k of ARR, nine of it renewing next quarter' is a decision input.
Score on value, confidence and effort — nothing more
RICE, WSJF and value-versus-effort all work. What kills them is field sprawl: once a model needs nine inputs, nobody fills it in. Keep three, make two of them automatic, and let the third be a human estimate.
Re-score quarterly, not weekly. Scores that move every standup are noise, and they teach stakeholders that lobbying works.
Close the loop or the data decays
Every request that ships should notify the people who asked for it. In our experience, when customers never hear back, they gradually stop posting, and the board drifts into a graveyard that no longer represents demand. We have no clean figure for how fast that happens; it varies with how engaged your customers were to begin with.
Linking each changelog entry to the requests it resolves, so the people who voted are told automatically, is one of the cheapest ways to keep contributors coming back.
What to look for in tooling
You need account context on votes, a status model your team actually uses, and pricing that does not punish you for inviting the whole company into the conversation. Per-seat pricing quietly caps how much of your organisation can participate.
Compare how the major tools handle each of those before you commit — the differences are largely in pricing model and account context, not in whether they can render a list of ideas.
A worked example
The requests and figures below are invented to show the method; they do not come from any real team. Take three requests from a quarterly review of a B2B product.
Request A, bulk editing for tasks, has 48 votes, almost all from free and trial accounts, and the comments describe a convenience rather than a blocker. Request B, SAML single sign-on, has 9 votes, every one from a paying account, and two of those accounts have told their account manager that renewal depends on it. Request C, exporting reports to PDF, has 21 votes from a mix of plans, and support tags show it coming up most weeks.
Score each on the three inputs. Value comes from weighted demand, so A is low despite its count, B is high and C is medium. Confidence comes from the evidence: B is high because customers named it as a blocker, C is high because the support volume is measurable, and A is low because nobody has said what they would do with it. Effort is the team's estimate.
On those scores C goes first: real demand, strong evidence and a moderate cost. B comes next, and scoping should start now, because its value sits in two renewals with dates attached. A waits, and the reply on the post should say why and what would change the decision, such as paying customers voting for it or someone describing the workflow it would unblock.
The ranking is not the real output. The output is a reason for each decision that you can write on the post, which is what voters actually want to read.
| Request | Votes | Value | Confidence | Effort | Decision |
|---|---|---|---|---|---|
| A: bulk edit | 48 | Low | Low | Small | Wait, and say why |
| B: SAML SSO | 9 | High | High | Large | Scope now, build next |
| C: PDF export | 21 | Medium | High | Medium | Build first |
Run triage on a fixed rhythm
Prioritisation fails quietly when it only happens at planning time. By then the board holds hundreds of unread posts, duplicates have split the votes, and the scores are guesses. A short weekly triage keeps the inputs clean, so the quarterly decision is quick.
Give triage an owner and a standing slot, thirty minutes to an hour depending on volume. The owner does not decide what gets built. Their job is to make sure every new post is readable, merged where it duplicates something, tagged and answered, so that whoever does decide is working from a clean list.
A weekly triage checklist
- Read every post that arrived since the last session and reply to each, even if only to say it has been seen.
- Merge duplicates into the clearest post so votes stop splitting.
- Rewrite titles that name a solution so they describe the problem, keeping the customer's own words in the details.
- Tag each post with the product area it touches.
- Record account context the board cannot show, such as a renewal date or a deal at risk, in a team-only note.
- Move anything you have decided on to a status, and leave a one-line reason when you decline.
Common prioritisation mistakes
Most of these come from treating the board as a ballot rather than as evidence.
- Building the top-voted item by default. Votes say where to look, not what to build, and a request with the most votes and no paying customer behind it can usually wait.
- Letting the largest account set the roadmap. Revenue weighting needs a cap per account, or one customer's wish list becomes the plan.
- Scoring before merging. Three duplicate posts each look minor; merged, they may be the biggest theme on the board.
- Hiding the reasoning. A decline with no reason reads as 'nobody looked'. One honest sentence keeps the customer posting.
- Re-scoring every week. Scores that move constantly reward lobbying and wear out the people filling them in.
- Leaving bugs on the feature board. Customers should not have to vote for the product to work, so route defects to a separate queue with a severity.
How to tell whether it is working
You cannot judge prioritisation by whether the roadmap looks sensible. Measure the inputs and the follow-through instead.
Track how long a new post waits for its first reply, the share of posts that leave Open within a month, and how many shipped items began as customer requests. Watch the duplicate rate as well: if the same request keeps arriving in new words, people are not finding the existing post, or its title does not describe the problem the way customers do.
The test that matters most is a conversation. Ask the engineering lead whether they trust the board enough to plan from it, and ask sales whether they can answer 'is this on the roadmap?' without asking product. If either says no, the data is still missing context, and another scoring field will not fix that.
Prioritising feature requests in Looph
Looph collects requests on feedback boards, where each signed-in person has one vote per post. The team inbox works across every board, filters by board, status, tag and posts assigned to you, and sorts by Trending, Top, Newest, Oldest or Recently updated. Similar posts appear while a customer types a new title, and merging moves votes, comments and followers onto one post while counting each voter once. Team-only internal notes hold the account context you would not put on a public post.
Looph does not score requests for you: there is no RICE or effort field, and votes are not weighted yet. Weighting votes by plan or revenue is coming soon. Until then, export the current inbox view to CSV, which includes each post's status, votes and comment count, and join it with your own billing data in a spreadsheet. When a request ships, link it to a changelog entry and everyone following it is told. Voting and prioritisation covers the settings, and the feature request board template is a recommended setup.
Read next: Feature voting · Changelog
Frequently asked questions
What is the best framework for prioritising feature requests?
The one your team will keep filling in. RICE, value versus effort and weighted scoring all work if the inputs are honest and the model stays small. Value, confidence and effort are enough for most teams.
Should the most-voted feature always be built first?
No. Votes show where demand is, not who is asking or what it would cost. Weight votes by the customers behind them, then set them against effort and strategy before deciding.
How often should you re-prioritise feature requests?
Triage new requests weekly, and re-score the backlog quarterly or when strategy changes. Scores that move every week encourage lobbying.
How do you say no to a feature request?
Move it to a declined status with one sentence explaining why, and say what would change the decision. Customers accept a reasoned no far more readily than silence.
How should you handle requests from one very large customer?
Record the account and its renewal date against the request, then treat it as one input among several, with a cap on how much any single account can count. If a few accounts make up most of your revenue, handle their needs through account plans and a private board.