Features / Product feedback
Feature requests
One board instead of forty conversations
Customers post what they want, other customers vote, and duplicates collapse into one. A support conversation can graduate into a request without retyping it.
- 34Bulk export to CSVAnalytics
- 21Slack notifications per productIntegrations
- 12Dark mode for the portalPortal
- 9Weekly digest of unresolved bugsEmail
- 7Filter the roadmap by productRoadmap
- 5Keyboard shortcuts in the inboxInbox
What it does
- Public or private boards, per product
- Voting, with duplicate votes prevented properly
- Turn a support conversation straight into a request
- Moderation and rate limits, because it is a public write surface
Without it
Requests arrive in five places and are counted in none of them
The same request, nine times, nine wordings
Someone asked for Slack alerts in a chat on Monday, in an email in March, and in a bug report that turned out not to be a bug. Nobody counted, so nobody knows whether nine people want it or ninety.
The roadmap is whoever emailed most recently
The customer who pushed hardest on Tuesday moves up the list. The quiet one who has asked three separate times through the widget does not, because those three asks are sitting in three closed conversations nobody will read again.
“I'll pass that on to the team”
You both know what that sentence means. It costs you the trust you just earned by answering in four minutes, and the customer stops telling you what they need.
How it works
A request can start anywhere
Customers post on the board, or you graduate something you already have: a support conversation, a ticket, a bug capture, or an investigation. It carries the original title and text across, so nobody retypes anything.
What that includes
- Customers post on the board
- a ticket
- a bug capture
- an investigation
Votes are counted per person, not per click
Every vote is tied to one identity: a verified contact, a known visitor, or an anonymous fingerprint. The database itself rejects a second vote from the same identity on the same request, and a repeat attempt is logged rather than counted.
Duplicates merge, and the count survives the merge
Merge two requests and the merged one keeps pointing at the survivor. Votes and comments are totaled across the whole family, so collapsing five near-identical asks never quietly loses four of them.
It is a public write surface, so it is treated as one
New posts and comments arrive pending moderation rather than going straight live. Block lists, banned content and per-identity rate limits are enforced at the door and recorded as abuse events you can go and look at.
What that includes
- Block lists
- banned content
- look at
Every request belongs to a product
There is no unsorted pile. Each board is scoped to a product and can be public or private, so an agency running six client products never shows one client's requests to another.
What it means for you
You can finally answer “how many people want this”.
Not a feeling from the last support shift. A count, with the voter list behind it, so you can see whether the loud request is also the common one.
The person who asked gets something back
Their request becomes a thing with a name and a status they can look at, instead of a sentence you promised to pass along.
Nothing falls in the gap between inbox and roadmap
A conversation that turns out to be a feature request stops being a closed conversation and becomes a counted one, with the customer's own words still attached.
The honest limit: Merging duplicates is a human decision. Tore does not automatically fold a new request into an existing one, so a board that nobody moderates will accumulate near-duplicates.
Also in Product feedback