A dashboard showing 95% SLA compliance while your support inbox is full of frustrated customers is one of the more disorienting problems in operations — the numbers say everything's fine, but everyone closest to the customer knows it isn't. This gap almost always comes down to a measurement problem, not an actual performance problem. Here's how to find it.
Check what "the clock starting" actually means
The most common cause: SLA timers start when a ticket is created in the system, not when the customer actually raised the issue. If there's any delay between a customer calling, emailing, or messaging and someone logging that as a ticket — even 20-30 minutes — your SLA clock is silently running short of the customer's actual experience. A "resolved within 2 hours" ticket that sat unlogged for 40 minutes first was really a 2 hour 40 minute experience from the customer's side.
Fix: capture the actual first-contact timestamp, not the ticket-creation timestamp, wherever the two can differ.
Check whether "resolved" matches the customer's definition of resolved
Internally, "resolved" often means an engineer marked a work order or ticket as complete. From the customer's side, resolved means the problem is actually gone and stays gone. These aren't always the same moment — a fix that required a follow-up visit, or an issue that recurred within days, can be counted as "resolved" in your SLA report while the customer experienced an ongoing problem.
Fix: track reopened tickets and repeat visits for the same underlying issue as a distinct metric, and treat a short-window reopen as evidence the original resolution shouldn't have counted.
Check whether SLA breaches are being excluded before they're counted
A subtler failure: some SLA reporting setups quietly exclude certain categories from the denominator — tickets marked "customer unavailable," "on hold," or "pending parts" often don't count against the SLA clock. That's sometimes legitimate (you shouldn't be penalized for a delay outside your control), but it's also an easy place for genuinely late resolutions to get reclassified into an excluded bucket, especially if the exclusion criteria aren't audited.
Fix: periodically audit what share of tickets fall into "excluded" categories, and who has the ability to apply that classification. A sudden increase in exclusions is worth investigating on its own.
Check whether you're averaging when you should be looking at distribution
An average resolution time of 2 hours can hide a distribution where most tickets resolve in 20 minutes and a meaningful tail takes 8+ hours. Averages flatter operations with a long tail of badly-handled tickets, because the fast majority pulls the number down. Customers who land in that tail are the ones showing up in your complaints, even while the average looks healthy.
Fix: report percentiles (median and 90th percentile resolution time), not just the average, for any SLA metric that matters.
A worked example of the average-vs-distribution problem
Illustrative numbers, not a real dataset — chosen to show the shape of the problem clearly.
A fictional field-service team, Coastline HVAC Services, reported a healthy 2 hour 10 minute average resolution time for a month of 200 tickets. Breaking the same 200 tickets down by percentile tells a different story:
| Metric | What it shows |
|---|---|
| Average resolution time | 2h 10m — looks fine on a dashboard |
| Median (50th percentile) | 1h 05m — most tickets really are fast |
| 90th percentile | 9h 40m — 1 in 10 tickets took most of a working day |
| 99th percentile | 26h 15m — a real, if rare, tail of badly-handled tickets |
The average is technically accurate and almost useless for spotting a problem: it's pulled down by the large number of genuinely fast tickets, while the 20 customers in that 90th-percentile tail are the ones generating complaints — and they're invisible in the top-line number the team was reporting to leadership.
Where this connects to system design
Most of these problems are fixable with better measurement discipline, but they're much harder to introduce after the fact — retrofitting "actual first contact time" tracking onto a system that only ever captured ticket-creation time means historical data is unrecoverable. This is why SLA tracking in Helpdesk and Field Service dispatch is built to capture the real trigger event, not just the system-record timestamp, from day one — the measurement discipline has to be structural, not a reporting layer bolted on afterward.
If your SLA dashboard and your customer sentiment disagree, start with these four checks before assuming your team's actual performance is the problem. More often than not, it's the ruler that's wrong, not the thing being measured.