Every support operation I have worked in measures the same thing first: how fast the queue goes down. It is an honest metric. People are waiting, and someone has to answer them. But after thirteen years of it, I am fairly sure it is also the metric that hides the actual work.
A queue is a symptom. Every item in it exists because something upstream produced it — a policy line that can be read two ways, a help centre article that answers a question nobody is asking, a product flow that quietly invites the wrong behaviour, a bug that has been reported forty times in forty different phrasings and never once in a form the product team could act on. Clearing the ticket resolves it for one person. Fixing what produced it removes it for everyone who would have written in next month.
Only one of those two jobs is visible
Clearing tickets is legible. There is a number, it moves, and everyone can see it move. The other work has no counter. Nobody logs the tickets that never arrived. So the incentive, in every operation I have seen, points quietly in the wrong direction: the person who empties the queue fastest looks like the strongest operator, and the person who spent Tuesday rewriting an ambiguous policy line looks like they had a slow day.
I wrote and maintained the FAQs and help centre material for my markets for years. None of it ever appeared on an operations dashboard. All of it appeared as volume that stopped coming.
Two habits that changed my results
The first: read the queue as data, not just as work. Once a week, stop answering and start counting. What are the five things people are actually writing about? Not the categories in the tool — the real ones, in their words. That list is almost never what the tagging system says it is, and it is the only reliable map of where the problem lives.
The second: translate before escalating. Product cannot act on "users are confused." They can act on: this happens on this screen, in this market, roughly this many times a week, here are the exact steps to reproduce it. The work of turning frustration into something actionable is unglamorous and it is most of the job. Cross-functional coordination is not meetings. It is doing the translation so the other team can say yes.
The uncomfortable part
None of this happens unless someone protects the time for it, and the queue is very good at arguing that there is no time. Drucker put it about as bluntly as it can be put: do first things first, and second things not at all. Not later, not in parallel — not at all. Sixty years on, in a job where everything arrives urgent, that is still the hardest instruction to follow.
The queue will still be there tomorrow. That is rather the point.
First in a series of short notes on how operations work actually gets done.