Template
Feature request board template
A feature request board template: the statuses, tags and setup steps for a public voting board in Looph, and the reasoning behind each one.
Product teams that need a single public place to collect and prioritize customer-driven feature ideas.
- Statuses
- 6
- Tags
- 5
- Things to ask for
- 4
- Setup steps
- 6
Use this template
Copy the setup, import the starter posts
Two ways to start from this template today: copy the checklist below into your setup notes, and import the starter CSV into a new board from the Posts page of your team area. The file holds this page's example posts, with each status mapped to Looph's built-in name so the importer accepts it; delete them before you share the board.
Columns: title, details, status. 3 example posts.
Setup checklist
Feature request board template (looph.ing/templates/feature-request-board) Statuses (the Statuses page in the team area): - Keep "Open" - Keep "Under review" - Keep "Planned" - Keep "In progress" - Rename "Complete" to "Shipped" - Rename "Rejected" to "Not planned" Hide Closed, and Pending approval unless you require approval. Statuses are shared by every board in a workspace, so a rename or a hidden status shows on all of them. Tags: - Integrations - UI/UX - API - Mobile - Reporting Board description: Tell us the problem you're trying to solve, what you do today instead, and who it affects. Ask for in the details: - A clear title - The problem - Today's workaround - Who it is for Setup steps: 1. Create a board called Feature requests and set visibility to Public, so anyone with the link can read it. Leave posting, voting and commenting open to anyone who can view, and paste the prompt above into the board description. 2. In your workspace's status settings, rename Complete to Shipped and Rejected to Not planned, and hide Closed. Then create the five tags. 3. Voting needs a sign-in, one vote per person per post, so every vote has a person behind it. When you plan, sort the inbox by Top or Trending and filter it by tag. 4. Invite support, sales and customer success as members. Members are free on every plan, so the people who hear requests can post them and vote. 5. Merge the repeats that the similar-posts list does not catch. Votes move across without double counting, and comments and followers come with them. 6. When a request ships, publish a changelog entry linked to it, and choose to mark it Shipped and tell the people who voted and followed.
Templates aren't applied automatically yet: you set the board up yourself by following the steps on this page. One-click templates are coming soon.
Fit
When to use this template
A good fit when
Requests reach you through support tickets, sales calls and chat, and nobody can say which one has the most demand behind it. A public board gives every request one URL, lets customers add a vote instead of asking again, and lets you sort by demand when you plan.
For most SaaS products this is the right first board. If you are on the Free plan and get one board, make it this one.
Pick something else when
Keep bug reports off it. A crash and a feature idea need different details and different urgency, and mixing them buries bugs under vote counts. Run the bug tracker setup as a second board.
If customers cannot discuss your product in the open, for example during an NDA beta or with enterprise accounts that will not post publicly, follow the beta feedback or customer portal setup instead, which use private boards.
What's inside
Statuses, tags and what to ask for, and why each one is there
Looph has a fixed set of statuses that you can rename, recolour, reorder and hide, but not add to; each status below says which built-in one to use. Posts are a title plus details, so the last list is what to ask for in the details.
Statuses
- OpenBuilt-in status
- Where every new post starts. It tells the submitter the request is in the queue and nothing more. Open is the one status that cannot be hidden.
- Under reviewBuilt-in status
- A person has read it and is weighing it. A post leaves this status when someone either commits to it or declines it.
- PlannedBuilt-in status
- You have decided to build it but are not promising a date. Posts in Planned appear in the Planned column of your public roadmap. Only move a request here once it has an owner or a slot in upcoming work.
- In progressBuilt-in status
- Someone is building it now. Your team moves the post here by hand, or, from Starter up, a linked Jira or GitHub issue moves it when work starts.
- ShippedRename Complete
- The request is live. Publishing a changelog entry linked to the post can mark it Shipped and tell everyone who voted on or followed it.
- Not plannedRename Rejected
- The honest answer for requests you will not build. Add a public comment explaining why when you change the status. A stated reason earns more trust than a request left to rot.
Hide Closed, and Pending approval unless you require approval. Statuses are shared by every board in a workspace, so a rename or a hidden status shows on all of them.
What to ask for in the details
- A clear title
- Similar posts surface underneath as someone types a title. A clear title means more people vote on the existing post instead of filing a second one.
- The problem
- Ask for the problem rather than the proposed solution. The job a customer is trying to get done tells you more than the button they imagine.
- Today's workaround
- What they do instead now. A painful workaround tells you how urgent the request really is.
- Who it is for
- A post a teammate writes on the board is credited to the teammate, so ask support and sales to name the customer in the details, or to file it with the Chrome extension, which can credit it to the customer.
Custom fields and file attachments are coming soon. Until then, a post is a title plus up to 5,000 characters of details.
Suggested board description
Put a line like this in the board description, so people know what to include: “Tell us the problem you're trying to solve, what you do today instead, and who it affects.”
Tags
- Integrations
- UI/UX
- API
- Mobile
- Reporting
Tags are created once for the whole workspace, and your team applies them to posts. Customers can filter the board by tag. These five follow common product areas; rename them to the areas your team actually plans around, so a filtered view answers a real planning question.
Setup
Set it up in Looph
Each step in order, with the guide that covers it.
- 01
Create a board called Feature requests and set visibility to Public, so anyone with the link can read it. Leave posting, voting and commenting open to anyone who can view, and paste the prompt above into the board description.
- 02
In your workspace's status settings, rename Complete to Shipped and Rejected to Not planned, and hide Closed. Then create the five tags.
- 03
Voting needs a sign-in, one vote per person per post, so every vote has a person behind it. When you plan, sort the inbox by Top or Trending and filter it by tag.
- 04
Invite support, sales and customer success as members. Members are free on every plan, so the people who hear requests can post them and vote.
- 05
Merge the repeats that the similar-posts list does not catch. Votes move across without double counting, and comments and followers come with them.
- 06
When a request ships, publish a changelog entry linked to it, and choose to mark it Shipped and tell the people who voted and followed.
Illustrative examples
Example posts
Made-up posts that show what a useful entry on this board looks like. They are not from real customers.
Example · Reporting
Export a filtered report as CSV
Our finance lead copies numbers from the monthly report into a spreadsheet by hand. Exporting the filtered view as CSV would remove that step entirely.
Planned
Example · Integrations
Sync deal stages from our CRM
Sales updates deal stages in the CRM and someone re-types them here. Even a one-way sync into the app would cover most of what we need.
Under review
Example · Mobile
Dark mode in the mobile app
Comment from the team: not this year. The mobile app is moving to a new framework first, and we will revisit theming once that lands.
Not planned
Plan
Which plan it needs
Works on Free. The Free plan covers this template on its own: one public board, the public roadmap and the changelog are all included, with up to 100 tracked voters. Starter becomes necessary when you add a second board, such as a separate bug tracker, or need more voters; serving the board on your own domain needs Growth. Compare plans.
How the pieces work: Feedback boards. Teams running this workflow: Feature request tracking software and Customer feedback management for SaaS product teams.
More templates
Other starting points
Public bug tracker board template
Teams that want bug reports separated from feature requests, with triage by impact that reporters can follow.Beta feedback board template
Teams running a private or invite-only beta that need structured, votable feedback before a general release.Internal IT request board template
Internal IT and operations teams that need a searchable, votable alternative to a ticketing spreadsheet.Design feedback board template
Design and product teams collecting structured critique on in-progress work from stakeholders or users.
Related
The features and reading behind this template
Start collecting feedback in five minutes
Free forever on one board, with unlimited members and a 14-day Business trial. No credit card, no sales call.
Unlimited members · Published prices · Cancel anytime