A workable SLA is a response and resolution target per priority tier, measured against your business hours, with an at-risk alert that fires before the deadline so someone can act in time. The goal is not the strictest possible numbers — it is targets your team can hit on a normal week, because an SLA you routinely miss is one everyone learns to ignore. Set it deliberately, automate the escalation, and tighten only when the data supports it.
Start with priority tiers
Not every ticket deserves the same clock. Set tighter SLA targets for higher priority or higher-value customers, and looser ones for everything else. A single global target either over-promises on routine questions or under-serves the urgent ones. Three or four tiers is the usual sweet spot — enough to distinguish a down-for-everyone outage from a how-do-I question, few enough that triage stays consistent.
- Urgent — something is broken for many users or a key account; fastest response and resolution targets.
- High — blocking one customer's work, no workaround.
- Normal — the default for most tickets.
- Low — questions, requests, and nice-to-haves.
Write down what lands a ticket in each tier, or the tiers drift and the SLA stops meaning anything.
Pick the right metrics to commit to
Most SLAs commit to two clocks: a first-response target and a resolution target. They behave very differently. First-response time is a leading indicator you control directly through staffing and routing, which makes it the one most worth a tight SLA. Resolution time is a lagging indicator shaped by how hard the underlying problems are, so resolution SLAs should be looser and account for tickets that legitimately need engineering or a customer reply to move. Committing to an aggressive resolution number you don't control is how teams end up gaming the metric instead of helping the customer.
Anchor to business hours
An SLA only means something against a schedule. Tie it to business hours with holidays and time zones, so the clock pauses when the team is off and resumes when it's back. Measuring in raw calendar time punishes the team for nights and weekends nobody staffs, and quietly pressures you into round-the-clock coverage you may not need. Reserve 24/7 calendar clocks for the specific tiers — usually only the top one — where you genuinely staff around the clock.
Use at-risk thresholds
The goal is to act before a breach, not explain one after. An at-risk threshold — say, 80% of the way to the deadline — should trigger a notification or escalation while there is still time to do something. Most breaches are preventable with one well-placed alert to the right person: the owner if the ticket has one, a lead or a channel if it's gone unowned. A breach report tells you what already went wrong; an at-risk alert lets you stop it.
Automate the routing, not just the alert
An alert that fires into a void doesn't help. The SLA is only as good as the automation behind it: rules that set priority on intake, assign the ticket to an owner so the clock has someone attached to it, and escalate on the at-risk threshold. Pair the SLA with round-robin or load-based assignment so urgent tickets land on an available agent immediately rather than waiting to be claimed — see round-robin, collision detection and presence. Cherryrise's automation and SLA engine ties these together: event, conditions, and actions, with business-hours-aware clocks and at-risk escalation built in.
Keep them honest
An SLA you routinely miss trains everyone to ignore it. Set targets you can hit on a normal week, measure first-response time against them, and tighten only when the data supports it. Review breaches for patterns rather than blame — a tier that breaches constantly is usually mis-set, mis-staffed, or mis-routed, not lazy. And don't publish customer-facing commitments you can't back internally; an SLA that lies to customers costs more trust than no SLA at all. For where these numbers fit in the wider picture, start with help desk ticketing 101.
Frequently asked questions
What is an SLA in customer support?
An SLA, or service level agreement, is a committed target for how quickly support will respond to or resolve a ticket. In practice it is usually a first-response target and a resolution target per priority tier, measured against business hours. A good SLA is one the team can hit on a normal week, with an at-risk threshold that escalates before the deadline rather than after.
Should SLAs be measured against business hours or calendar time?
Against business hours, in almost every case. Measuring SLA clocks in calendar time penalizes the team for nights, weekends, and holidays when no one is on shift, and pushes you toward staffing coverage you may not need. Tie the clock to business hours with time zones and holidays so it pauses when the team is off and resumes when it is back. Reserve 24/7 calendar SLAs for tiers where you genuinely staff around the clock.
What is an at-risk SLA threshold?
An at-risk threshold is a point before the SLA deadline — for example 80 percent of the way to it — at which the system notifies or escalates so someone can act while there is still time. The goal is to prevent breaches rather than report them. Most breaches are avoidable with one well-placed alert to the right person.
How many priority tiers should an SLA have?
Usually three or four. Too few tiers force a single global target that either over-promises on routine tickets or under-serves urgent ones; too many tiers become impossible to triage consistently. A common shape is urgent, high, normal, and low, each with its own first-response and resolution targets, with clear rules for what lands a ticket in each.
Cherryrise SLAs are business-hours-aware with at-risk alerts. See the workflow engine.