Most service desk tools have a state that stops the SLA clock. Usually it's called On Hold. The idea is fair: if you're waiting for the user to reply, or for a supplier, that time shouldn't count against the team.
The problem is that it's also the easiest way to make a late ticket look like it was on time. Nobody has to cheat for this to happen.
A typical case
A priority 2 incident comes in with a four-hour target. After two hours the engineer needs a log file from the user, so they put the ticket On Hold, reason "awaiting caller". The clock stops, which is correct.
The user sends the file an hour later. The ticket doesn't move, because nothing takes it out of On Hold except a person, and nobody looks. Two days later someone picks it up and fixes it. The report says it took three hours. On time.
Do that a few hundred times a month and the SLA report stops describing the service people actually get.
What to set up
A reason from a short list. Awaiting caller, awaiting supplier, awaiting change, awaiting problem. No free text. If none of the reasons fit, the ticket probably shouldn't be on hold.
Decide which reasons stop the clock. Waiting for the user, yes. Waiting for another team inside the company is a different story. That's work the customer is still waiting on, and it belongs in an internal agreement (an OLA), not in a paused clock. Write the decision down for each reason.
A way out. When the user replies, the ticket should come off hold by itself, or at least show up again in front of whoever owns it. If it depends on someone remembering, it will sit there.
A time limit. After a set number of days on hold, someone reviews it. Escalate it, close it with a note, or take it off hold. It shouldn't just stay there.
Report the pause, not only the breaches
Most SLA reports show one number, the breach rate. I'd put a second one right next to it: how much of the ticket time was spent on hold, by team and by service.
A team that's always on time but spends 40% of its ticket time on hold isn't necessarily fast. That's worth a conversation, not a reprimand. Usually it means the process hides the waiting instead of shortening it.
Two other numbers help:
- how many tickets went on hold more than once
- how long, on average, a ticket stays on hold after the user has replied
The handover nobody decides
The hardest case is the incident the service desk can't fix and has to send to the developers, often as a linked ticket in another tool. What should the clock do then?
If it keeps running, the service desk is measured on work it can't do. If it stops, the customer's wait disappears from the report, sometimes for weeks.
Both options can work. What doesn't work is never choosing. A reasonable setup: a separate reason like "awaiting development" that stops the clock, a limit on how long it can stay there, and the development time reported on its own so the person in charge of that team sees it. Then check that the tool and the report follow the same rule.
If you want to check yours
Ask three questions:
- Which on-hold reasons stop the clock, and who decided that?
- How much ticket time is spent on hold, per team?
- What happens to the clock when a ticket goes to development?
If nobody can answer the third one, I'd start there.
At Lumenfold we help IT teams set up service management that shows what really happens. More about ITSM →
Written with AI assistance.