Key Points
- SLA breaches can result from slow technician work, external wait time, or incorrectly counted non-working hours, and each requires a different fix.
- Separating active work time from wait time helps IT teams distinguish technician performance issues from delays caused by users, approvers, vendors, or dependencies.
- Approval steps should be tracked inside the ticket with named owners, deadlines, and escalation paths, so stalled decisions remain visible and attributable.
- SLA timers should use configured support hours and holiday calendars to avoid false breaches caused by nights, weekends, or regional scheduling differences.
- Pre-breach alerts give support teams time to reassign or escalate tickets before service targets are missed.
- Reviewing breached tickets by root cause helps MSPs and internal IT teams improve service delivery without incorrectly blaming technician speed.
Pull up this week’s breach report, and two tickets look identical: same red flag, same missed target, same line in the monthly summary. Look closer, and those tickets have nothing in common. One sat in a queue for three days because nobody picked it up. The other was diagnosed in twenty minutes and then waited two days for a device owner, who never opened the approval email. An SLA is a promise made before the ticket ever exists. Falling short of it is more than just a metric. It costs you trust from a client, a department head, or an end user.
If you could split the Service Level Agreement (SLA) into work time and wait time, you can more effectively show where you’re meeting or missing SLAs. This doesn’t require you to track something new. Every one of those minutes already lives in your ticket history as a status change with a timestamp. What’s missing is the split: work time on one side of the ledger, wait time on the other. Without it, “we’re missing our SLAs” reads as a technician problem, even in the weeks your team was the fastest part of the process.
Split the clock into work time and wait time
The elapsed time between “opened” and “resolved” is two different things stacked on top of one other. Part of it is a technician actively working the ticket. The rest is the ticket parked, waiting on an approver, a vendor, or an end user who hasn’t replied.
Both are worth fixing, but not with the same approach. Work time responds to context. A technician who loses the first fifteen minutes of every ticket hunting for device history and asset records before troubleshooting even starts isn’t slow – the setup is slow. Give them that context up front, and the ticket that used to take an hour of digging starts with the digging already done. That gain belongs entirely to the work-time side of the ledger.
No amount of technician speed touches wait time. Define a status, or a small set of them, that means “waiting on someone who isn’t us.” Make sure your resolution target either pauses in that status or reports time spent there separately. That one change turns a single aggregate number into two numbers you can act on.
Treat sign-off as a tracked step
ITIL’s change enablement practice makes it clear that a change requires authorization from someone accountable for the risk. You’ve almost certainly already got that authorization, but it’s happening in a Slack DM or a one-line email, most often outside the ticket. For a laptop config change, that is the right amount of process.
But when you’re running a support function, an unanswered approval email is invisible. The ticket shows as stalled, your technician gets asked why, and the honest answer is that someone has to clean up their inbox. As far as an audit goes, an approval that no one logged didn’t happen. Attach the sign-off as an explicit step on the ticket – a named approver, a manager, a device owner, a role, an ad-hoc list – and it stops being a soft dependency and becomes an attributable one. You can see exactly who owes you a decision and how long they’ve owed it. Give the approval step a timeout and an escalation path, too. A bounded wait is a known cost; an open-ended one is a black box.
Run the timer on your support hours, not the wall clock
An eight-hour resolution target measured against wall-clock time breaches every Friday night, on schedule, whether or not anyone did anything wrong. The same thing happens across holidays, and it happens unevenly when your team spans regions that don’t share a calendar.
False breaches cost more than they appear to. They inflate your numbers, and the first time a technician notices the report is counting hours nobody worked, they stop trusting the report, which means the real breaches stop getting attention too. Configure support hours and holiday calendars, per organization or globally, and the timer starts measuring something worth acting on.
Set your escalation threshold before the breach. An alert at 80% of allotted time gives you a window to reassign. An alert at breach gives you a postmortem.
That’s not just an internal number, either. If you’re an MSP, response times are a commercial commitment that differs by client and by tier – and when wait time goes unrecorded, you walk into a renewal or billing conversation with no evidence of whose clock the time was actually on. If you’re running an internal help desk instead of a client book, the stakes look different but the exposure is the same: nobody’s invoicing you for a missed SLA on patch deployment, but the security lead asking why the same three endpoints missed their patch window twice this quarter is having exactly the same conversation, just without the line item.
Where to start
Pull your last 90 days of breached tickets and sort them into three piles: worked too slowly, waited on a person, and should never have counted. The second and third piles are usually bigger than the first, and neither one gets fixed by asking anyone to work faster.
NinjaOne Ticketing tracks response and resolution targets by priority against your configured support hours, and surfaces SLA status and time remaining as board columns you can filter and sort on, with alerts at 80% of allotted time and at breach. Approval steps route to a manager, device owner, role, or an ad-hoc list, get cleared by email, and log the decision on the ticket itself. Start your free trial.
