Pick any number on your support dashboard that depends on an agent tagging a ticket. There's a good chance it's being undercounted, and almost no chance you can see by how much.

The Signal Engine looked at one such case for a customer. The flag for one common issue type had been checked on only about 1 in 6 of the tickets that actually had it. Five out of six were missing the tag. So a number leadership read as 2% of all tickets was really closer to 12%. Six times higher than the dashboard said, and nobody in the building could see it.

This isn't really about one team. It's about how almost every support metric gets made.

Why every team runs on tags

Tags are how a support team turns a flood of individual conversations into something countable. Categories, dispositions, priority flags, known-issue lists. An agent picks them as they close each ticket, and those picks roll up into the dashboards leadership uses to decide what's worth fixing, where to add people, and which bug the product team hears about first.

It's a reasonable system, and it's everywhere for a reason. Every help desk ships with it. It needs no extra tooling, and it gives you a number today instead of a research project next quarter. So the tags quietly become the system of record. Reports get built on them, goals get set against them, roadmaps get argued over them.

The whole thing rests on one quiet assumption: that the tags are roughly right. And most of the time nobody checks, because checking would mean reading the tickets one by one, which is exactly the work the tags were supposed to save everyone from.

Why tags drift

It's structural, not a discipline problem. A tag depends on a busy person, mid-conversation, picking the right category on every ticket, all day. Under real volume, people pick the fastest option, the closest one, or none. A customer mentions one problem in passing while writing in about another, the ticket gets filed under the second one, and the first is never counted.

Picture the agent's actual moment. A customer writes in angry about being double-charged, and somewhere in the third paragraph mentions the app froze on them twice that week. The agent fixes the charge, tags the ticket "billing," and moves to the next person in the queue. That's the right call for the customer in front of them. It also means the frozen app, the thing the product team would want to know about, just disappeared from the data. Not because anyone was careless, but because the tag has room for one story, and billing was the one that needed solving right then.

Do that across thousands of tickets and the number that reaches leadership stops meaning "how often this happens." It starts meaning "how often someone remembered to log it." Those are very different numbers, and the gap between them is invisible, because a dashboard can't show you what it never captured. You don't get a warning that the 2% is wrong. You just get the 2%.

The list you keep by hand has the same hole

It isn't only checkboxes. That same company kept a list of known bugs, the confirmed issues everyone agreed were the real problems. The Signal Engine read the actual complaints customers wrote and matched them against that list. Only about 1 in 10 lined up. The other 90% were about things nobody had written down. Grouped into themes, the top 20 of those unlisted problems accounted for half of all the friction customers reported. The biggest sources of pain were the ones the team hadn't thought to track yet. A hand-kept list can only ever hold what you already knew to look for.

Put the two findings side by side and the pattern is hard to miss:

What the wrong number costs

A miscounted number doesn't just sit on a dashboard. It makes decisions. In that company's case, the issue that looked like 2% of volume was quietly one of the most common things customers actually hit, and it was losing every prioritization argument to problems that looked bigger on the chart. A number that low doesn't get the engineer, doesn't make the roadmap, doesn't earn a line in the board deck.

The deeper trouble is that nobody was arguing about it. The chart looked clean, and everyone in the room was reading the same clean chart. The most expensive problems aren't always the loudest ones. Sometimes they're the ones that got quietly miscounted and then confidently acted on, for quarters at a time, before anyone thought to go back and read what customers had actually written.

The fix isn't better tagging

The instinct, once you see this, is to tighten the tagging policy. Make the categories mandatory, audit the agents, send the reminder. It doesn't work, and you probably already know it doesn't, because you've tried it. Tagging discipline decays in about a week. The moment volume spikes, the tags go back to being whatever's fastest.

The fix is to stop measuring from the tags and measure from what the customer actually wrote. The information was always there. Every real case of that issue was sitting in plain text in the ticket, described by the customer, whether or not anyone checked a box. The Signal Engine reads the words and counts what's really in them, so the number you act on is the real one. No tagging program to build, train, police, and then quietly distrust.

What it frees you to ask

The part that surprises people isn't the corrected number. It's everything you can ask once you're not limited to the tags. Which feature drives the most complaints. Which policy. Which step the customer was on when it broke. None of those are fields in your help desk. You can't tag your way to them, no matter how disciplined the team is. They're all in the words, the same place the real issue rate was.

Ask which screen people are on when they give up, or which policy generates your angriest tickets, and the answer comes back as a ranked list instead of a shrug and a "we'd have to read through them all." The questions you quietly stopped asking, because there was no way to answer them, are back on the table.

Your dashboard has been telling you what got logged. Your customers have been telling you what actually happened. Those should be the same story. Usually they aren't, and the difference is where the work is.

See your real numbers

This is exactly what the Signal Engine is built to do. Point it at your support data and it reads every ticket, chat, and review, counts what customers are actually reporting, and hands you the real rate instead of the tagged one. The true frequency of each issue. The problems missing from your known-bug list. The feature, the policy, the step that drives the most pain, none of which your help desk can group by today. No tagging program to build, no cleanup to do first.

Most teams we run this for find at least one number they'd been reporting to leadership that was off by multiples. It's better to find that yourself than to find it in the next planning cycle.

Want to see what's hiding in your own tickets? [Book a 20-minute walkthrough] and the Signal Engine will read a slice of your real support data, then show you where your dashboard and your customers disagree.