SLA for customer support: how to write a policy your team can keep

What an SLA for customer support covers

In support, an SLA (service level agreement) is a set of time targets attached to tickets. It usually has two parts.

The external promise is what you tell customers, often in a contract or on your pricing page, such as "first reply within 4 business hours on Business plans".

The internal policy is how your help desk enforces it: which tickets get which targets, when the clock runs, when it stops, who gets warned and who gets pulled in.

The internal policy should be stricter than the external promise. If you promise 4 hours, aim for 2 internally, so a busy morning does not turn into a breach.

Some teams call the internal version an OLA (operational level agreement). The name matters less than having both levels written down.

The two targets that matter: first response and resolution

First response time

First response time is the time from when a ticket arrives until a person (or an approved AI answer) sends the first public reply.

Automatic acknowledgements ("we got your message") do not count. The customer knows they are not an answer, and so does your team.

First response is the target customers feel most. A quick, useful first reply buys patience for the rest of the ticket.

Resolution time

Resolution time is the time from arrival until the ticket is solved. It is harder to control because it depends on the problem, on other teams, and on the customer replying.

Many teams set resolution targets only for high and urgent priorities, and track resolution for the rest without a formal target. That is a reasonable way to start.

Next reply time (optional)

Some teams also set a target for every reply after the first. It stops tickets from getting one quick answer and then going quiet for days. Add it once first response is under control.

Step 1: define priorities people can apply consistently

An SLA is only as good as the priority attached to each ticket. If agents disagree on what "high" means, the targets mean nothing.

Write a one-line definition for each level, based on impact and urgency:

• Urgent: the product or a critical function is down for a customer, or money or data is at risk right now.
• High: a major feature is broken for a customer with no workaround.
• Normal: a problem with a workaround, or a question that blocks some work.
• Low: general questions, feedback, feature requests.

Then decide who sets priority. Options are the customer (via a form field), a rule (keywords, customer tier, channel), an AI classifier, or the agent at triage. Most teams combine a rule or classifier with the agent's right to change it.

Watch for priority inflation. If customers pick their own priority, some will always pick urgent. Let the team correct it and track how often that happens.

Step 2: set targets by priority

Here is a starting point many support teams can adapt. It assumes business-hours support on weekdays, with urgent tickets handled around the clock by an on-call person.

These numbers are not a benchmark. They are a first draft for you to test against your own history and staffing, then tighten or loosen.

To check whether a draft is realistic, pull the last three months of tickets and look at what share of each priority already meets it. If only half your high tickets get a reply within 4 business hours today, a 4-hour promise needs more staff, better routing or automation first.

Different targets per customer tier

Many B2B teams set tighter targets for customers on higher plans or enterprise contracts. A clean way to do it is a separate policy per tier, each with its own table, rather than one giant table with exceptions.

Keep the number of tiers small. Two or three policies are manageable. Ten policies means nobody remembers which applies.

Step 3: define business hours, holidays and time zones

A target of "4 business hours" only makes sense if everyone knows which hours count.

Write down:

• Working days and hours, for example Monday to Friday, 08:00 to 18:00.
• The time zone the clock uses. For a team spread across regions, choose the time zone of the customer's region or run separate schedules per team.
• Public holidays the clock skips, per region if you support several.
• Whether urgent tickets follow a 24/7 schedule instead.

A worked example: a normal ticket arrives Friday at 17:00 with an 8 business hour first response target and hours of 08:00 to 18:00. One business hour passes on Friday. The clock picks up on Monday at 08:00 and the target falls at 15:00 Monday.

Customers do not always think in business hours. Say so plainly in your public SLA, including your hours and time zone.

Step 4: decide when the clock pauses

Clocks should stop when the delay is not your team's doing. Common pause rules:

• Pending on customer: you asked a question and are waiting for the answer. The resolution clock pauses and restarts when they reply.
• On hold for a third party: a carrier, a payment provider or a vendor must act. Some teams pause, others keep the clock running because the customer still waits. Decide deliberately and document it.
• Waiting on internal engineering: usually the clock should keep running. Pausing here hides real delays from your reports.

Pausing must not become a hiding place. Report how long tickets spend pending, and set a rule that sends a reminder after a few days and solves the ticket after a follow-up if the customer never replies.

First response clocks normally do not pause at all. Until you have replied once, there is nothing to wait for.

Step 5: warn before a breach, not after

A breach report on Monday about tickets missed on Friday does not help the customer who waited. What helps is a warning while there is still time.

Set warnings at a fixed share of the target, for example when 75 percent of the time has passed. For a 4-hour target, the warning fires at 3 hours.

Show the warning where agents already look: sort the queue by time to breach, highlight tickets close to the limit, and send a notification to the assignee.

If a ticket has no assignee when the warning fires, send it to the team lead. Unassigned tickets are the most common source of breaches.

Step 6: write the escalation path

Escalation answers one question: when a target is at risk, who acts?

A simple path most teams can run:

• At the warning point, notify the assignee.
• At breach, notify the team lead and move the ticket to the top of the queue.
• If an urgent ticket breaches, notify the support manager and, for outages, the on-call engineer.
• If a customer on an enterprise contract breaches twice in a month, flag it for the account owner.

Keep escalations about attention, not blame. The goal is that the right person sees the ticket in time.

Step 7: measure and review

Track SLA attainment per priority and per policy: the share of tickets where the target was met. Look at both first response and resolution.

Review once a month with three questions:

• Which priority misses most, and at what time of day or week?
• Are breaches caused by volume, by routing (tickets sitting in the wrong queue) or by dependencies on other teams?
• Is the target itself wrong? If you meet it every time with no effort, it may be too loose. If you miss it constantly despite effort, it may need resources before it becomes a promise.

Change targets deliberately and tell the team why. Moving the goalposts silently breaks trust in the whole system.

Common SLA mistakes

• Promising externally what you only just meet internally, with no buffer.
• Counting an automatic acknowledgement as a first response.
• Using calendar hours in reports while promising business hours to customers, or the reverse.
• Pausing the clock for internal waits, so reports look green while customers wait.
• Having no owner for unassigned tickets, which breach first.
• Writing ten policies before one works.