What is a help desk SLA?

A help desk SLA is a service level agreement that defines target response and resolution times for support tickets, usually by priority, customer tier, team, and business hours.

Updated October 21, 2026 7 min read
What is a help desk SLA?

Key takeaways

  • A help desk SLA turns response and resolution expectations into visible ticket timers and ownership rules.
  • First-response time, next-response time, and resolution time measure different parts of the customer experience.
  • Targets should reflect priority, coverage, business hours, and a clear escalation path—not an arbitrary industry number.

Quick answer

A help desk SLA, or service level agreement, defines how quickly a support team aims to respond to, update, and resolve tickets. The help desk applies the relevant policy, runs a timer during the configured service hours, warns the owner before breach, and records whether the target was met.

SLA response time vs resolution time

A fast first reply does not necessarily mean a fast solution. Track the stages separately so one easy metric does not hide a long or confusing customer journey.

Common help desk SLA time targets

SLA metricTimer startsTimer stopsWhat it reveals
First-response timeWhen the first customer message creates or reopens a ticket.When an agent sends the first meaningful reply.How quickly the team acknowledges and begins ownership.
Next-response timeWhen the customer replies during an open conversation.When the team sends the next meaningful update.Whether active conversations keep moving.
Resolution timeWhen the ticket enters the support queue.When the issue is solved or the ticket is resolved under the agreed rules.How long the customer waits for an outcome.

How an SLA timer works in a ticketing system

  • Match the ticket to a policy using priority, customer tier, team, topic, or channel.
  • Start the relevant response or resolution timer when the policy applies.
  • Pause the clock outside business hours or while waiting on the customer only when the agreement says so.
  • Warn the owner and team lead before the target is missed.
  • Record the breach reason so routing, staffing, and policy problems can be reviewed.

What a help desk SLA policy should include

ScopeWhich customers, plans, teams, channels, or ticket types the agreement covers.
Service hoursTime zone, working days, holidays, and whether the timer runs continuously or only during coverage.
TargetsFirst response, next response, update cadence, and resolution expectations by priority.
Escalation and exclusionsWho gets notified, what pauses the clock, and which events sit outside the agreement.

Example help desk SLA priority matrix

Use the following as a planning example, not a universal benchmark. Set the actual times from customer commitments, staffing, channel expectations, and the risk of each priority level.

Illustrative SLA matrix—replace these targets with commitments your team can support

PriorityTypical situationExample first responseExample update or resolution goal
UrgentService unavailable, security risk, or business-critical blocker.15–30 minutesFrequent updates until stabilized; named escalation owner.
HighMajor workflow impaired with no practical workaround.1–2 business hoursSame-business-day update and agreed recovery plan.
NormalStandard product, account, or policy question.4–8 business hoursResolution or next useful update within 1–2 business days.
LowHow-to request, feedback, or non-blocking question.1 business dayResolution or planned follow-up within several business days.

How AI triage supports SLA workflows

AI triage can flag urgency, sentiment, topic, and routing risk when the ticket arrives. That helps high-risk conversations reach the right owner before the SLA timer becomes the only warning.

Help desk SLA metrics to review

  • First-response and resolution compliance by priority, customer tier, channel, and team.
  • Tickets that breached because they were unassigned, misrouted, or waiting in the wrong queue.
  • Time spent waiting on the team compared with time waiting on the customer or a third party.
  • Topics that repeatedly approach breach and need better staffing, automation, or documentation.
  • Customer satisfaction, reopen rate, and repeat contact after breached and non-breached tickets.

How to set realistic SLA goals

  • Measure the current response and resolution distribution before promising a target.
  • Separate urgent incidents from routine questions so one queue does not distort every target.
  • Choose the coverage calendar and pause rules before configuring the timer.
  • Set a warning threshold early enough for another person to help before breach.
  • Review breached tickets monthly and change the workflow when the same cause repeats.

Put the SLA into the support workflow

A written agreement matters only when the queue makes it visible. Connect the policy to routing, ownership, business hours, warnings, and reporting so agents can act before a breach.

How to calculate SLA response time during business hours

Suppose support hours are Monday to Friday, 09:00–17:00, and the first-response target is four business hours. A ticket arriving Friday at 16:00 uses one hour that day. Its remaining three hours run on Monday, so the deadline is Monday at 12:00, assuming there is no holiday. Under a 24/7 calendar, the same four-hour target ends Friday at 20:00.

  • Specify the time zone and holiday calendar before calculating a deadline.
  • Count only the time included in the agreement; do not silently change pause rules after a breach.
  • Decide whether an automated acknowledgement satisfies the first-response promise or whether a meaningful support reply is required.

How to calculate SLA compliance

SLA compliance is the number of eligible targets met divided by the number of eligible targets measured, multiplied by 100. For example, if 180 of 200 measured first-response targets were met, first-response compliance is 90%. Calculate resolution compliance separately; meeting the first-response target does not mean the issue was resolved on time.

  • Use the same reporting window, policy, and priority group for numerator and denominator.
  • Document exclusions and how targets still in progress are treated.
  • Read breached conversations to distinguish missed routing, staffing gaps, and unrealistic targets.

A small SLA reporting example, not a benchmark

MeasureCalculationResult
First-response compliance180 targets met ÷ 200 targets measured × 10090%
First-response breach rate20 targets missed ÷ 200 targets measured × 10010%

Frequently asked questions

There is no fixed setup time. A team with agreed targets, service hours, priorities, and named escalation owners has less preparation to do than one still defining those policies. Before going live, test business-hours boundaries, holidays, reassignment, customer-waiting states, and breach alerts with sample tickets. Configuration is ready when those cases behave as agreed, not simply when a timer appears.
Separate the customer response commitment from an internal AI triage quality target. Define how routing errors are reviewed, who corrects them, and what happens when AI is unavailable. Keep the customer response timer and escalation owner clear; a fast AI classification is not the same as a meaningful reply to the customer.
SLA means service level agreement. In a help desk, it defines the response, update, or resolution times the support team commits to for a class of tickets, along with service hours, pause rules, and escalation steps.
Yes, once support volume grows. SLAs turn response expectations into a visible operating system.
A first-response SLA measures how quickly the team replies for the first time. A resolution SLA measures how quickly the issue is solved or closed.
No. Urgent, high-value, or business-critical tickets often need tighter targets than routine questions.
Pause rules should follow the agreement. Common examples include time outside configured business hours or periods when the team is waiting for required customer information. Document every pause condition so the metric cannot be gamed.
The help desk should alert the owner and escalation contact, make the breach visible, and record why it happened. The team should still solve the issue; the breach is a signal to review routing, coverage, workload, or the target itself.

Try Protodesk free for 7 days

Connect your first inbox, invite your team, and see AI triage, sidekick drafts, and auto-resolve with 300 trial credits. No credit card required.