What is a customer support SLA? Examples for small businesses

Most support SLAs fail for the same two reasons: they promise a fast first reply and nothing else, and nobody agrees on when the clock runs. This is what belongs in one, example targets you can start from, and the rules that decide whether you hit them.

What does SLA mean in customer service?

SLA stands for service level agreement. In customer support it's a written promise covering three things: what you'll respond to, how quickly, and what happens when you miss. The third part is what separates an SLA from a wish. A target with no consequence and no report attached is a marketing line.

Internally, an SLA does something more useful than reassure customers: it decides what gets worked on first when everything arrives at once. That's really what you're buying when you write one.

What goes into a customer support SLA

• Scope — which channels are covered (email, chat, phone), and which aren't.
• Hours and time zone — "9am–5pm AEST, business days" is a very different promise from 24/7. Say which, explicitly.
• Priority levels — with definitions, not adjectives. See below.
• First response time — how long until a human replies.
• Resolution or update targets — either when it will be fixed, or how often you'll report progress until it is.
• How the clock is measured — when it starts, when it pauses, what counts as a response.
• Exclusions — third-party outages, customer delays, scheduled maintenance, feature requests.
• Reporting — what's measured, how often it's shared, by whom.
• What happens on a miss — escalation to a named person, a review, or a service credit.
• Review date — targets set before you had real volume will be wrong. Agree when you'll revisit them.

SLA priority level definitions

Priority is the part that gets fudged most often, usually because it's set by how loudly the customer asks. A workable definition combines impact (how many people are affected) with urgency (whether there's a way around it).

Customer service SLA examples

Start from these and adjust to your volume and hours. They assume business-hours cover; 24/7 targets look similar but cost far more to staff, for reasons covered in what outsourced support costs.

These are illustrative, not industry benchmarks. Set your own from your real numbers, not from a table on the internet. And note that this table alone isn't enough, because a customer waiting in a chat window has nothing like the patience of one who sent an email.

First response times by channel

Priority decides what you work on first. Channel decides how long the customer is willing to wait. Someone in a live chat is sitting there watching a cursor; someone who emailed has gone back to work. Treating both as "one hour" will fail the first and over-serve the second.

The split is between synchronous channels, where the customer is present and waiting, and asynchronous ones, where they aren't. Set first response by channel, and keep resolution on the priority table above.

All of these apply during your stated hours of operation only. Outside them, say plainly what happens: typically the clock starts when you open, with a defined on-call route for P1. "Under 5 minutes" written without that qualifier is a promise to answer chat at 2am.

Two things worth deciding alongside the table:

• Turn channels off rather than miss them. If nobody can watch chat all day, set it to appear only during the hours you can staff, or replace it with a form. An unanswered chat widget does more damage than no chat widget.
• Resolution belongs to priority, not to channel. A critical bug reported by phone isn't fixed faster than the same bug reported by email. Channel sets how quickly someone answers; priority sets how quickly it's fixed.

How SLA response time is calculated

Two teams can report wildly different numbers from identical work, purely because of clock rules. Agree these in writing:

• When it starts. Usually when the ticket arrives — but if you promise business hours, a message at 11pm starts the clock at opening time, not at 11pm.
• What counts as a response. A human reply that moves things forward. An automated "we've received your request" shouldn't count, though plenty of teams quietly let it.
• When it pauses. While you're waiting on the customer, almost always. Without a pause rule, every slow-replying customer looks like your failure.
• Business hours versus calendar hours. Four business hours on a Friday afternoon is Monday morning. Make sure both sides read it the same way.
• Which percentile you report. "90% of P2 tickets answered within 4 hours" is honest. An average quietly hides every disaster, which is the same trap as leaning on Average Handle Time.

Common SLA mistakes

• Measuring first response only. A fast reply that solves nothing meets the SLA and still fails the customer. Pair it with resolution or update targets.
• Priority by volume of shouting. Without written definitions, the loudest customer becomes P1 and real P1s wait.
• Promising 24/7 without the people. A week has 168 hours. At 40 hours each, round-the-clock cover for one seat needs 4.2 people before holidays or sickness — the arithmetic behind build versus outsource.
• No pause rule, so your numbers measure your customers' response time as much as your own.
• Targets nobody reports. If it isn't in a monthly report, it isn't an SLA.
• Setting it once. Volume doubles, the team doesn't, and the targets quietly become fiction. Review quarterly.

How to set targets you can actually hit

1. Measure what you do today. Pull your last three months and find the time within which you answer 90% of tickets. That's your real starting point.
2. Ask what customers actually need. Faster is not always better — a trustworthy "tomorrow" beats an optimistic "within the hour" that slips.
3. Set the first target just inside what you already do, then tighten it once it holds for a quarter. A promise you keep is worth more than an ambitious one you miss.
4. Check the staffing maths. Peak hour volume, not average, decides whether a target is reachable. This is often the point at which teams realise they've outgrown their support setup.
5. Publish it, then report on it. Monthly, in plain language, including the misses.

SLA, SLO and KPI — the short version

An SLA is the promise you make externally, with consequences attached. An SLO is the internal target you run to, usually stricter, so you notice trouble before the customer does. A KPI is any number you track, with no promise attached. Small teams rarely need all three; start with an SLA you can keep and an internal target slightly tighter than it.

If a provider is answering your tickets

Hold an outsourced team to the same document, and read theirs carefully: check which hours are covered, whether resolution appears at all, how the clock pauses, and what actually happens on a miss. Those questions are part of choosing a support provider, and a vague answer there tells you plenty.