Skip to main content
Voting helps you understand which requests matter to users, but votes should be one signal in your prioritization process rather than the only signal. Use votes together with customer context, product strategy, effort, revenue impact, and support volume to decide what to build next.

​
How voting works

When voting is enabled for a board, users can vote on posts they care about. Vote counts make demand visible to your team and to other users on the public portal. Votes are useful for:
  • Identifying popular feature requests
  • Finding repeated pain points
  • Comparing demand across related ideas
  • Showing users that feedback is being considered

​
Review high-signal feedback

Use this workflow during feedback triage:
1

Sort by vote count

Review posts with the strongest user demand first.
2

Read comments and details

Look for business context, workflows, affected user segments, and repeated use cases.
3

Apply tags and priority

Tag related themes and set priority for internal planning.
4

Update status

Move posts to the right status so users can see what is under review, planned, in progress, or complete.

​
Use priority carefully

Priority is an internal planning signal. A highly voted request may still be low priority if it does not fit your product direction or requires disproportionate effort. Good priority decisions usually consider:
  • Number of affected users
  • Severity of the problem
  • Strategic fit
  • Implementation effort
  • Enterprise or key-account impact
  • Dependencies and timing
Owner and priority information is intended for your team. Public users should see clear status and communication, not internal planning details.

​
Close the loop

When you update a post status, add a short comment explaining what changed. This builds trust and reduces repeated support questions. Examples:
  • Planned: Explain what problem you plan to solve.
  • In Progress: Share what is being worked on without overpromising dates.
  • Completed: Link to the release note or changelog entry when available.
  • Closed: Explain why the request will not be built.

Roadmap and status

Turn prioritized feedback into a public roadmap.

Changelog

Announce shipped changes and connect them back to user feedback.