← Revenue weighted voting

Import customer revenue onto your board

Weighting a vote by what somebody pays needs one thing first, which is knowing what they pay.

There are three ways to import that, being Stripe, Paddle and a CSV of MRR, and the honest news is that none of them changes anything on your board by itself. The API route that writes a voter's plan and revenue is documented with its fields.

What can I connect?

Stripe, Paddle, and a CSV file you upload.

Stripe and Paddle are connections, so once they are made they keep a customer's revenue and tier in step without anybody doing it again. The CSV is a file, so it is accurate on the day you upload it and stale the day after.

Both are available on a trial, and a trial runs 14 days with a card at signup.

Three more connectors are listed on the same panel and marked coming soon, and this page is not going to describe them as though they work. What ships today is those three.

The import connections panel, offering Stripe, Paddle and a CSV upload to pull customer revenue in
Where revenue comes from: Stripe, Paddle, or a CSV.

Why did importing my customers not change any votes?

Because the import fills in what people pay, and the multiplier is a separate number you set.

This is the single most common surprise, so it is worth being blunt. Revenue and vote weight are deliberately two different things.

A tier carries a multiplier, which decides how much a vote from that tier weighs, and it carries a monthly revenue figure, which decides what you see when you ask how much money is behind a request. Importing revenue populates the second one. Nothing about the first one changes until you say so.

The reason to keep them apart is that a weight computed from a currency figure gives you a board where a rounding difference or a mid month upgrade silently reorders your roadmap. A multiplier is a number a person chose and can defend.

The tier list, where Enterprise votes count five times, Pro three times and Free once
Tiers and their multipliers: an Enterprise vote counts five times.

How does a voter get matched to a customer?

By the profile, and the assignment records where it came from.

Every tier change on a voter carries its source, which is one of manual, Stripe, Paddle, CSV or the API. That is not bookkeeping for its own sake. The first time an imported tier disagrees with one somebody set by hand, the source column is what tells you which is which.

The voter list, one row per person, showing where each arrived from and how many requests and comments they have left
Everyone who voted, one row each, no account required.

What does a connection keep in sync?

Revenue and tier membership, and it also tells you when somebody leaves.

A cancellation at the payment provider marks the voter as churned without anybody typing anything, which is the part that decays fastest when it is done by hand. Their past requests and comments stay exactly where they are. What changes is that they stop counting toward what you build next.

Is my revenue data exposed anywhere?

No, and the API is explicit about it.

The one endpoint that reads what customers pay refuses an embed key outright rather than answering with an empty result. An embed key sits in a public web page by definition, so the refusal is the only safe behaviour. Reading revenue needs a key that lives on your own server.

Nothing about revenue appears on the public board either. What your visitors see is the plain vote count, and the weighted total is a number for your side of the product.

The insights rail beside the voter list, counting total, new and active voters, how many carry revenue, where they arrived from, and the requests with the most revenue behind them
The rail counting voters, revenue, and which requests carry money.

Where this stops

Five limits, stated before you plan around them.

Three connectors are marked coming soon and do not work today. Lemon Squeezy, Braintree and HubSpot are on the panel and are not available.

A CSV is a snapshot. It is right on upload day and wrong by degrees after that. Only the two connections stay in step.

Importing revenue does not weight anything. The multiplier is yours to set, and a board where every tier is still at one times is a board where the import changed no ordering at all.

Coverage decides whether any of it means anything. If most of your voters are not matched to a customer, the weighted count on a request is mostly unweighted votes. The tier coverage figure on the insights rail is the number to read before trusting an ordering.

It knows nothing about people who never voted. An import fills in the customers you already have votes from. It does not bring the silent majority onto your board.

This suits a team whose voters are already customers in Stripe or Paddle. A team whose feedback comes mostly from people who have never paid gets a board of unmatched voters, and the plain count is the honest number for them.

What this costs

Weighted voting is on every plan including Lite, and so are the imports. There is no revenue tier gate.

The trial runs 14 days with a card at signup, then $9 a month for Lite or $39 for Pro.

The honest summary

Two live connections and a file. They fill in what people pay and who churned. They do not set a multiplier, they do not reorder a board, and they are only as useful as the share of your voters they actually match.

Weighting is the page that explains what the multiplier then does, and the voter list is where the matched customers land.

14 days, a card at signup, then $9 or $39 a month.

Related reading

Weight feature requests by what the customer pays Customer feedback, and the voter list behind every count A feature request board that needs no account to vote