Support tickets vs. feature requests: which do you trust?
5 min read
A feature request board captures what users ask for when they have time to sit down and describe what they want. A support ticket captures what users are stuck on right now, often while annoyed, often without the vocabulary to describe the underlying request cleanly. Both are real signal, and teams that only look at one of them end up solving the wrong problem with confidence, because each channel systematically over-represents a different kind of user and a different kind of need. Prioritizing feature requests covers ranking what’s already on the board; this is about the gap between what makes it onto the board at all and what only ever shows up as a support ticket.
Why would the same underlying problem show up in one channel and not the other?
Because the two channels have different activation costs, and the size of that cost determines who clears it. Filing a feature request takes initiative: a user has to believe the request is worth articulating, find the board, and write something coherent, which selects for engaged, patient users who are already invested in the product. Filing a support ticket takes almost no initiative in comparison, often just clicking “help” mid-task, which means it captures frustrated users in the moment, including ones who would never have bothered with a feature request board at all. A real gap in the product can be invisible on the feature board and loud in support simply because the users hitting it are the ones least likely to file a formal request.
Does ticket volume for a missing feature mean the same thing as vote count for it?
No, because they’re measuring different populations under different conditions. A feature request with a hundred votes represents a hundred people who took the time to find and support an existing ask, which is a strong signal of durable, considered demand. A hundred support tickets about the same underlying gap, filed over the same period, likely represents users hitting a wall in the moment, some of whom would forget about it entirely once the immediate friction passed. Treating the two as equivalent “hundred people want this” signals overweights the ticket volume, because tickets are cheap to generate and votes aren’t.
| Feature request board | Support tickets |
|---|---|
| Requires initiative to file | Requires almost none |
| Captures considered, durable demand | Captures in-the-moment frustration |
| Skews toward engaged, patient users | Captures users who’d never use the board |
| A vote count is a real commitment signal | A ticket count reflects friction, not always desire |
What does it mean when a feature has support tickets but almost no votes on the board?
Often that the request exists but the users hitting it don’t know the board exists, don’t believe voting will do anything, or hit the problem too rarely to bother crossing to a different channel to register it formally. This is exactly the population a request board structurally misses, and a low vote count here is evidence of a measurement gap, not of low demand. Treat a support-ticket cluster around a missing feature as its own signal worth logging on the board yourself, on the users’ behalf, rather than distrusting the tickets, so it isn’t invisible to whoever prioritizes from vote counts alone.
Board reads as low priority:
"Export to CSV": 4 votes over 6 months
Support tells a different story:
"Export to CSV": 31 tickets over the same 6 months,
each from a different account, each closed with
"not currently supported, will pass along feedback"Does a spike in support tickets always mean the underlying issue is a missing feature?
No, and this is where the two channels can mislead in the opposite direction. A ticket spike is just as often caused by a confusing UI around a feature that already exists, a bug, or a change that shipped without adequate explanation, none of which are solved by building something new. Reading every ticket spike as “users want a feature we don’t have” produces a roadmap stuffed with things that were actually documentation gaps or usability problems in disguise. The support ticket tells you where the friction is; it doesn’t tell you on its own whether the fix is a new feature, a UI change, or a better help article, and conflating those wastes engineering time on the wrong solution.
How should the two signals actually be combined when deciding what to build?
Use tickets to find where the friction is, and use the request board, plus direct outreach where the board is thin, to confirm what the actual desired outcome looks like. A ticket cluster identifies a real, felt problem; it rarely specifies the solution precisely enough to build against, because a frustrated user in a support conversation describes symptoms, not specifications. The request board, when it has enough votes on the same underlying issue, tends to carry more of the “what would actually satisfy this” detail, because writing a request is already an act of specifying what you want, not just reporting what’s wrong.
Should support agents be logging tickets as feature requests themselves?
Yes, and this is the single highest-leverage fix for the gap between the two channels. An agent who recognizes a ticket as a disguised feature request, rather than just resolving it and moving on, can log it to the board on the customer’s behalf, which closes the measurement gap directly instead of requiring the customer to discover and use a second channel. This only works if logging takes the agent seconds, not minutes, so the friction of doing it has to be lower than the friction of just closing the ticket and moving to the next one.
FAQ
Should feature request votes ever be discounted if they all come from one account or team? Yes, weight by distinct accounts or organizations rather than raw vote count, because five votes from five people at the same company represent one customer’s priorities, not five independent confirmations of demand.
Is it worth building a feature that shows up heavily in tickets but has almost no votes? Often yes, provided the ticket volume is genuinely from distinct accounts and the underlying need is confirmed rather than assumed; treat the low vote count as a measurement artifact of the board’s activation cost, not as evidence the demand isn’t real.
How do you tell a UI confusion ticket apart from a genuine missing-feature ticket at a glance? Look at whether the resolution involves explaining an existing capability or apologizing for a missing one. A pattern of “oh, it’s actually right there” resolutions points at a UI or discoverability problem; a pattern of “we don’t support that yet” points at a real gap.
Does this distinction matter as much for a very small support volume? Less mechanically, since a handful of tickets is easy to read individually rather than needing aggregate analysis, but the underlying bias, tickets over-representing frustrated users and under-representing patient ones, is present at any scale and worth keeping in mind even when you’re reading every ticket yourself.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.