Two clocks, not one#
Every ticket carries two distinct promises: how fast a human first responds, and how fast the problem is actually resolved. Clients feel the first one hardest — silence is what makes people escalate — and teams control it most directly. Track them separately, target them separately, and never let a fast "we're on it" masquerade as progress on the fix itself.
Pick the clock honestly#
A 4-hour response target means something completely different on a 24/7 clock than on a business-hours clock. If you support 8-to-6 weekdays, a ticket filed Friday at 5pm with a 4-hour target is due Monday morning — that is not cheating, that is the promise you actually sold. Run each board on the clock that matches its contract: 24/7 for the after-hours retainer, business hours (with your holiday calendar) for everyone else.
The dishonest version — measuring business-hours teams against a wall clock — produces breach reports full of weekend "misses" nobody could have prevented, and the team learns to ignore the report.
Waiting on the customer stops the clock#
The moment a ticket needs something from the client — approval, credentials, a reboot window — the clock should pause. Without pause states, your resolution numbers punish you for client slowness, and the team starts closing tickets prematurely to protect the metric (and reopening them later, which is worse data and worse service).
Pause states need discipline of their own: a ticket sitting in "Waiting on Customer" for two weeks is not paused, it is abandoned. Put a reminder cadence on the waiting state — nudge at intervals, then auto-close with a courteous note and an easy way back in.
Alert before the breach, not after#
A breach alert that fires when the target is already missed is a report, not a tool. The useful signal fires when a ticket is approaching its target with time to act — surfaced in the queue where triage happens, not buried in email. Save the after-the-fact breach notification for standing recipients who own the client relationship, and let automations act the moment a target is missed (bump priority, reassign, notify) so the response is a rule, not a hero, while the queue's warning flags what is about to slip.
Targets by priority, priorities by rule#
SLA targets attach to priorities — P1 gets an hour, P3 gets a day — which means the real SLA decision is who sets the priority. If every inbound email lands as "default," your targets only apply to tickets someone remembered to re-triage. Put rules (or AI-assisted triage) at the front door: keywords, senders, and boards route the ticket and stamp the priority, and the human review corrects rather than originates.
Report compliance, not heroics#
The number that matters over time is the compliance rate — what share of tickets met their targets — per board and per priority, on the same clock the promise was made. Watch it monthly: a falling response compliance is a staffing signal, a falling resolution compliance is a scoping or escalation signal, and both are visible long before a client says anything.
Takeaways#
- Track response and resolution as separate promises — clients feel silence hardest.
- Run each board on the clock its contract sold: 24/7 or business hours with holidays.
- Waiting-on-customer pauses the clock — and needs its own reminder-then-auto-close cadence.
- The useful alert fires before the breach, in the queue, with automations able to act on it.
- SLAs attach to priorities, so the front-door triage rules ARE your SLA coverage.