Feature requests are a ticket type like any other, with two differences: customers can upvote them, and you can show them publicly. That combination is what makes a roadmap rather than a backlog.
They live under Feedback portal, in Roadmap.
Three routes, and most teams use all of them: a customer submits one from the portal, someone posts one from the widget, or an agent creates one out of a conversation. The last one matters most, because the best requests arrive as complaints rather than as feature ideas.
Creating a request from a conversation also links the two, so when the thing ships you know who to tell.
Customers upvote requests they care about, and the count travels with the request. Treat it as a signal about strength of feeling rather than as a decision: the people who vote are the people who found the portal, which is not the same as your customer base.
Everyone who voted can be notified when the status changes, which turns a roadmap from a wall of text into something that closes the loop.
A request moves through lanes: on a new project, Ideas, Requested, Planned, In progress and Released, with Closed for the ones you won't do. You rename, reorder and add lanes under Set up ticket types and custom fields, and each lane is either public or hidden.
Hidden lanes never appear on the portal. Ideas and Closed are hidden by default, so a request becomes visible when it's accepted and disappears when it's closed. Keep your intake lane hidden: it lets you, or Kai, decide before customers see it.
The roadmap starts with All, and you can add views next to it: saved filters over your requests, in the order you arrange them. Views are how "what's planned" and "what we've shipped" become separate things to look at rather than one long list.
The Feedback portal overview is where requests get decided. Kai PM scores every request from demand, revenue, fit with your goals and effort, with the factors visible on each one, so "why did we build that one?" has an answer everybody can see.
You can review the queue yourself, accepting and declining with a message to the voters, or let Kai make the first pass and only look at what it flags. Either way, accepted requests land on the public roadmap and declined ones get a reply. The collection Let Kai run your roadmap covers setup, scoring and the automations.
Any open roadmap collects the same idea five times in different words, and the votes scatter across all five. Kai catches clear duplicates as they arrive and merges them, votes included. For the rest, ask Kai PM in chat to find duplicates: it groups likely matches with the evidence and merges the groups you confirm.
Review each group before confirming. Two requests that sound alike sometimes aren't, and a merge is a lot easier to make than to undo.
Changelogs are the other half of the portal: the posts that say what you released. Customers can subscribe to them and comment, which is the difference between a roadmap that people trust and one they stop reading. Moving a request to Released offers to tell everyone who voted; take it.
