What a voting board tells you that AI on your support tickets can’t

Your support inbox has never been easier to read.

Feed a month of tickets to an AI model and it hands back a tidy list in minutes: the top 10 themes, ranked by frequency, with sentiment scores and a clean summary of every recurring issue. In a way it’s impressive, and many teams are already doing some version of it. AI now handles about 30% of customer service cases, a share Salesforce expects to reach half by 2027.

So here’s a fair question. If a model can already tell you where your users are struggling, why does deciding what to build next still feel like guesswork?

A tidy summary of your tickets is a genuinely useful signal. It’s just not the signal you need to plan a roadmap. Mistaking one for the other can mean you end up building the wrong things for your users.

Your tickets describe the product you have. A feature voting board describes the product you haven’t built yet.

Two different signals: friction and demand

A support ticket is a record of friction. Not necessarily complaints; they can often be questions, like “Can it do this?” “How does that work?” “Why doesn’t it function like this?”

Each of those is a small signal about where your product isn’t quite in line with user expectations. It could be confusing, incomplete, or harder to use than it should be. Or it could just be different to a competitor they’ve used, or different to what they imagined.

This is all valuable information, and understanding it should shape your product’s development direction. AI is good at organizing these insights.

But a question about how your product works isn’t the same as a statement about what it should do next. And the absence of a question doesn’t mean there’s no demand for something you haven’t built.

Think about what your support queue can and can’t tell you.

Users might submit a ticket to ask about features that don’t exist yet. They ask because they assume: like if your app integrates with Xero, someone writes in asking how to connect Sage. That’s a demand signal, but not a very useful one. You learn that one person asked about Sage. You don’t learn that lots of people want it, which of them would switch to a competitor without it, or why they need it.

The people happily using your product every day, the ones who’d love one specific thing if you built it, often say nothing at all. Their wants are real, and they’re invisible to any system that only reads tickets.

A feature voting board is built to catch that other signal. Instead of waiting for friction, it gives people a place to say what they want. And it gives everyone else a way to upvote feature requests they care about. What comes back is different: a ranked expression of demand, in your users’ own words, from people who were never going to open a ticket to tell you.

What ticket AI does well

None of this is an argument against running AI on your tickets. If you give it the right task, it’ll do great things for you.

At volume, it’s excellent at triage and routing. AI can sort incoming tickets by intent and urgency far faster than a human queue can. It’s a strong summarizer, too: tools that generate a case summary for the next agent will cut time to resolution. A team dealing with thousands of conversations a week will struggle to do this manually.

Intercom reports that its Fin agent resolves roughly two-thirds of the conversations it handles across tens of millions of cases. So for routine, answerable questions, that advantage is real and worth having.

There are two things to keep in mind, though. Firstly, many of these will be deflected rather than resolved: a bot that closes 90% of tickets may actually solve far fewer, with a bunch of them coming back under a different subject line.

Secondly, all of this is about handling friction efficiently. It tells you nothing about what to build. Speed at closing tickets and knowing what to build next are different things.

Four things a voting board tells you that ticket AI can’t

There are things a feature voting tool surfaces that no amount of AI on your tickets can produce, because the information was never in the tickets to begin with.

Demand, not just friction. A ticket summary tells you how often something comes up. A voting board tells you how many people actively want a thing built. Both are useful; only one of them points forward.

The silent majority. The users who write in are a small and unrepresentative slice. According to one report, only 29% of customers say they raise issues directly with a company after a bad experience. Most people say nothing. A voting board lowers the bar to a single click, so you finally hear from people who’d never have filed a ticket.

Priorities set by users, not inferred by a model. When AI ranks your ticket themes, it’s estimating importance from how often something is mentioned. When users vote, they tell you directly. One is a guess drawn from a biased sample; the other is an explicit, forward-looking statement of what matters to the people who chose to weigh in.

The “why” behind the request. 50 tickets mentioning “bulk export” will get AI-summarized as “users want bulk export.” What the summary can’t tell you is why. Do they really want to share data with a colleague, meet a compliance rule, or escape a screen that’s too slow? Each of these points to a different and possibly better solution.

