A feature request tool that weights votes by revenue exists because every feature request board has the same problem. The requests with the most votes are the ones the most people wanted, and the people who pay you are almost never the most people.
VoteFirst lets you put a number on that. You define your voting tiers, you give each tier a multiplier, and a vote from a customer on that tier counts for the multiplier instead of for one.
Putting a voter on a tier from your own application is one API call. The board still shows you the plain headcount beside it, so you can always see both.
This page explains exactly how the number is built, because a prioritisation number you do not understand is a number you will not trust at the moment you need it.
How do I prioritize feature requests by how much the customer pays?
You create voting tiers, you set an integer multiplier on each one, and you assign each voter to a tier. When somebody votes, the weight of that vote is their tier's multiplier.
That is the whole mechanism. A tier called Enterprise with a multiplier of 5 makes one vote from that customer count as five, and a vote gets cast the same way it always does. A voter you have not assigned to any tier counts as one.
There is a second, separate number on a tier, which is monthly revenue. It is used for the revenue figures on your board and it never multiplies anything. The multiplier decides the weight, the revenue figure decides what you see when you ask how much money is behind a request.
Keeping them apart is deliberate, because the moment a weight is computed from a currency amount you get a board where a rounding difference changes the order of your roadmap.
That is the behaviour as it ships, and a trial runs 14 days with a card at signup if you would rather confirm it than read it.
Can I sort my roadmap by MRR instead of votes?
Yes, and the two are different columns rather than two names for the same thing.
The revenue behind a feature is the sum of monthly revenue across the voters who voted for it. If a voter has a personal revenue figure set, that one is used instead of their tier's. The card shows it as a whole dollar amount with the cents dropped.
The weighted vote total is a separate number, the sum of the weights of every live vote. It is always a whole number, because every multiplier is a whole number and nothing is ever rounded.
If you read the board through the API rather than the dashboard, the two totals are two different sorts. Ranking by votes is always the plain headcount whatever the project weights by, and ranking by top follows the score, which is the weighted total when weighting is switched into it.
Pinned cards lead every sort, and every sort breaks its ties on the card id so paging can neither repeat a card nor skip one.
You can also rank by demand, which combines votes, comments and views into one score, and you can tell VoteFirst to use the weighted vote total inside that score rather than the plain one.
That is a separate switch from weighting itself, so you can weight votes without changing how demand is calculated, or do both.
How do I stop one customer dominating the board?
Choose small multipliers, and watch the two totals diverge.
This is the question the whole category avoids and it deserves a straight answer. The multiplier is a policy you write, not a fact about your revenue.
If you set your top tier to 40 because that customer pays forty times your smallest one, you have not modelled your business, you have handed one account a veto. Everything they vote for goes to the top and everything nobody there cares about sinks, and after a month your roadmap is that account's roadmap.
The field itself will take any whole number from 1 to 100. Anything you type below 1 is stored as 1, and anything above 100 is refused rather than quietly clamped, so the range is a real one and the ceiling is not a suggestion. That does not make 100 a sensible choice.
Small integers do the job. A top tier at 3 or 5 lifts your paying customers above the noise without letting any single one of them outvote a room.
If four people on your middle tier want something and one enterprise account wants something else, you want to see that as a real contest, not as a settled question. Put your own tiers in and watch the two totals move, because the gap between them is easier to see than to describe.
The reason this stays visible is that VoteFirst never throws the plain count away. Both totals sit on the same card. The category has a name for the problem this section is about. If you are still deciding whether voting is the right mechanism at all, that question is answered here.
When a feature has a high weighted total and a low headcount, that is one large customer, and you can see it at a glance rather than discovering it in a planning meeting.
What do I do with a request from someone who does not pay?
Nothing special. Their vote counts as one, it stays on the board, and the public sees it.
A voter with no tier assignment weighs exactly one. A tier with a multiplier below one is also read as one, so there is no way to configure a voter into counting for less than a person. Weighting can lift a customer above the baseline and it can never push anybody below it.
That matters more than it sounds. A free account that files a clear, well argued request is often the first sign of something your paying customers will ask for in six months. Weighting is there to stop you being deafened, not to stop you listening.
Do my customers see the weighted score?
On the hosted page, no. In the embedded widget, yes.
On the hosted public board they see the plain count, and when they vote the number they get back is the plain count.
One exception, and we would rather write it here than let you find it. The embedded widget publishes a score beside the plain count, and that score is the weighted total whenever the demand score switch is on.
Read that sentence again, because the switch it names is the second one rather than the first. The widget follows the demand score setting, not weighting itself, so you can weight your own ordering and leave the widget publishing a headcount.
Whichever way you set it, the payload carries a flag next to the score saying whether that score is weighted, so a developer building against it never has to guess. Turning the vote counts off on a board hides the score along with them, because one setting publishes both.
Multipliers, tier names and revenue figures are never public anywhere. The two endpoints that read money refuse the embed key outright, and the embed key is the one you paste into your own HTML, so nobody reading your page can work out what an individual pays.
That is the right way round, and it is worth saying why rather than presenting it as a feature. A public board that displayed how much each voter was worth would tell your smallest customers exactly where they stand, and it would tell your competitors your tier structure.
The weighting is a tool for the person deciding what to build. It is not a scoreboard for the people asking.
Does a vote from a trial account count?
It counts for whatever tier you put them in, and if you have not put them in one, it counts for one.
VoteFirst does not know which of your voters are on trial unless you tell it. Voters arrive with the revenue data you import from Stripe, from Paddle or from a CSV file, and the tier assignment follows from what you set up.
There is no automatic rule that treats a trial differently, and that is a deliberate absence rather than a gap, because whether a trial vote should count for more or less is a question about your business rather than about software.
Why did importing my customers not change any votes?
Because an import files the tier against an email address, and a vote is weighted through the voter who cast it.
This is the one part of weighted voting that surprises people, so here is all of it in one place. Every importer, Stripe, Paddle and the CSV file, writes the tier onto a row keyed by the customer's address. Nobody ever votes as that row.
Your voters are the people who pressed a button on your board, and every query that turns a tier into a number joins the tier to the voter who voted. That is true of the weighted total on the card, of the money badge beside it and of the revenue screen.
So an import gives you the money picture and it does not, by itself, move a vote. What connects the two is assigning the tier to the voter on the voters screen, either one voter at a time or a whole selection at once.
There is a second route on PRO, because a voter who signs in through your own single sign on carries their address with them, and a vote from that voter picks up an imported tier with a matching address without you doing anything.
We would rather put that under a heading than in a support reply.
What breaks when the revenue data is the shape real data is in?
Four things, and the first is invisible because it changes a number nobody is watching.
An annual plan typed in as it appears on the invoice. The CSV reader takes any column named mrr, revenue, monthly_revenue or amount, strips a dollar sign and the thousands commas, multiplies by a hundred and stores the result as cents. The field it stores into is a monthly figure. Nothing divides by twelve, nothing asks you which it was, and nothing can tell 12000 from 1000 after the fact. Work it through with two customers. One pays 12,000 dollars a year, which is $1,000 a month. One pays 1,200 dollars a month. Read correctly the monthly customer is the larger of the two and should sit above the other. Take the annual figure off the invoice and type it in as it appears, and the first arrives as ten times ahead instead of slightly behind.
Here is the part worth the heading. That mistake does not touch a single vote weight, because weight comes from the tier's multiplier and the revenue figure multiplies nothing.
The ordering by votes looks exactly as it did, no total changes, nothing looks broken, and the money beside each request is wrong by an order of magnitude for precisely the customers you most wanted to read correctly.
A defect that changes a number you are watching gets found in a day. This one changes a number you are trusting. Divide by twelve before the file goes in.
A half filled row. A row carrying neither a tier name nor a revenue figure still creates the voter. It just gets no tier, so a half filled row leaves you exactly the voter that quietly weighs one. Fill both columns or leave the row out.
A customer who cancelled. Their votes stay on the board and each one keeps the weight it was given on the day it was cast. Churn is a separate mark on the voter, set by a cancellation webhook, cleared when a new active subscription arrives, and switchable by hand. It deletes nothing and it reweighs nothing. Run a board for a year with a weighted top tier and some turnover and part of your ordering is the opinion of people who left, which never announces itself, because a stale weight looks identical to a live one. The recalculate button below is the repair, and the useful habit is pressing it after any large import or any month with real churn in it rather than once when something already looks wrong.
A weighted total that matches the headcount. Four separate things make the weight function return a one. No tier assignment is one. A multiplier somebody typed below one is another, since anything under one is read as one. Weighting being off is the third, and an honest multiplier of one is the fourth. The number is the same in all four, so a one carries no information at all. If your weighted total matches your headcount, that is not evidence the weighting is working and not evidence that it is not, and the only way to tell them apart is to open the tier and look.
The keys you paste in for the Stripe and Paddle importers are encrypted with AES GCM under a 32 byte key before they reach the database.
What happens if I turn weighting off?
Your board is a headcount again on the spot, and the weighted numbers behind it sit where they are until you clear them.
The plain count was never weighted. It is a count of rows, so the moment the switch goes off your ordering is people again and nothing has to be rebuilt for it.
What does not change on its own is the weighted total, because the weight is stamped onto each vote when it is cast rather than worked out each time it is read.
The same is true the other way round. Change a multiplier, or move a customer up a tier, and the votes they already cast keep the weight they were given.
There is a button for that, on the voters screen, named Recalculate vote counts. It rewrites every vote to the weight its voter's tier says today and recounts every feature in the project.
Only the project owner can press it, and it is hidden while weighting is off, so the tidy order is to press it first and turn the switch off after.
This is the part people ask about last and worry about most. You can try weighting on a real board, look at what it does to your ordering, and undo it, and the only thing you lose is the time it took to look.
The weighted total also feeds the demand score on every card, and the coefficients that score uses are published in full.
14 days, a card at signup, then $9 or $39 a month.
What this costs
Weighted voting is on the LITE plan at nine dollars a month, which covers one project. PRO is thirty nine dollars a month and adds more projects, the API and a custom domain.
There is a fourteen day trial on whichever plan you choose, and a card is required to start it. You can cancel from the dashboard.
We charge one price whatever the board does. There is no charge per tracked user, so a board that suddenly gets popular costs the same as one that does not. If you are currently paying by tracked user, the calculator works through what that unit actually costs as a board gets busy.
The honest summary
Weighted voting is a small mechanism and no more than that. An integer on a tier, frozen onto each vote, summed into a second total that sits beside the first one. It will not tell you what to build.
What it does is stop the loudest group and the largest customer looking identical on the same screen, which is the exact confusion that makes a feature request board slowly stop being useful.
If that is the problem you have, it is nine dollars a month, you can turn it off again, and our own board runs on it.