The Seven Ways Support Quietly Fails
Nothing is down. The monitoring is quiet, the dashboard is green, and the monthly report says ticket volume is down eleven percent. In the same building, finance keeps a spreadsheet of IT problems they ask each other about. The warehouse phones Marcus directly because he fixed the scanner once. Sales stopped raising tickets in the spring because nothing happened when they did. Three departments have left the desk. The desk has not noticed, because the desk measures the desk.
This article is about the failures that never page anyone. These are the seven ways a support desk goes wrong without an outage, an alert or a complaint. They are the hero, the black hole, the silent close, the shadow channel, the category swamp, the untracked walk-up and metric theater. Each gets the same treatment: what it looks like, why it happens, the early-warning sign and the fix. A self-diagnosis table and a fixing order follow. It is part of our Helpdesk Fundamentals series, which covers what good support looks like and why support is a system rather than a person.
You will recognize at least two of the seven. Most desks run three or four at once, and they feed each other, which is why the fixes come in an order. I have never run a desk that had none. I have run one that had five, and by every number on its dashboard it was doing well.
Failures That Never Page Anyone
An outage is the easy kind of failure: loud, with a start time and an end, noticed by forty people inside a minute and forgiven by Thursday. A quiet failure is a desk that is open, staffed, and becoming irrelevant. Nothing breaks. Tickets still arrive, fewer each month. The people who stopped using the desk did not complain, because complaining takes effort and they had already found another way. From inside, a quiet failure looks like a good quarter.
Quiet failures share three properties. They look like success from inside. They are discovered from outside, usually by accident, usually by someone senior asking why a department has its own IT person. And they cost more the later they are found, because what is being lost is trust, and trust comes back more slowly than it leaves. The dashboard, throughout, stays green. Green is its resting state.
The Hero
The hero is the one person who holds the desk together. Every hard ticket ends up with them. They know the password to the thing, the history of the other thing, and which person in finance can approve a purchase before Thursday. When they are on leave the desk is still open, the way a shop with the lights on and nobody behind the counter is still open.
Heroes are made by rewarding them, not by hoarding. Somebody fixed a bad week once, got thanked, and was handed the next bad week. Nothing they knew was written down because they never had the time, and they never had the time because they were the hero. The organization praised the person every time it could have fixed the system.
The early-warning sign is the out-of-office test. Look at the week the senior technician was last away and count what waited for them. Count how many tickets in the last ninety days were reassigned to the same name, and how many answers in the team begin with "ask Dana". If the numbers are high, the desk is a person with a queue attached.
The fix is to copy the hero, not to replace them. Pick the ten ticket types that always go to them and write a runbook for each. That is a one-page set of steps a competent stranger could follow. Rotate the hard tickets so someone else does the next one with the hero watching. The test is in support is a system, not a person: can the desk run for two weeks from what is written down? Until it can, the hero's next vacation is a scheduled outage.
The Black Hole
The black hole is a desk that tickets go into and nothing comes out of. The requester gets an automatic acknowledgment with a number in it, then silence. A week later they ask a colleague, who asks the hero, who fixes it from memory. The ticket is still marked "New", and will be until somebody closes it in bulk at the end of the quarter.
Black holes form where there is no triage step. Triage is the sort: someone reads each new ticket and gives it a category, a priority and an owner. Without it, tickets are assigned to a group, and a group queue is where a ticket belongs to everyone, which is a way of belonging to nobody. Each technician assumes another has it. The assumption is correct, in that every technician is making it.
Here is one from the black hole at Bluewater Bank. Ticket 4471 was opened on a Tuesday at 09:12 by Priya in lending, about a report that would not export. It was acknowledged automatically at 09:12, and assigned to "Support Team". Priya replied "any update?" on the Friday and again the next Wednesday; both landed in the same unread ticket. It was found on day nineteen by a technician searching for something else and resolved in eleven minutes. The fix was short. The nineteen days were the failure.
The early-warning sign is the count of unowned tickets, the age of the oldest ticket still marked "New", and the number of replies that say only "any update?" Each of those replies is a person checking whether the desk is still there.
The fix is the cheapest in this article. Triage twice a day at fixed times and assign every ticket to a person by name. Reply to every new ticket within the hour with a time you will come back. Glance daily at the oldest unowned ticket. These are four of the ten habits in your first week running a helpdesk, and they close the black hole in a week without touching a setting.
The Silent Close
The silent close is a ticket resolved without telling anyone. The fix was made, the status changed, and the requester found out by noticing that the thing worked. Or they did not notice, because they had stopped trying, and three weeks later they raised the same ticket again. The desk counts a resolution. The requester counts a disappearance.
Silent closes happen because closing is the reward and replying is extra. The tool makes "resolve" one click and a reply three, and at the end of a long day the one click wins. Underneath is a belief that the status change is the message: the ticket says "Resolved", so the requester has been told. The requester does not read statuses. "Resolved" is a word the ticket system says to itself.
The early-warning sign is closed tickets whose last message was from the requester. Pull a month of closed tickets and look at who wrote the final entry. Add reopened tickets, and duplicates from the same requester within a month. A satisfaction comment reading "I did not know this was fixed" is the sign in its purest form.
The fix has two parts. Close with a note that says what was wrong, what was done and how to tell if it comes back. Ask the requester to confirm before you close. Then make sure the way back is open: a reply to a resolved ticket must land in that ticket, with its history, not in a new one. Where a reply on a resolved or closed ticket reopens it from any channel and the reopen is counted, as in QuerySolv, a wrong silent close becomes a number you can watch. It is then no longer a second ticket you never connect to the first.
The Shadow Channel
A shadow channel is any route to IT help that does not create a ticket. The routes include the direct message to a technician, the hallway, the technician's own mailbox, and the phone number only the warehouse has. The desk sees forty tickets a week. The organization asks for help ninety times a week. The other fifty are answered, often well, and never counted.
Shadow channels are built by good technicians being reachable. Nobody designs one. The desk once took three days, a person once helped in ten minutes, and the person became the channel. From then on the requester chooses between a queue that was slow once and a person who was fast once, and chooses as anyone would. Every shadow channel is a compliment to somebody and a verdict on the queue.
The early-warning sign is the quiet department. Compare ticket volume by department against headcount; a department raising a third of what its size predicts has another route. Look for the technician whose inbox is busier than the queue, and for tickets that arrive beginning "as discussed", which means the discussion happened somewhere the desk cannot see.
The fix is to make the desk as easy to reach as the person was, then route the person through the desk. The technician keeps answering the message, replies "opening a ticket so this does not get lost", does so, and sends the number back. The desk accepts requests by whatever door the requester already uses. The setup is one queue fed by web form, e-mail, live chat, social direct messages and an API. Every route creates the same kind of ticket, as QuerySolv does. That removes the argument about doors. Channel strategy is a later subject in this library. The ticket follows the conversation, wherever the conversation was.
The Category Swamp
The category swamp is a category list so long that none of it means anything. Four hundred categories, nested four deep, two called "Printing" and one called "Printers". A pick list the technician scrolls past and leaves on the first entry. A monthly report in which the largest category, at forty-one percent, is "Other". The list was meant to describe the work. It describes the history of everyone who ever edited the list.
Swamps form because categories are added and never removed. Every new kind of ticket got a category, every department got a branch, every reorganization added names and retired none. Nobody owned the list, so nobody could say no to a new entry. Categories breed. They are not even discreet about it.
The early-warning sign is "Other" being the largest category, two categories with the same name, or a technician who cannot say what the field is for. The sharper test is to ask what decision a category changes. If it changes who gets the ticket, how fast it must be answered or which report it appears in, it is doing work. If nobody can name a decision, it is clutter with a label.
The fix is ten to fifteen categories, each justified by a decision, and a prune every quarter. Build the list from the tickets, not the organization chart: pull a month of tickets, sort them by what the desk did about them, and name the piles. Map every old category to a new one so history survives, then stop the list growing without a reason. A report that says "Access, 38 percent" is a report somebody can act on.
The Untracked Walk-Up
The untracked walk-up is the work that never becomes a ticket. The technician is busy from nine to six, helps fourteen people, fixes a projector, resets three passwords and talks a manager through a spreadsheet. The queue, that evening, shows four tickets closed. The other ten jobs happened in the hallway, which is the busiest channel the desk has and the only one with no inbox.
Walk-ups go untracked because logging feels like paperwork and the person is standing right there. The fix took two minutes and the ticket would take three, so the ticket loses, every time, on reasonable grounds. The technician is being helpful and the organization is being helped. The only thing not happening is the record, and the record is the only part anyone will ask about later.
The early-warning sign is the gap between how busy the desk feels and what the queue shows. If the technicians are exhausted and the closed count is low, the work went somewhere. The sharper sign is a request for a second person that cannot be backed with numbers, because the numbers that would justify it were never written down.
The fix is to log every walk-up as a ticket, even a one-line one, even after the fact. Use a source of "walk-up" so the channel can be counted on its own. Say "I am opening a ticket so this does not get lost", which is true and which nobody objects to. Redirecting people away from the hallway comes later. For now the point is that the work is counted, because the number that proves the desk needs help is the number not being written down.
Metric Theater
Metric theater is a set of numbers that look good because they measure the wrong thing. Average resolution time is four hours, calculated on closed tickets, which excludes the thirty-one that are open and ninety days old. Volume is down eleven percent, because three departments left. Satisfaction is 4.8 out of 5, from the nine people who answered. Every number is accurate. None of them is true.
Theater happens when the metric is chosen because the tool offers it rather than because a decision depends on it. The report was built for a meeting, the meeting liked the green, and from then on the number's job was to stay green. A goal measured on closed tickets is best served by closing tickets, which is how the silent close and the bulk close get their funding.
Kestrel Payroll's monthly report showed an average resolution time of three hours and twelve minutes, over the 212 tickets closed that month. It left out the 38 tickets still open, whose average age was twenty-six days. It included nine tickets closed in under a minute because they were duplicates. Recomputed on everything opened that month, the honest figure was closer to two working days. Nobody had lied. The number had been asked an easy question.
The early-warning sign is a number that only ever improves, a report that is produced but not read, and a dashboard that is green while the hallway is full. The sharper test is to ask what decision the number last changed. If the answer is none, the number is scenery. A dashboard nobody acts on is a screensaver with a budget.
The fix is three numbers with a question each, and the honest version shown beside the flattering one. Volume in and out answers whether the desk is keeping up. The age of the oldest ticket and the count over thirty days answers whether anything is rotting. Reopen rate answers whether closed means fixed. Those are the first week's numbers in your first week running a helpdesk. They are hard to make look good without making the desk better.
The Self-Diagnosis Table
Run the table against your own desk in one afternoon. Most of the signs are counts you can pull from the queue in minutes; two require asking people, which is the part most diagnoses skip.
| Failure | The sign to look for | Where to look | What a healthy desk shows |
|---|---|---|---|
| The hero | One name on most hard tickets; the desk slows when they are away | Assignee counts for ninety days; the week they were last away | Hard tickets spread across the team; a runbook for each recurring one |
| The black hole | Unowned tickets, or tickets owned by a group; "any update?" replies | The oldest tickets still marked new; the unassigned filter | Nothing unowned for more than a few hours; a human reply within the hour |
| The silent close | Closed tickets whose last message is from the requester; duplicates | The last entry on a month of closed tickets; the reopen count | Every close has a note and a confirmation request |
| The shadow channel | A department raising far fewer tickets than its size predicts; an inbox busier than the queue | Volume by department against headcount; ask the quiet department | Every department raises tickets in rough proportion to its size |
| The category swamp | "Other" is the largest category; duplicate names | The category report; the length of the pick list | Ten to fifteen categories; "Other" under ten percent |
| The untracked walk-up | A busy day and a short closed list | Closed count against hours worked; ask the technicians | Walk-ups logged as tickets with their own source |
| Metric theater | A number that only improves; a report nobody reads | The report, and the meeting it was built for | Three numbers with a question each; the honest figure beside the flattering one |
Score it honestly and expect three. A zero on the first pass usually means the desk was diagnosed from inside, where quiet failures are invisible by design. Ask a requester from the quietest department to score it with you. The second pass is the real one.
A Short War Story: The Falling Count at Northgate Retail
Northgate Retail's support desk watched its monthly ticket count fall for six months, from about 320 to under 200. The desk was congratulated for it at the quarterly review. The count had fallen because the store managers had stopped using the portal and were e-mailing Sam. He was the technician who had once fixed the flagship store's checkout register over the phone in four minutes. They were using his own address. Sam answered everything, quickly and well, from his inbox, and none of it was a ticket. The shadow mailbox came to light when Sam took two weeks off and forty-one store problems arrived at the desk in three days. Most began "I usually e-mail Sam". The desk made Sam's address an intake address, so the same e-mail created a ticket in the same queue. The desk put the volume he had been carrying alone into the next report, with his name on it. The count went back up, and so, for the first time in a year, did the numbers that mattered.
Three of the seven were running at once there: a shadow channel, a hero, and a metric that rewarded both. Quiet failures are rarely alone, and the one you find first is seldom the one that started it.
Fixing in Order
Fix the black hole first, because it is the failure requesters feel. Every other failure is invisible to them; this one is the silence after they asked. It is also the cheapest fix, four habits and no settings. It earns you the right to ask people to use the queue, which the next fixes require.
Fix the shadow channel and the untracked walk-up together, second, because they are the same failure wearing two coats: work that is not in the queue. Until it is, every number the desk produces is a count of a sample, and the sample is whoever still bothers. Route the messages into tickets, log the hallway, and the queue becomes the record of the work rather than a record of the patient.
Fix the silent close third. It is quick and rebuilds trust faster than anything else on the list. It starts producing the reopen number, which you will want for the last step.
Fix the hero fourth, slowly. Copying what one person knows into runbooks and rotations takes months. It only works once the queue is the real record, because much of what the hero knows is in tickets that never existed. Start in month two and expect it to take the year.
Fix the category swamp and metric theater last. Both are about reading the desk, and there is no point reading a desk that is not yet recording what it does. Once the queue holds the real work, prune the categories against real tickets and replace the dashboard with three honest numbers. The dashboard will stay green through all of this. That is not its fault. It was never asked a hard question.
Frequently Asked Questions
Is a falling ticket count ever good news?
How do I find a shadow channel without starting a witch hunt?
What is the difference between a hero and a good senior technician?
How many categories should a small desk have?
Which metrics are not theater?
We have all seven. Where do we start?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