That last one deserves a moment. Tickets are worth reading closely, and the value is rarely on the surface. You have to read between the lines and ask why someone is really asking this, and what problem led them to write in at all. It takes empathy and a deep understanding of your customers. A frequency-ranked list of themes strips out exactly the context that makes that work possible. On a voting board the request arrives with comments, discussion, and reasoning attached, from the person who wanted it.

None of these are failures of the AI. The model is doing exactly what you asked. It can’t summarize data that was never collected, and demand for things that don’t exist yet isn’t sitting in your ticket queue waiting to be found.

Why “just summarize the tickets” can mislead you

There’s a subtler risk than missing signals. It’s being actively misled by the signals you do get.

People who file tickets are, by definition, the ones who hit something worth writing in about. That makes any pile of tickets a biased sample: it speaks for the users who make contact, and says nothing for the rest.

Run an AI summary over it and you get a confident, well-formatted picture of what your most vocal users are dealing with, presented as if it were the view of your whole user base. Those few end up driving most of the decisions, and you can spend your roadmap smoothing out yesterday’s friction for the people who speak up. Meanwhile, the needs of your wider customer base go unbuilt because nobody logged a ticket about them.

Developers in particular have seen how confidently wrong an AI support layer can be. In April 2025 the AI support bot for the coding tool Cursor invented a subscription policy out of thin air, told users it was real, and set off a wave of cancellations before the company clarified that no such policy existed.

A model that can fabricate an answer for a user can just as easily give you a clean, plausible, wrong summary of what those users need. Garbage in, confident garbage out.

The industry walk-back from “automate everything”

Across the industry, the teams that pushed automation hardest are amongst the ones now walking it back.

Klarna is the case study everyone cites. In early 2024 it announced that its AI assistant was doing the work of 700 agents. By 2025 its CEO had publicly conceded that leaning too hard on cost-saving AI had produced lower-quality service, and the company was recruiting human agents again. Australia’s largest bank, CBA, cut 45 support roles on the strength of an AI voice bot, then reversed the decision within weeks after call volumes went up rather than down, and apologized.

There’s wider data that tells the same story. Sinch found that 74% of enterprises had already rolled back or shut down a live AI customer-communications agent. Gartner predicts that half of the organizations planning to cut service headcount because of AI will abandon those plans by 2027. And Qualtrics found that AI customer service fails at roughly four times the rate of other AI uses, with nearly one in five people getting no benefit from it at all.

Worth being careful about, isn’t it?

This isn’t an anti-AI story. It looks like businesses are getting more deliberate about where automation belongs. AI is a good tool for some jobs and a poor one for others.

Use both methods, deliberately

So use both. Just point each one at the job it’s actually good at.

AI on your tickets is a diagnostic tool. Aim it at your support queue to find out what’s confusing, what’s missing, and where your existing experience is failing people. Being able to do this more efficiently than before is a big advantage.

A feature voting board is a planning tool. Aim it at the question the tickets can’t answer: out of everything we could build next, what do our users actually want, and how many of them want it? A public feature request board also shows what’s already been suggested, so people add a vote instead of adding a duplicate. Use it to prioritize features by real demand, not by who wrote in most.

The voting board has its own blind spots, though. A vote is a request for you to consider, not an order to obey.

The people who vote can tend to be your most engaged and most opinionated users. Popularity isn’t the same as importance, and a loud, motivated group can push a niche request up the list. This is why the human part still matters: read the comments, notice who’s asking, and treat a vote count as a strong hypothesis rather than a verdict.

A feature request board doesn’t make the decision for you. It makes sure the decision is informed by the people you’d otherwise never hear from.

What to do next

These ideas should help explain why we build Fider the way we do. Hopefully you can understand why, for the time being, we’re not putting AI inside it. We’d rather give you a clear, simple place for people to tell you what they want (and for you to show them what you’re doing about it) than an algorithm guessing what’s in their heads.

If you want to run AI over your tickets alongside that, go for it! The two jobs sit happily side by side.

So here’s the practical next step. Look at how you decided what to build recently. If the real answer is that it came from the support queue, then you’ve been reading a map of the product you already have. That’s fine; it’s just not the same as knowing what to build next. For that, you have to give people somewhere to tell you, and start listening.

‍