SLA Agreement for Customer Service: How to Write One That Holds

An SLA agreement in customer service is a written promise about how fast your team answers and resolves customer requests, on which channels, during which hours, and what happens when a target is missed. The method fits in one line: pick two or three clocks that customers actually feel, set a target for each one per channel and priority, write down when the clocks pause, and review the misses every week. Everything else is detail around those four decisions.

What an SLA agreement covers, and how it differs from a goal

Google's site reliability engineers draw a useful line. A service level objective is a target value for something you measure, while a service level agreement is a contract with your users that includes consequences for meeting or missing those objectives ^[1]. Their quick test is to ask what happens when a target is missed. If nothing happens, you have a goal, not an agreement. For a support team, the consequence may be a credit, an escalation to a manager, or simply a promise you publish and report against.

The call center world adds the parts a customer-facing agreement usually holds. Brad Cleveland's ICMI primer lists the products supported, the services and channels, the response-time objectives, the hours of operation, quality standards and reporting ^[2]. He also separates two kinds of work. Some contacts must be handled when they arrive, like calls and chats. Others can wait in a queue, like email. Each kind needs its own clock.

IT teams that run internal service desks use a separate class of tools for SLAs on incidents and changes. This guide is for businesses answering their own customers.

The customer service metrics your SLA should time

Most support SLAs time three moments in a conversation. Each one answers a different customer worry. Pick the ones your customers would complain about first, and leave the rest as internal reports.

First response time

First response time is the gap between the customer's message and the first real reply from your team. It tells the customer someone has seen the problem. Decide up front whether an automatic acknowledgment counts. It should not, because a robot receipt answers nothing.

Next reply time

This clock restarts each time the customer writes back. It catches the conversation that got a fast first answer and then went quiet for three days. Customers often notice that silence more than a slow start, so time it too.

Resolution time

Resolution time runs from the first message until the problem is solved. It is often the clock customers care about and the hardest to promise, because some fixes depend on a refund, a shipment or another department. Many teams publish response targets and keep resolution as an internal goal.

How to set targets your team can actually keep

A target that looks good on a slide and fails every Monday morning does more harm than no target. Cleveland's primer warns against agreements that are one-sided or leave the calculation undefined. The SRE book adds two lessons: avoid absolutes, and keep as few objectives as possible. Turn that into a short routine:

1. Pull a month of history. Export your inbox or help desk data and note when messages arrive by hour and weekday, and how long replies take today.
2. Split by channel. Chat customers wait minutes; email customers expect hours. One number for both is either too loose for chat or impossible for email.
3. Add priority. An order that has not shipped or a customer who cannot log in gets a shorter clock than a feature question.
4. Set the published target, then a stricter internal one. The internal goal is the alarm; the published one is the promise.
5. Express it as a share, not an absolute. Promise that most requests meet the target, not every single one, and say what share you aim for.
6. Name the owner of a breach. Decide who gets told when a ticket is about to miss, and what they do next.

Then run it for a month before you publish anything. Your real numbers will tell you whether the target was honest. Monday mornings usually carry the weekend backlog, and a single product launch can double the inbox for a week. Plan staffing for those peaks, or write them into the agreement as known exceptions. Cleveland calls this out directly: an agreement should say which events nullify a target. Keep that list short.

A one-page SLA template you can copy

Use the table below as a starting SLA template. The figures are an illustration for an online shop, not a benchmark. Replace them with numbers from your own history.

A worked example

Take a shop that receives an illustrative 400 emails a month and promises a first reply within 4 business hours for 90% of them. That allows 40 late replies a month; the 41st breaks the promise. Hours matter here too. An email that lands at 4:30 p.m. on a Friday has 30 business minutes left that day. The other 3.5 hours run Monday from 9 a.m., so the reply is due at 12:30 p.m. Monday, not 8:30 p.m. Friday.

SLA management: clocks, pauses and escalations

Writing the agreement is the easy half. Running it is harder. SLA management is the daily work of keeping every clock honest. Three questions decide whether your report means anything.

What stops the clock

Define a real response. In Freshdesk's ticketing system, only a reply or a public note counts; a private note never stops the first-response clock. That is the right rule. An internal comment does not help the customer, so it should not count as an answer.

What pauses it

Business hours and holidays pause most support clocks, and waiting on the customer often does too. Be careful with pause statuses. In Zoho Desk's SLA automation, putting a ticket On Hold freezes the SLA timer and stops escalations. Used loosely, that can flatter the report while the customer keeps waiting. Agree on when a ticket may go on hold and check the hold list each week.

What happens before a breach

Escalation should start before the deadline, not after it. A reminder when most of the time has passed gives the owner a chance to reply. A second step can reassign the ticket or raise its priority. Fast first replies often come from good pre-written answers; our guide to canned responses shows how to build them in Gmail and Outlook.

Mistakes that quietly break the promise

• Averages instead of shares. An average hides the long tail. The SRE authors prefer percentiles because a typical case can look fine while a few requests wait far longer.
• One clock for every channel. Chat and email need different targets.
• Counting auto-replies as responses. The report looks perfect; customers still wait.
• No definition of the math. Write down what starts, stops and pauses each clock.
• Targets set from hope. Base them on a month of real data.

Tools that run the SLA clock for you

A spreadsheet can record targets, but it cannot start a timer when an email arrives or warn you an hour before a breach. Help desks do that. Each of the tools below can attach SLA targets to tickets and run the clocks for you. They differ in which plan carries SLA policies and how much control you get. The full comparison, by team size and situation, is in our guide to SLA management tools.

The bottom line

A customer service SLA works when it is narrow, measured and honest. Promise a first response and a next reply per channel and priority, write down the hours and the pauses, express the target as a share of requests, and set a stricter internal alarm. Run it quietly for a month, fix what your data shows, then publish it. When manual tracking starts missing breaches, move the clocks into a help desk so the timing and the warnings happen without anyone watching.