First-reply SLA timer: start, pause and breach are three different events

A first-reply timer measures the business time between the moment a request becomes your responsibility and the moment a human answers it. Three conditions govern that measurement, they live in three different places in the configuration, and a team discussing only the target is discussing the least interesting part.

The consequence: 2 helpdesks with the same target and the same staffing will report different breach rates, because they disagree about when a ticket became your responsibility and about what counts as an answer.

What starts the clock

Ticket creation is the obvious answer and it is frequently wrong. The start condition varies by how the ticket came into existence.

• Inbound from a customer. The clock starts at creation, subject to the schedule — a request arriving at 22:10 on a Friday usually starts on Monday morning.
• Created by an agent on someone's behalf. Many setups start the clock immediately, so a rep logging a phone call at 17:55 manufactures a breach for a conversation that already happened.
• Suspended, then recovered. A ticket held by a spam rule has no clock until somebody recovers it, so the delay is absent from reporting — see the suspended queue nobody reads.
• Raised by automation. A monitor's tickets inherit whatever policy matches them, which is how an alerting integration acquires a 1-hour customer target.
• Which policy applies depends on who the requester resolves to: the person's entitlement, or the organisation's. That graph is one human, three records.

What stops it, and the reply that stops it wrongly

The stop event is a customer-visible message from a human. Everything else is work, and work is not a reply. Three things routinely stop the clock without answering anybody.

• The auto-acknowledgement. Sent as a public reply from an agent identity rather than a system notification, it satisfies the stop condition on every ticket, and first-reply time becomes a measure of how fast the automation runs.
• The empty macro. A greeting-only template sent to claim a ticket stops the clock and answers nothing, which is how first-reply time improves while resolution time worsens.
• A reply to the wrong person. A message to a colleague on the thread can satisfy the stop condition without reaching the customer at all.
• Reassignment, by contrast, does not stop the clock — which is why a ticket bouncing between teams looks acceptable in first-reply reporting and awful elsewhere: tickets bouncing between two groups.

Pause states are not equivalent

Helpdesks ship several waiting states and they behave differently. Only states explicitly configured to pause actually pause, and the defaults rarely match how a team uses them.

One ticket, annotated

One email against a 4-business-hour target, on a 09:00 to 18:00 schedule, with every transition marked.

One last thing moves breach rates with nothing about the clock changing: the mix. If a category with a tight target grows as a share of arrivals, breaches rise while every behaviour stays identical — which is why a jump gets investigated as a performance problem and turns out to be one ticket category doubling overnight.

Writing these 3 conditions down and matching them to the configuration is an afternoon that ends a recurring argument. It is the groundwork that makes everything else in ticket and inbox triage measurable, and where a helpdesk cannot express the rule you need, a small service beside it can — MVP and product builds work in our SaaS and customer support practice.

• SLA
• first response time
• helpdesk configuration
• triage