A single place for every feature request
Customers post ideas and bugs, vote on the ones they care about, and get told when their request moves. You get a ranked list instead of a shared inbox.
The problem
The spreadsheet always loses
Feature requests arrive through support tickets, sales calls, and Slack messages. Someone summarises them into a document, the document goes stale, and the customer who asked never hears back — so they ask again, through a different channel, and the count starts over.
A board fixes the accounting problem. Every request has one canonical home, one vote count, and one status that the person who asked can check without emailing anyone.
What you get
Everything in feedback boards
Voting that names names
Every vote is attached to the person who cast it. Eight votes from your three largest accounts is not the same as forty from trials, and the requester list is what lets you tell the difference before committing a quarter.
Custom statuses
Posts move through open, under review, planned, in progress, completed, and closed. Changing a status notifies every voter, which makes it the highest-leverage field on the page — including `closed`, which is the decline nobody enjoys sending and everybody wants to receive.
Duplicate merging
You will get duplicates. Merge rather than delete: votes combine, both requester lists transfer, and everyone who asked is notified when the survivor ships.
Threaded comments
The detail you need is usually in the follow-up question. Discuss on the post, in public, so the next person asking the same thing reads the answer instead of filing it again.
Tags and filtering
Cut across boards by `mobile`, `billing`, or `enterprise`. Filter by votes, status, tag, or date to answer 'what do paying customers want that we have not planned?'.
Public or private
Run the board in the open to build trust, or keep it internal while your team files on customers' behalf. The same board can be flipped either way.
Step by step
How to set up a customer feedback board
Create a workspace, open a board, set statuses, publish the portal, and share the link with customers.
- 1
Create a workspace
Sign in with your email — a one-time code, no password — and name the workspace after your product.
- 2
Open a board
Create one board with a plain name such as 'Feature requests'. One board is enough to start; several will just spread the votes thin.
- 3
Set your statuses
Keep the defaults or rename them to match what your team says. The status is what customers come back to check.
- 4
Publish the portal
Make the portal public in Settings. The board is now live at signlos.com/p/your-workspace.
- 5
Seed and share
Post the three requests you already know about, then put the link in your support reply template and your product's help menu.
Questions
Frequently asked
Keep reading
Works with
Roadmaps
Group work into Planned, In progress, and Shipped. Each item stays linked to the feedback posts that asked for it, so the people who requested it hear about it without you keeping a list.
Learn more →Release notes
A changelog with an editor, categories, and a public feed. Publishing notifies everyone who voted for the linked posts — the loop from request to announcement closes itself.
Learn more →Widgets
Drop-in embeds for the board, roadmap, and changelog. Feedback arrives with the context of the screen the user was on when they wrote it.
Learn more →Full documentation lives at docs.signlos.com.
Your customers already told you what to build
It is in a support inbox, three Slack threads, and a spreadsheet nobody has opened since March. Put it somewhere it can be counted.
No credit card required to start. $0 forever.