Service desk SLA: metrics, clock rules and pause states

A service desk SLA is a set of timers, one per promise. The target is the easy part. What decides whether a request met it is what the attainment rate divides by, how the hours are counted, and which states stop the clock.

The metrics, and what starts and stops each clock

Write one row per timer before you agree any target. Each row needs a start event, a stop event and a list of pause states. The table is a recommended definition set. Only the Zendesk pending behaviour and the Next reply start and stop come from vendor documentation.

Zendesk’s troubleshooting article lists First Reply Time, Next Reply Time, Periodic Update Time and Total Resolution Time as the four targets that do not pause in pending status. Requester Wait Time pauses on pending, and Agent Work Time pauses on both pending and on-hold. Status lists in most tools are longer than “pending”, so check on-hold too.

Atlassian’s Jira Service Management documentation uses “Respond to all requests within 2 hours” and “Resolve high-priority requests within 24-hours” as example goals. Read them as a format, not as benchmarks.

What the attainment rate divides by

The common mistake is to divide requests met by requests that closed in the period. That hides the backlog, because the requests most likely to miss are the ones still open.

attainment = requests whose stop event came within target / requests whose due time fell in the period

Worked example. In a period, 215 requests had a first response due. 180 got a reply within target. 20 got a reply late. 15 have no reply and are past due.

• Dividing by replied requests only: 180 of 200. The 15 unanswered requests drop out of the report.
• Dividing by all requests due: 180 of 215. The 15 are misses.

Decision rule: a request past due and still open is a miss on the reporting date. Remove only duplicates merged into another request. A pause changes the clock under the rule in your SLA, but it does not remove the request from the denominator.

Reporting window. Fix three things in writing: the cut-off (for example 23:59 in the calendar’s time zone on the last day of the month), the date you freeze the report (for example the fifth business day of the next month), and what a moved due time does. If a pause pushes a due time from the 29th into the next month, the request belongs to the month of its final due time, so the earlier month’s figure can change until the freeze. After the freeze, late corrections go into the next report as a labelled adjustment.

Reopened requests. Neither Intercom’s nor Atlassian’s article covers them, so this is a policy choice. A workable rule: a reopen within 7 days continues the original request and starts a next-reply clock but no new first-response clock. A reopen after that is a new request linked to the old one. Whatever you pick, apply it in the denominator the same way.

Calendar time and business time

As of 2026, Intercom’s help center says SLA timers are always running, time outside office hours is not counted toward the SLA, and by default one calendar day is treated as 24 hours. Zendesk’s troubleshooting article says that for an SLA policy built to respect business hours, the badge considers time outside business hours and holidays, and that the badge shows time left in calendar hours and days. Atlassian’s docs say Jira clocks run 24/7 by default, and a calendar under SLAs > Calendars can exclude lunch breaks, holidays or weekends. Create one calendar per team schedule there, and put the lunch break in it if your promise excludes it.

Worked example, with a 24 business-hour target and a schedule of 9am to 5pm, Monday to Friday, which is 8 hours a day:

• Start Monday at 9am. Monday, Tuesday and Wednesday give 24 business hours, so the due time is Wednesday at 5pm. That is 56 calendar hours later.
• Start Friday at 5pm. The clock does not run until Monday at 9am. The due time is again Wednesday at 5pm, which is 120 calendar hours after the start.

A 4-hour target with a message at 3pm on Monday leaves 2 business hours that day. The remaining 2 hours run from 9am on Tuesday, so the due time is 11am on Tuesday, 20 calendar hours after the start. If Tuesday is a closed holiday, the timer resumes at 9am on Wednesday and the due time is 11am on Wednesday. Intercom’s own Scenario 3 describes a holiday case with a 3pm Monday start and 4 hour target but states 1 office hour left and a 12pm Wednesday breach, which does not match a 9am to 5pm Monday. Check any worked example, including this one, against your own calendar.

Rules that follow:

• Store the due time as a timestamp computed from the calendar. Do not store start plus 24 hours.
• Name the calendar and its time zone in the SLA. Normally that is the calendar of the team that owns the promise. A customer’s public holidays count only if the SLA says so.
• If a contract gives one customer different hours, attach the calendar to the account, not to the channel. A shared channel can hold two customers on two schedules, and one global calendar then gives one of them the wrong due time. After any calendar change, check the due time on one open request per account.
• Label every remaining-time figure as calendar or business time.

Incidents and service requests need separate clocks

For an incident, keep a response timer and a restore timer. The restore timer stops when service is back, not when the ticket is closed. If the customer is waiting on your fix, the clock keeps running, because that wait is what the restore target measures. Pause restore only for a state you cannot act on, such as a vendor patch with no date, and write that state into the SLA with a named owner.

For a service request, keep a response timer and a fulfilment timer. Fulfilment can pause while the customer owes input.

Service request SLA example

