> ## Documentation Index
> Fetch the complete documentation index at: https://help.suggix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Voting and Prioritization

> Use votes, comments, tags, priority, and ownership to decide what to build next.

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:

<Steps>
  <Step title="Sort by vote count">
    Review posts with the strongest user demand first.
  </Step>

  <Step title="Read comments and details">
    Look for business context, workflows, affected user segments, and repeated use cases.
  </Step>

  <Step title="Apply tags and priority">
    Tag related themes and set priority for internal planning.
  </Step>

  <Step title="Update status">
    Move posts to the right status so users can see what is under review, planned, in progress, or complete.
  </Step>
</Steps>

## 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

<Note>
  Owner and priority information is intended for your team. Public users should see clear status and communication, not internal planning details.
</Note>

## 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.

## Related guides

<CardGroup cols={2}>
  <Card title="Roadmap and status" icon="map" href="/guides/roadmap">
    Turn prioritized feedback into a public roadmap.
  </Card>

  <Card title="Changelog" icon="list-check" href="/guides/changelog">
    Announce shipped changes and connect them back to user feedback.
  </Card>
</CardGroup>