One board per decision, not per team
The most common setup mistake is creating a board per internal team. Customers do not know your org chart. Create boards around the decision being made, such as feature requests, bug reports or integrations wanted, and use tags for the finer cuts.
Creating the board
A board needs a name and a URL slug; everything else can be changed later. The board lives at your workspace address followed by its slug, such as yourname.looph.ing/feature-requests, and each post gets its own page under /p/.
- 1Open Admin, then Boards, and choose New board.
- 2Enter a name and check the URL slug.
- 3Add a description, and pick a colour and an emoji icon.
- 4Choose the visibility, then who can post, who can vote and who can comment.
- 5Tick Require approval before posts go live if you want to review posts first.
- 6Choose Create.
Visibility and permissions
Public boards can be viewed by anyone with the link and are indexable by search engines. Private boards are seen only by your workspace members and the emails or @domains on the board's allowlist, which suits enterprise customers, beta programmes and internal requests.
Who can post, Who can vote and Who can comment each take one of three values: anyone who can view the board, workspace members only, or admins only. A board where only your team posts but customers vote and comment is one setting away.
Statuses
Statuses are the public contract you make with the people who voted. Every workspace uses the same set: Pending approval, Open, Under review, Planned, In progress, Complete, Closed and Rejected. You cannot add new ones, but you can rename them, change their colours, reorder them and hide any you do not use, except Open.
Each post shows its status history publicly, and a status change can carry a public comment explaining it. Followers are told when the status changes, so a request closed with a one-line reason builds more trust than one left sitting in Open.
Search and SEO for each board
Public board and post pages are rendered on the server with their own titles and descriptions, and appear in your workspace's sitemap. Each board can override its search title, description, social image and canonical address, add keywords, or be kept out of search results with noindex.
Board setups that work
Feature requests: public, with tags by product area. This is the board most customers will see, so keep its description short and clear about what belongs there.
Bug reports: a separate board, so a bug never competes with a feature for votes. Use the description to ask reporters for the steps they took and what they expected to happen.
Beta feedback: a private board limited to the people in the programme, which keeps work under NDA out of public view while keeping voting and statuses.
Internal requests: a private board for employees, with tags such as hardware, access and software so each request type reaches its owner.
Ready-made board templates are coming soon. To reuse a setup today, duplicate an existing board from Admin, then Boards; you can choose whether its posts come with it.
Archiving, duplicating and deleting
Boards can be reordered by dragging, archived and restored, duplicated, or deleted. Archive a board you have finished with rather than deleting it, so its posts stay on record. If a downgrade leaves you with more boards than your plan includes, the extra boards become read-only rather than being deleted.
Writing statuses customers understand
Customers read statuses as promises, so the labels should say what the customer can expect rather than describe your internal workflow. Under review says you have seen it; Planned says you intend to build it; Complete says it is live. If your customers would rather read Shipped than Complete, rename it; the status keeps working the same way.
Write a one-line description of each status and publish it wherever customers will see it, such as your help centre, so nobody has to guess what Planned commits you to. Review the set after a month: a status nothing ever moves into is a candidate to hide.