A P3 access request, schedule 9am to 5pm Monday to Friday, response target 2 business hours, fulfilment target 24 business hours.

• Monday 10:00: request arrives. Both timers start.
• Monday 11:30: a human reply goes out. Response is met after 1.5 business hours.
• Tuesday 14:00: the team needs a signed form. Fulfilment has used 12 business hours (Monday 10:00 to 17:00 is 7, Tuesday 9:00 to 14:00 is 5). The fulfilment timer pauses.
• Thursday 10:00: the form arrives and the timer resumes with 12 business hours left. Thursday 10:00 to 17:00 is 7, Friday 9:00 to 14:00 is 5.
• Friday 14:00: fulfilment is due.

Without the pause, the request is due Thursday at 10:00 (Monday 7, Tuesday 8, Wednesday 8, plus Thursday 9:00 to 10:00 makes 24). The 12 paused business hours move the due time to Friday 14:00. This example uses a rule where a pause pushes the due time out. Intercom’s pauses do not push the breach deadline, so confirm which behaviour your tool has. A workable message to the customer: “We need the signed access form before we can start. The fulfilment timer is paused until we receive it.”

Pause states checklist

A pause state needs three things: a name in the SLA, a status the customer and agent can see on the ticket, and a restart rule. Without all three, a pause becomes a way to hide misses.

• Pending or waiting on customer: pause fulfilment, not first response.
• On-hold: Zendesk pauses Agent Work Time here. Decide whether on-hold means waiting on a third party, and if so name the owner.
• Customer has not replied: Intercom lists this as a pause example. Use it only if your SLA names it.
• Snoozed: Intercom says SLA timers can be paused when a conversation is snoozed. Pause on snooze only if your SLA lists it.
• Outside office hours: not counted, through the calendar. Intercom says this holds whether or not the conversation is also paused.
• Automated acknowledgement: it tells the customer you saw the message, not that you answered it. Keep it out of the first response stop event unless your SLA says otherwise.
• Waiting on a vendor or another internal team: pause only if written into the SLA with a named owner. Otherwise it becomes the default reason for every late request.

Jira Service Management reads Start, Stop and Pause conditions as “or”, not “and”, per its documentation. So a pause defined with several conditions fires when any one of them matches. If you need a pause only when two things are true, such as a status of waiting plus a specific field, you have to build that as a single condition. Test it on one ticket before you report on it.

Priority changes keep the elapsed time in Jira Service Management. The docs give a goal of 5 hours for Critical and 3 hours for Blocker: an issue 4 hours into its Critical goal that is raised to Blocker breaches at once, because the 4 elapsed hours already exceed 3. A breach happens only when the elapsed time exceeds the new goal, so raising an issue at 2 hours would not breach. Decide in the SLA whether a priority change resets anything.

Failure mode: a team uses “Pending” for “waiting on us” and “waiting on them” alike. Then every pause looks identical and the report cannot say who is late. Fix: split the status into “waiting on customer” and “waiting on us”, and pause only the first.

Breach handling and starting targets

Set the escalation before the first breach. When half the response target has passed with no reply, route the request to the assignee’s team lead. At the breach, add a reason code: customer paused, vendor, internal, or none. The miss stays in attainment with that code. The assignee at the moment of breach owns the miss.

When a fulfilment target is missed, send the customer the new date with the reason in plain words: “We missed the fulfilment time we agreed for this request. The new date is Friday at 2pm, and what is left is the access grant for your team.”

For starting targets, use Atlassian’s example goals, a 2-hour response and a 24-hour resolution for high-priority requests, as a format. Then pull 30 days of request timestamps and compute attainment with the denominator above before you commit. If the staffed desk cannot meet the target on that history, change staffing before you change the number.

Shared Slack channels and AI agents

In a shared Slack Connect channel, a workable start is the customer’s top-level message and a workable stop is a public reply from a named person in the thread. These are recommended rules, not Slack behaviour. A message posted into a thread that already has an open request extends that request and starts no new clock, though it can start a next-reply clock. See measuring first response time in Slack Connect for more.

A reply from a shared account that only acknowledges the message does not stop first response under the table above. A bot reply that actually resolves or answers the question can count under some SLA definitions, so say which in the SLA.

AI agents force that choice in 2026. Pick one of three and write it down:

• Acknowledgement and answers by an AI agent never stop first response. A human reply does. This is the strictest and is easy to audit.
• An AI answer stops first response only if the customer does not reopen or follow up within a set window, for example 24 business hours. Otherwise the clock is treated as never stopped.
• An AI answer counts the same as a human one. Then report resolution quality separately, or fast wrong answers will lift attainment.

Whatever you pick, tag each request with who handled it: AI only, AI then human, or human only. Report attainment per tag as well as in total. A rising total with a falling human-only figure shows the agent is absorbing easy requests, not that the team got faster.