Boards & Voting

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: Setting a post’s status is what moves it on the public Roadmap — the roadmap is a view over these columns, not a separate artifact you maintain.

​

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.

​

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