How to Set Up Help Desk SLAs That Your Team Can Actually Hit
The short version
Set your first SLA based on what your team already achieves, not what you think sounds good. Measure for 30 days, then tighten by 10 to 15 percent. Repeat every quarter. The goal is continuous improvement, not a number that looks impressive in a deck.
Why most SLAs fail
The mistake most teams make is setting SLAs by guessing. Someone says “let’s commit to 4-hour first response,” the number goes on a slide, and three months later agents are gaming the system by sending holding replies to stop the SLA timer rather than actually resolving issues.
Two failure modes are common.
The aspirational SLA: you set a target 40 percent below your actual average, miss it constantly, and the number loses meaning. Agents stop caring because it feels like an unachievable standard.
The too-easy SLA: you set a target your team hits 98 percent of the time without trying. Customers are not well-served, and you have no signal that anything needs improving.
The useful SLA sits in the middle: one that your team hits 80 to 90 percent of the time, which means it is both achievable and still creates pressure to improve on the remaining cases.
Step 1: Measure first, set later
Before you write a single SLA number, pull your existing data. Most help desk tools can show you average first response time by ticket type, channel, and time of day.
If you have been operating without SLAs and your data shows:
- Average first response: 5.2 hours
- P75 first response: 7.8 hours (75% of tickets get a reply within this time)
- P90 first response: 14 hours
A reasonable starting SLA would be 8 hours for first response. That is above your average (achievable) but below your P90 (creates pressure on slow cases).
If you do not have this data yet, run without SLAs for 30 days while logging response times manually. It is worth the wait to have real numbers.
Step 2: Tier your tickets by impact
Not every ticket deserves the same SLA. A billing error affecting a paying customer is different from a feature request that can wait a week.
A simple 3-tier model works for most teams:
| Priority | Examples | First response SLA | Resolution target |
|---|---|---|---|
| Urgent | System down, payment issue, data loss | 1 hour | 4 hours |
| Normal | Bug reports, account issues, integration errors | 8 hours | 2 business days |
| Low | Feature requests, how-to questions, general feedback | 24 hours | No hard target |
The resolution target is different from the first response target. You can respond within 1 hour but not resolve a system outage that quickly. Both are useful to track; they measure different things.
Step 3: Adjust for channels and hours
SLAs that do not account for your support hours set agents up to fail. If you offer email support from 9 to 5 Monday through Friday, an “8-hour first response” SLA should probably mean 8 business hours, not 8 calendar hours.
Most help desk tools let you set business hours for SLA calculation. Use them. A ticket that comes in at 11 PM Friday should not be marked as SLA-breached at 7 AM Saturday.
Channel-specific SLAs are also worth considering:
- Live chat: response within 90 seconds
- Email: 8 business hours
- Phone: answer within 3 rings or offer callback within 2 hours
- Social media: 4 hours during business hours
Step 4: Track the right metrics
SLA hit rate alone is not enough. A team hitting 95 percent of SLAs by sending hollow “we’re looking into it” replies is not actually serving customers well.
Track alongside SLA hit rate:
- First response that moves the ticket forward: did the reply actually address the issue, or just reset the timer?
- Resolution time (not just first response): how long did the total interaction take?
- CSAT on SLA-missed tickets: how do customers actually feel about delays?
- Reopened tickets: did the resolution stick?
If your SLA hit rate is high but CSAT is low on support interactions, the SLA is being gamed. If SLA hit rate is lower than you want but CSAT is fine, your SLAs may be too tight for your team’s size.
Common mistakes to avoid
Setting different SLAs per channel without coordination: if email agents and chat agents are competing for tickets from the same queue, the SLAs create perverse incentives to cherry-pick easy tickets.
Not telling customers your SLA: customers who know you commit to a same-day reply will set their expectations accordingly. Customers who do not know often assume you saw their message and ignored it.
Setting SLAs for async channels without adjusting for time zones: if you have customers in multiple time zones, your 8-hour business-hours SLA hits differently depending on where they are. Consider extending your stated SLA slightly to account for this.
Frequently asked questions
What is a realistic first response SLA for a 3-person support team? For a small team, 8 to 24 business hours for email is common and achievable. If you are offering live chat, 90 seconds to 5 minutes is the standard expectation regardless of team size. Setting a faster SLA than you can hit consistently is worse than setting a realistic one, because missed SLAs damage trust more than longer response times do.
Should SLAs be included in customer contracts? For B2B customers, especially in SaaS and professional services, customers often expect SLAs to be written into service agreements. If you commit to SLAs in contracts, make sure your internal operational SLA is tighter than the contractual one to give your team buffer.
How often should you review and update SLAs? Quarterly is a good rhythm for most teams. Review your SLA hit rate data, look at whether tickets are being gamed to meet the SLA, and tighten targets by 10 to 15 percent if you are consistently hitting 95 percent or above.
What happens if you miss an SLA? Have a clear escalation path. For urgent tickets, a missed SLA should trigger an immediate alert to a senior agent or manager. For normal tickets, missed SLAs should show up in a weekly review. The goal is not to punish agents for misses but to understand whether the miss was due to volume, complexity, or process failure.