Closing the loop means telling the people who asked for something what became of their request: at every change of status, and again when it ships or gets a no. On the median public board, half of all requests carry no decision, and 43 percent of boards have never told anybody no in public. On Featurebase boards, 45 percent of shipped requests were announced to their voters by email.
Below are eight replies, one for each point a request reaches, written out in full, and which tools send which of these messages on their own.
How often does a request get an answer?
A read of 634 public Canny and Featurebase boards, 67,473 requests in all, on 3 October 2026, found a decided share of 50 percent on the median board. 43 percent of the boards have never declined a single request in public, and 50 percent have gone 90 days without a new one. Atlassian's own tracker shows the same silence at scale: across 179,402 suggestions on Atlassian's public tracker, 45,849 of the 49,752 still open sit in the first status, Gathering Interest, a median of 1,089 days after they were filed.
Two more cuts of the same rows show which requests get the answer.
Decision rate by votes. Every request on the measured boards, by the status it carries and how many votes it holds. The 1,377 requests at zero votes, 2 percent, are left out.
| Votes | Open | Under review, planned or in progress | Completed | Declined | Requests |
|---|---|---|---|---|---|
| 1 | 52% | 8% | 29% | 11% | 27,358 |
| 2 | 57% | 8% | 28% | 8% | 11,620 |
| 3 to 9 | 53% | 11% | 29% | 7% | 18,792 |
| 10 to 99 | 44% | 16% | 34% | 6% | 7,677 |
| 100 or more | 30% | 24% | 43% | 3% | 649 |
Decision rate holds flat from one vote through nine, 43 to 48 percent of requests carrying a decision whichever of those three rows a request falls in. It then rises: 56 percent decided at 10 to 99 votes, 70 percent at 100 or more. A vote count separates the top of a board from the rest, and says little about anything short of that. The declines run the other way: 11 percent of single vote requests are marked no, against 3 percent of those with 100 votes or more.
Decision rate by age. The same shares, by how long ago the request was created, counted from 3 October 2026.
| Age | Open | Under review, planned or in progress | Completed | Declined | Requests |
|---|---|---|---|---|---|
| 0 to 90 days | 71% | 10% | 16% | 3% | 4,007 |
| 91 to 365 days | 61% | 10% | 25% | 5% | 14,028 |
| More than a year | 49% | 9% | 32% | 10% | 47,521 |
The 1,917 requests with no readable date are left out.
Few requests are answered quickly. 29 percent of requests under 90 days old carry a decision, 39 percent of those 91 to 365 days old, and 51 percent of those older than a year. Past a year, half are still open.
How often are voters told?
Featurebase keeps a record on each request of whether a status update email went out for the status the request now carries. Its help centre says changing a status and messaging customers are separate actions, so the record shows what the team chose to send. A read of every Featurebase host in the study on 3 October 2026, 341 hosts with 10 or more requests, found the record on 10,476 of 14,143 completed requests; requests whose status changed before Featurebase began keeping it carry none.
| Status the request carries | Requests with the record | Status email sent |
|---|---|---|
| Planned | 2,122 | 17.5% |
| In progress | 1,209 | 30.2% |
| Completed | 10,476 | 45.0% |
| Declined | 1,737 | 21.6% |
A shipped request is the one most often announced, and still fewer than half are. On the median host, 32.8 percent of completed requests were announced, a quarter of hosts announced fewer than 5.8 percent, and 51 of the 244 hosts with five or more such requests announced none. A decline is told about one time in five.
Votes raise the odds a little. 34.0 percent of the 4,122 completed requests with one vote got an email, against 51.5 percent of the 4,656 with 2 to 9 votes, 55.4 percent of the 1,467 with 10 to 99, and 46.1 percent of the 128 with 100 or more.
Who needs to hear it?
Three people, and they are not the same person. The poster wrote the request down. The voters agreed with it without writing anything. The commenters added a reason, a workaround or a second case further down the thread. A reply addressed only to the poster misses the other two.
What a feedback loop is covers the full four step version of this. Collecting and closing pull against each other, and the anonymous vote is where they meet. Letting a visitor vote with no account buys more votes and gives up the reply for every one of them. A signed in voter has an email on file and can be told. A cookie has no address, so when the thing it voted for ships, there is nobody to write to, only the board itself to update.
What to send at each stage
Each reply names the request and the next step, fits in a short email or a comment on the card, and assumes a system that can find who asked, not a memory of who asked.
A request arrives
Send it to the poster, within a day of the request landing, before anyone has to ask whether it was read.
Thanks for writing this up, {poster_name}. "{request_title}" is now on the board at {request_url}, where anyone who hits the same thing can vote on it instead of filing it again.
We read every request. If you want to add a screenshot, a link, or the workaround you are using today, the comment box on that page is the fastest way to reach us.
The mistake this avoids: a silent submission. A poster who gets nothing back has no reason to believe the form did anything.
More detail is needed
Send it to the poster, as soon as a reviewer tries to size the request and cannot.
Quick question on "{request_title}": what are you doing today instead of this, and how often does it come up?
That tells us how much this is costing you, which is what decides whether it gets built next quarter or next year. No need to write an essay, a sentence is enough.
The mistake this avoids: guessing at severity from the title alone, and building too much or too little.
It is a duplicate
Send it to the newer poster, at triage, before the request sits unanswered next to the one it duplicates.
"{new_request_title}" is the same thing as an existing request, "{existing_request_title}", so we have merged your vote into it: {existing_request_url}
Your vote and your comment are both there now. Watching that page is the fastest way to hear when it moves.
The mistake this avoids: two open threads for one idea, splitting the votes that would have shown it mattered.
It is planned
Send it to everyone who voted or commented, the day the status changes, naming a quarter rather than a date if the date is not fixed yet.
"{request_title}" is now planned for {timeframe}. It is not built yet, but it has a place on the roadmap and a quarter attached to it.
We will write again when it moves into progress, and once more when it ships.
The mistake this avoids: "planned" used as a polite way to end the conversation with no second message ever sent.
It is in progress
Send it to the same list, when work starts, with no promise of an exact ship date unless one is already fixed.
Work on "{request_title}" has started. We cannot promise an exact date yet, but it has moved from the roadmap into active work.
The next message you get about this one will say it shipped.
The mistake this avoids: going quiet between planned and shipped, which is the stretch where a voter assumes the request was quietly dropped.
It shipped
Send it to every voter and commenter on the request, the day the release goes out, naming the heading they voted for rather than the whole release.
"{request_title}" is live as of {release_date}. You asked for this on {request_date}, and it is now in the product.
Full notes on everything in this release: {changelog_url}
The mistake this avoids: one email about the whole release with the voter's own request buried in a list of ten others.
Declining it
Send it to the poster and every voter, with a reason and an alternative where one exists, and never silently.
We have decided not to build "{request_title}". {reason_for_declining}
{alternative_if_any}
The request stays on the board marked declined, with this note attached, so anyone who finds it later sees the answer rather than a dead end.
The mistake this avoids: a card that vanishes instead of one marked no. A dropped request looks identical to a forgotten one, and a visitor cannot tell which.
Not now, but kept open
Send it when a request is read and agreed with but has no place on the current roadmap, so voters know the difference between a no and a later.
"{request_title}" is a real problem and it is staying open on the board. It is not on the roadmap for {current_period}, so do not expect it soon, but it has not been declined either.
If this is blocking something for you today, say so in a comment and that changes how we weigh it.
The mistake this avoids: treating silence as a maybe, when a reader cannot tell a later from a quietly declined request without being told which one it is.
JetBrains gives this answer a state of its own on its public tracker. Shelved, as the IntelliJ team defines it, is for a request reviewed and found to have merit that the team cannot plan for now, and 7,765 of 149,466 JetBrains feature requests carry it, filed a median of more than ten years ago. GitLab has one too. Its Awaiting further demand milestone holds issues it has triaged but kept off the backlog until more customers ask, and the median open feature issue there has one upvote after almost six years.
Which tools send which message
Read from each vendor's own help pages on 3 October 2026.
| Tool | On status change | On ship | On a team reply |
|---|---|---|---|
| Canny | Automatic by default, with an opt-out | Automatic, same mechanism | Automatic, named as its own category |
| Featurebase | Admin has to trigger it each time | Admin has to trigger it each time | Not read |
| Fider | Automatic, on by default | Automatic, on by default | Automatic, a separate notification |
| Frill | Automatic | Automatic, through an announcement | Automatic |
| Nolt | Automatic by default, to the poster, commenters, upvoters and subscribers | Automatic, shipping is a status change | Automatic, to the poster, commenters and subscribers, not upvoters |
| Productboard's portal | Admin has to compose and send it | Admin has to compose and send it | Not published |
| Sleekplan | Automatic | Automatic | Not published |
| Upvoty | Not read beyond the one line below | Automatic, its own marketing line | Not read |
| UserJot | Automatic, poster, voters and commenters together | Automatic | Not published as a separate trigger |
| VoteFirst | None | Automatic, to signed in voters whose own vote is on the release, naming their requests | None |
VoteFirst sends exactly one of these messages automatically: the release email, and only to a voter who was signed in with an account when they voted. Nothing goes out when a request is marked planned, in progress or denied, and nothing goes out when the team comments on a card. A decline is visible rather than announced: the public roadmap keeps a Denied column shown by default, so the answer sits on the card for anyone who looks, but nobody is told to go looking. The eight replies above are what fills that gap by hand.
Closing the loop with no tool at all
A spreadsheet does this at small numbers. One column for the request, one for every email address that asked for it, a status column, and the discipline to open it and send something the day the status column changes. The request log on the template page already has columns for who asked, the people on it, the status, the decision and the reason.
It works as long as a request has a handful of people on it and the list does not have to be reconstructed from four different systems months later. Four loops written out end to end show where that reconstruction is the part that actually fails.
Method
Read 3 October 2026. The population is the study's own: every public Canny or Featurebase board with 10 or more requests that could be read whole, 634 boards and 67,473 requests, each request's vote count, status and creation date read through the same public endpoints the board importer reads, with no sign in.
The board rows carry no reply or comment field. The one record of a message is Featurebase's status update field, read the same day from every Featurebase host in the study through the same public endpoint: whether an email went out for the request's current status, sent or marked not sent, counted only where the field is present. Canny's public endpoint carries no such field, so its boards are not in that table.
14 days, a card at signup, then $9 or $39 a month.