Support SLAs: defining timers and escalation rules

Support looks fast in the report, yet the customer still complains: an automatic email arrived first, the issue was passed to engineering, and the ticket then spent several days “waiting.” Different definitions of time may explain the discrepancy. Without rules for starting, pausing and stopping clocks, an SLA becomes a number that cannot be checked against the ticket history.

HubSpot's guide to SLA tracking distinguishes first response, subsequent responses, resolution time and time spent waiting for the team. In the model it describes, an automatic acknowledgement does not count as the first response. This is a useful basis for independent definitions, but commitments, schedules and exceptions need to match the agreement with the customer.

Define the event before the deadline

Consider a B2B service handling routine requests during business hours, with a separate route for critical incidents. “Reply quickly” is insufficient. Define the starting event, required action and calendar used to calculate the deadline.

A first-response clock might start when a request reaches a supported channel. It might end when an employee provides a substantive answer containing a solution or clear next action. If AI replies, decide separately when its message satisfies the commitment: merely repeating the question should not stop a timer because text was sent.

Resolution needs a different definition. An employee marking a ticket closed may not coincide with verified restoration of the service. Record what constitutes resolution, how the result is checked and what happens if the ticket reopens. Otherwise, cases completed on different grounds are being compared.

Business hours differ from elapsed time

Choose the time zone, schedule, holidays and treatment of requests outside the service window. In an illustrative example, a request arrives on Friday evening and support resumes on Monday. Under a business-hours calendar, some time begins counting only when the next window opens; a continuous SLA keeps running over the weekend. The commitment determines the correct approach.

Do not automatically apply an individual agent's schedule to the customer. Several shifts may cover a single agreed service window. Schedule changes need a history too: recalculating old cases under new rules can make period comparisons misleading.

Connecting tickets, customers and service terms requires CRM integration. The Dent-Picks service operations case study offers context for operational roles and data; it does not establish a particular SLA or implementation of this article's rules.

Every pause needs a reason

Waiting for customer information can be excluded from particular metrics when that is explicitly agreed. But one “waiting” status should not combine missing customer information, engineering work and an internal approval delay. Those causes have different owners.

For each pause, record the starting event, information required and resumption condition. For example, an agent requests an order number; a new customer reply returns the ticket to the active queue. Test a reply arriving through another channel, with messages merged later. Routing behavior should not leave the clock paused after the information has arrived.

Show total elapsed resolution time alongside time spent waiting for the team. That keeps pauses from hiding the customer's experience: a case may meet an internal measure while taking several days from submission to outcome.

Escalation should assign work

In its SLA management guide, HubSpot connects external commitments with internal operational level agreements, or OLAs. Its authors recommend agreeing handoffs, schedules and routing in advance, then investigating breaches. Product performance figures in that publication are not forecasts for another team; the relevant idea here is ownership.

If an engineering investigation consumes most of the available window, a last-minute notification to a manager cannot fix the process. Work backward from the customer commitment: when must engineering receive the request, who accepts it, and when should a manager see the risk? Set warnings according to the remaining opportunity to act.

Escalation should change ownership or priority under a defined rule and preserve the history. Test situations with no available employee, an ending shift and several simultaneous urgent cases. These transitions belong to workflow automation, rather than notification settings alone.

Conversations and onboarding affect the clocks

Meeting a deadline still requires explaining the next step. A context-free question or a request to repeat the problem can produce an attractive first-response metric and a poor experience. Assess AI support conversation design alongside timing measures.

Separate new customers as well. Repeated questions after launch may call for better onboarding and repeated value, rather than tighter SLAs. Combining these requests with incidents obscures the causes of workload.

Check the rules against a ticket history

Before launch, examine several scenarios: a normal reply, waiting for the customer, a weekend, a priority increase, an engineering handoff and reopening. Mark events and expected clock results manually, then compare them with the system. A priority change should not silently erase elapsed time.

When a breach occurs, assign a recovery action and give the customer an updated expectation. In the team's review, distinguish causes: an unowned queue, insufficient availability, a schedule error, complex work or a missed restart. Improvement means resolving a specific cause, rather than obtaining a more attractive compliance percentage by changing the rules.

Sources

• SLA tracking: What it is and how to do it right
• SLA management: What it is and how to do it right