Let me apply a customer segment (or contact group) filter to the requests list so I only see feedback from that segment, with counts/stats updating for the filtered view.

Next to the 👍 🎉 ❤️ reactions on a changelog update, readers get a 🤷 Not for me button. It says the update wasn't important to them, not that it was bad. You see how many people liked each update and how many shrugged, as a share of everyone who reacted. That shows which releases landed and which ones your users didn't care about, without anyone having to write a comment. When an update covers several shipped requests, readers could react to each one, so you can tell which part people wanted. The Not for me count could be shown only to your team, so a small product never has a pile of shrugs on its public changelog. The changelog email could carry the same buttons, since that's where most readers see an update. A tap would open the update with the choice ready to confirm, so email scanners that open links on their own don't count.

Supports linear integration and status updates.

Connects Notion to the platform.

Board owners can create and sign into their Featurevote account using Discord or Patreon.

A member types /featurevote ask in your Discord and writes a question, like "is controller support coming?". Featurevote searches your board, roadmap and changelog and answers in the channel. The answer names the request it found, its status and how many votes it has, with a button to vote on it. If nothing on the board matches, it offers to post the question as a new request. Communities get the same questions again and again in chat, mostly whether something is planned and when it ships. The answers are already on the board, so this gives them out where people ask, and sends people to the board to vote. It would only answer from what is public on your board.

When someone writes in asking for something that is already on your board, add their vote to that request from the conversation itself. You already know who wrote in, so there is no email to type. They then hear from you when the request ships, like everyone else who voted.

When a changelog is posted to your Discord channel, Featurevote could tag the members who asked for the requests in it. They get a Discord notification, so someone who suggested an idea from Discord hears that it shipped, even with no email address on file. It would cover changelogs made from your completed requests. It could tag only the people who asked, or their voters too. Builds on posting changelogs to a Discord channel, which is live.

Open a request, pick anyone in its voter list, and send them a private email from Featurevote. Ask what they are trying to do, or what they would use it for. Their answer comes back to your own email, and nothing about it shows on the board. Only voters who left an email can be reached. Today Reply on Home reaches the person who posted a request, while they wait for a first answer. People who voted later can only be reached from your own mail app. The most common advice from small teams is to ask why before you count a request. People ask for a fix, and the problem behind it is what you weigh.

Reply to a changelog update with a written comment, to ask a question about what changed or say what you think of it. Emoji reactions on changelog updates are already available. This request is for written comments on top of them. One idea raised by a customer: if a comment turns out to be a new feature idea, let the team turn it into a proper request in one click, so good ideas don't get lost in a comment thread.

Ask one question with options. Each answer's weight depends on the patron's tier. View results broken down by tier.

Give your board an email address. Forward your support@ address to it, or hand the address out directly, and every message lands in your Featurevote inbox as a conversation. You reply from inside Featurevote. The reply goes out under your own name and domain, and when the customer answers, it lands back in the same conversation instead of in someone's personal mailbox. Each conversation is open, waiting on the customer, or closed, and you can hand it to a teammate. Conversations nobody has answered show up on your home page next to the requests waiting for a word from you. When a message asks for something, attach it to a request on your board, or create the request from it. Featurevote suggests the matching request and shows how many other conversations asked for the same thing. When that request ships, everyone in every attached conversation gets the email saying so. Saved replies for the answers you type often, and an AI draft that reads the conversation, your board and your changelog before suggesting a reply. Messages from your feedback widget, Slack and Discord land in the same inbox. This grew out of a conversation with a customer who said a feature board falls between support, product and engineering because nobody's job is to open it. If the support inbox is the board's front door, the board gets an owner without anyone having to remember it.

When a few new requests have come in since your last email, Featurevote could let you send your subscribers a short email listing them, with a link to vote on the ones they think should be built. You decide when it goes out. Featurevote tells you something like "5 new requests since your last email", you check the list, remove anything you don't want to promote, and send. It could also work on a schedule, like every two weeks, for teams that run their board in rounds. Not everyone who votes leaves an email, so a post to a Discord channel could be another way to reach people.

Connect your board to the other tools you use without writing code. For example, put every new request into a spreadsheet, post it to a channel, or create a card in whatever you plan your work in. This would cover the tools we do not integrate with directly.

Write an update when the work is done, pick the day and time it should go out, and let Featurevote publish it and send the email for you. Useful when a release goes live on a set date, or when you want the update to land in the morning rather than whenever you finished writing it.

Requests move through a fixed set of statuses today, and there is no way to group them by area. This would let you name the statuses yourself, so the roadmap uses your words rather than ours, and sort requests into categories such as mobile, billing or docs. People visiting your board could then filter to the part they care about.

Keep more than one board in the same place, for example one per product, or one for feature requests and one for bugs. Today each board is its own workspace with its own plan, so running two means setting up and paying for two. This would let one account hold several boards, with the same team and one subscription behind them.

Integrate Slack to allow users to submit feature requests directly from the slack platform.

Notify customers when a request is planned, delayed, or shipped

Link one request to multiple customers and accounts

Import feedback from email, discord and Slack.