The Ticket That Turns Into Work
A support desk has one door and four kinds of request come through it. Three of them can be answered. The fourth is work — and the moment a desk treats work as a question, its SLA stops measuring anything.
A ticket has been open for thirty-one days. It is red on every dashboard, it is dragging the desk's resolution average into a shape nobody wants to present, and reading it back shows that the agent did everything right. It was answered within the hour. It was routed correctly. And then it stopped being a support question, because the answer turned out to be "the system needs to do something it does not currently do" — and there is no version of that which resolves inside a support desk.
Every desk has these. They are not failures of support and they are not rare. They are the consequence of an organizational design that almost every organization chooses on purpose: one door for everything, because making the requester guess which door to use is worse. The door is right. What is usually missing is what happens on the other side of it.
Four kinds of request wearing the same uniform
| What arrived | What actually closes it | Who owns it | What the clock should do |
|---|---|---|---|
| A question | An answer. Somebody knows the thing. | The desk, start to finish. | Run. This is exactly what an SLA is for. |
| An incident | A fix or a workaround, then a cause. | The desk, with help. | Run — but the resolution target for an incident is a different promise from the one for a question, and most desks use one number for both. |
| A change | A decision by somebody who can authorise it, then work. | Not the desk. The desk is the messenger. | Stop when the decision leaves the desk. It is not measuring support any more. |
| A piece of work | Delivery. Weeks, sometimes quarters. | A project or a backlog. Never the desk. | Stop at the handover. Keeping it running measures the roadmap, not the desk. |
The metrics go before the service does
A desk carrying work as tickets degrades in a specific order, and the order matters because the early symptoms are misread as staffing problems.
First, the resolution average inflates — a handful of multi-week items drag a number that is otherwise healthy, and the desk looks slow while every answerable ticket is being answered promptly. Then the backlog stops being actionable: an agent scanning open tickets learns that a third of them are things nobody can act on today, and once a queue trains people to skim it, the genuinely urgent item in the middle gets skimmed too. Finally the SLA gets quietly abandoned as a management tool, because everybody knows the breaches are "just the old ones" — which is true, and which means the number no longer distinguishes a good week from a bad one.
The breaches are "just the old ones" — which is true, and which is exactly why the measure has stopped working. A metric everyone knows to discount is not a lenient metric. It is an absent one.
The distinction worth holding on to: this is not the same as the desk being slow, and treating it as a staffing problem adds agents to a queue whose problem is that it contains the wrong kind of item. The measures that survive the mix — backlog age distribution rather than average, and reopen rate — are in support metrics that are not vanity.
The handover, and the two things it does not do for you
The mechanism itself is straightforward and worth using: a ticket can be escalated into a project task, which carries the subject, description, priority and assignee across, links the two records together so each can be found from the other, and writes a note on the ticket saying where the work went. The link is deliberately loose — the task points back at the ticket polymorphically rather than through a hard foreign key — which is the right call, because support and delivery should not be welded to each other.
Two behaviours to know before you rely on it
The new task belongs to no project. It is created with an assignee and a priority but no project, which is valid — the column is nullable — and means the task exists in the general pool rather than inside the plan somebody is actually managing. If the work matters, somebody has to put it somewhere on purpose, and nothing will remind them. The ticket keeps running. Escalating does not change the ticket's status, so the resolution clock continues on a request whose work has demonstrably left the desk. Both are defensible engineering decisions and neither is guessable from the button, which is why they are worth writing down.
The pause state you do not have
The obvious fix is to pause the clock at handover, and it is worth being precise about why that is harder than it sounds. The resolution clock pauses on exactly one status: waiting on the requester. Entering it stamps a pause, leaving it pushes the due date forward by however long the wait lasted. That mechanism is well built and it is fair, which is the whole argument of SLAs that mean something.
But notice what it means. The one available pause says we are waiting on you. The situation you actually have is you are waiting on us. Those are opposite claims about whose court the ball is in, and only one of them can be recorded.
So a desk with escalated work has three options and none of them is clean:
- Let it run and breach. Honest, and it degrades the measure exactly as described above. Defensible only if these are rare enough to name individually.
- Mark it as waiting on the requester. Stops the clock, and puts a false statement in the record — one that will be read back during a dispute, and that skews any analysis of how long customers take to respond. This is the common choice and it is the one to think hardest about, because it trades a visibly wrong number for an invisibly wrong one.
- Resolve the ticket and let the task carry the work. The cleanest of the three, and it requires the discipline that makes it work: the requester is told the request has moved and where, and somebody owns telling them when it lands. A ticket resolved silently while the person still waits is the worst outcome available, and it is what this option decays into without that discipline.
The third is usually right, and the reason is that a ticket and a piece of work have genuinely different lifespans. Holding a ticket open for a quarter to represent something a backlog is already tracking gives you two records of one commitment, both half-maintained.
Decide at intake, not at day thirty
Everything above is cheaper if the sort happens early. It will never happen at intake reliably — the requester does not know which of the four they have, and often neither does the agent on first read — but it can happen fast, and "fast" is the achievable target.
-
Ask the closing question on first response
Not "what is the problem" but "what has to be true for this to be finished". If the answer is something the desk can do, it is a question or an incident. If it is something somebody else must build, decide or authorise, it is a change or a piece of work, and it is already in the wrong container.
-
Give it a visible label the day it is known
A category, a tag, anything that lets the queue be read without it. The point is not classification for its own sake — it is that an agent scanning the backlog can see what is actionable today, which is the property the mix destroys first.
-
Hand over with the destination named
Escalating produces a task. Putting that task into the project or backlog that somebody actually reviews is a separate act and nothing prompts it. A handover into an unreviewed pool is not a handover; it is a deferral with extra steps.
-
Close the loop backwards
When the work ships, somebody tells the person who asked. This is the step that fails most often, because by then the ticket is closed, the agent has moved on, and the only record of who cared is a link on a task nobody is looking at. Whoever owns the task owns this.
Three questions for whoever supplies your desk
Testing the boundary, not the queue
What happens to the SLA clock when a ticket is handed to engineering?
What you are listening for
A named state, or an honest "it keeps running".
How to read the answer
Most tools keep running and most demos never show it. "It keeps running" is a fine answer that lets you design around it. Vagueness here usually means nobody has been asked before.
Can I pause a clock for a reason that is our fault, and does the reason get recorded?
What you are listening for
A pause with a reason code, or a clear no.
How to read the answer
A pause with only one meaning will be used for every meaning, and your response-time data quietly becomes a record of something else.
Where does escalated work land, and who reviews that place weekly?
What you are listening for
A named container, and a named person.
How to read the answer
This is an organizational answer, not a product one, and the vendor may not have it. You still need it — the most common failure here is a working button pointing at a pool nobody reads.
A monthly review that takes fifteen minutes
Read the tail, not the average
- List every open ticket older than three times your resolution target. This is the set, and it is usually short enough to read one by one.
- For each, answer one question: can this desk close it by doing something? If no, it is work in the wrong container, today.
- Check where the escalated tasks went. Any task with no project is in the pool, not in a plan — decide which plan it belongs to or accept that it is not being done.
- Count how many tickets are sitting in "waiting on the requester" where the requester is, in fact, waiting on you. That count is the size of the lie in your response-time data.
- Tell one person from the oldest handover what happened to their request. If that is difficult to find out, the loop is not being closed for anybody.
The short version
One door for every request is the right design, and it works only if something sorts what came through it. Three of the four kinds can be answered; the fourth is work, and a desk that carries work as tickets loses its resolution metric first, its readable backlog second, and its SLA as a management tool third. Escalate the work, put the resulting task somewhere a human reviews, resolve the ticket with the requester told where their request went — and know, before you need it, whether your clock can express "waiting on us", because most cannot, and the workaround people reach for records the opposite of what is true.
