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

# Boards & Voting

> Run public feedback boards, manage posts and statuses, and see the people and companies behind every vote

A **feedback board** is where customers post ideas and vote on them. It is the public half of your feature-request pipeline.

## Posts

Each post on a feedback board carries a title, body, and a status. You can create posts yourself — useful when you want to seed a board, or surface a request that came in through a call rather than the portal — and you can edit or delete them.

Posts are the unit customers vote on, so keep one post per idea. Two posts for the same request split the demand signal and make the board look busier than the underlying need actually is.

## Statuses

A board's **status columns** define the states a post can be in. The default set is:

| Status          | Means                  |
| --------------- | ---------------------- |
| **Planned**     | Committed, not started |
| **In Progress** | Being built now        |
| **Shipped**     | Released               |

Setting a post's status is what moves it on the public [Roadmap](./roadmap) — the roadmap is a view over these columns, not a separate artifact you maintain.

<Tip>
  Only set **Planned** on things you actually intend to build. A public board makes the roadmap a soft commitment, and moving items back out of Planned is the fastest way to lose trust in it.
</Tip>

## Voting

Votes are attributable. For any post you can list its **voters** — the people who voted and the companies they belong to.

That matters more than a raw count:

* **Ten votes from one account** is one customer with a strong opinion.
* **Ten votes from ten accounts** is a market signal.
* A count alone can't tell you which you have.

You can also add a voter to a post directly, for when someone asks on a call rather than through the portal, so the public tally reflects real demand rather than portal-participation rates.

## Post Matching

Customers only post a fraction of what they ask for. The rest arrives in calls, tickets, and conversations, where BuildBetter already extracts it as feature requests.

**Post matching** connects the two. For a given post you can list its candidate matches from your extracted feedback, then apply a match to link them. The result is one item carrying evidence from both the public board and every private conversation that touched it.

<Note>
  This is the difference between a portal that reflects what customers bothered to type and one that reflects what they actually said. Review matches for anything you're about to prioritize.
</Note>

## Visibility

Boards are `public` or restricted, and can be disabled without being deleted. Running a board privately while you find your footing — then flipping it public once the statuses are honest — is a reasonable way to start.

## Next

<CardGroup cols={2}>
  <Card title="Roadmap" icon="map" href="./roadmap">
    How status columns become the public roadmap.
  </Card>

  <Card title="Changelog" icon="megaphone" href="./changelog">
    Publishing what shipped.
  </Card>
</CardGroup>