By Yair Knijn · February 4, 2025

Your SLA clock starts when the ticket arrives, not when someone acknowledges it. Most managers measure the wrong one.

A service-desk manager opens the Monday dashboard, sees 98% green on SLA compliance, and walks into the leadership sync with a clean number. The assumption baked into that walk is that green means the contract is being met. It usually means the tool is timing the one clock the contract barely cares about.

Most desks instrument time-to-acknowledge because it is the easiest event to capture: ticket created, agent assigned, status moved off New. The contract you signed almost never penalizes acknowledgement. It penalizes resolution. Those are different clocks, and only one of them shows up by default.

The four clocks in every SLA and why only one shows up on your dashboard

Every ticket runs at least four timers: time-to-first-response, time-to-acknowledge, time-to-resolve, and the customer-facing wall-clock from the moment they reported it. Your ITSM tool ships with response timing on by default because response is a single state transition. Resolution spans the whole lifecycle and depends on pause logic, business calendars, and priority, so it gets configured later, or never.

The result is a dashboard that flatters the desk. Agents tap a ticket within minutes, the response SLA goes green, and the resolution breach quietly accrues underneath. You can hit 98% on response and still be running 80% on resolution, and the customer only feels the second number.

How impact and urgency get mislabelled so P2s breach as P3s

Priority in ITIL is impact times urgency, and it is supposed to be set by the desk, not by whoever opened the ticket. In practice the requester picks the priority, or a default does, and a payroll outage lands as a P3 with a five-business-day target instead of a P2 with a four-hour one. The clock is now wrong by design, and the dashboard agrees with the wrong clock.

This is where the green-but-losing pattern starts. A misclassified ticket can sit for two days inside its (generous, incorrect) target and never flag. The account manager hears about it before your tool does, and by then the breach is already a credit note.

Pause clocks, business hours, and the timezone math that hides breaches

"Stop the clock" is everywhere in ITSM tooling, but it is a vendor convention, not an ITIL practice — the framework never defines it. Every pause you grant is a place a breach can hide. A common setup runs P1 and P2 on a 24x7 calendar while P3 and P4 pause overnight and on weekends. Mix that with a server set to one timezone and contracts written in another, and your "four business hours" quietly becomes a day and a half of real elapsed time.

• A ticket parked in Awaiting Customer by an agent who just wanted the clock to stop is not actually blocked — it is a manufactured pause.
• A weekend-paused P3 that should have been a 24x7 P2 hides two full days of elapsed breach.
• Business-hours math computed in the wrong timezone shifts every target without anyone touching the SLA definition.

Building a resolution-breach report a director can take to a QBR

The report that matters does not lead with the green percentage. It leads with resolution breaches by priority, with pause time stripped back out so you see real wall-clock-to-resolve next to the contractual target. For each breach you want the audit trail: when it arrived, how it was classified and by whom, every pause and who applied it. That is the difference between a number a director can defend and one that collapses the first time the customer pulls their own ticket export.

OpsDesk times resolution and response as separate clocks per priority inside each customer workspace, keeps pause events on the audit trail instead of swallowing them, and generates the resolution-breach view your director takes into the QBR before the account manager hears about it. If your current tool only proves you answered fast, see what measuring the clock the contract penalizes looks like.