A customer support SLA is a written commitment on the maximum time a team takes to reply to and resolve each client request, depending on its priority. It is measured ticket by ticket with two clocks, time to first response and time to resolution, usually in business hours. The figure that sums it all up is the share of requests handled within the deadline.
In technical support, software and IT, engineering firms and agencies, the question clients ask most often is "when will this be sorted?". Without an SLA, the answer depends on who opened the email and how busy their week is. With an SLA that is actually measured, the team knows what it has promised and the client knows what to expect.
What is a customer support SLA?
SLA stands for service level agreement. In customer support, it is the rule that sets how quickly each request gets a reply and how quickly it is resolved. An SLA can sit in the contract with the client, with consequences when it is missed, or be an internal commitment the team makes to itself. Either way, it is only useful if it is written down and measured.
A ticket with an SLA is a request recorded with its arrival time, a priority and the deadlines that follow from both. A complete SLA answers five questions.
- Who it covers. Which clients, which contracts and which types of request.
- When the clock runs. Service hours, working days and public holidays.
- Which priorities exist. Three or four levels, with criteria that do not depend on whoever does the triage.
- Which deadlines apply. One for the first response and one for resolution, for each priority.
- What happens when time runs short. Who gets warned and who the request is escalated to.
Which times are measured on a ticket?
Measuring an SLA does not take dozens of indicators. In a small team, five figures are enough to know whether the commitment is being kept.
| Metric | What it shows | How it is calculated |
|---|---|---|
| First response time | How long the client waits for a person to reply | From the moment the request arrives to the first reply written by someone on the team |
| Resolution time | How long the problem stays unsolved | From arrival to the moment the request is resolved, excluding agreed pauses |
| SLA compliance | Whether the team keeps its promise | Requests within the deadline divided by all requests in the period, by priority |
| Open requests | Whether work is piling up | Tickets still open and how long each one has been waiting |
| Satisfaction (CSAT) | How the client rated the service | Share of positive answers to a short survey sent when the ticket closes |
Reopened tickets, the ones a client opens again after they were closed, are also worth counting. An SLA that is met alongside many reopened tickets usually means requests are being closed too quickly.
How do you set realistic deadlines by priority?
The most common mistake is copying the targets of a shift-based support centre into a team that also has projects to deliver. The right deadlines come from the team's own starting point.
- Measure for four weeks, without targets. Log every request as a ticket and see how long the first response and the resolution take today.
- Define priorities by impact on the client. For instance, critical when the client's service is down, high when it works with limitations, normal for questions and small changes, low for suggestions.
- Set the deadlines for each priority. Slightly better than the measured reality, so they are demanding without being impossible.
- Write down the service hours. For example, working days from 9am to 6pm, excluding public holidays. A request that arrives at 5.30pm on a Friday with a deadline of four business hours is due at 12.30pm on Monday.
- Decide when the clock stops. The usual choice is to pause it while the request is waiting for information from the client.
- Agree on warnings and escalation. Who is alerted when the deadline is close and who decides once it has passed.
The table below is only an example, for a technical support team. Each company's figures depend on its contracts and the people available.
| Priority | Example request | First response | Resolution |
|---|---|---|---|
| Critical | The client's service is down | 1 business hour | 8 business hours |
| High | Works, but with a fault affecting the client's team | 4 business hours | 2 working days |
| Normal | Question or small change | 1 working day | 5 working days |
| Low | Suggestion or improvement | 2 working days | Planned with the client |
Which mistakes make an SLA useless?
- Counting the auto-reply as the first response. The acknowledgement tells the client the request has arrived, but nobody has looked at it yet.
- Closing tickets to hit the deadline. A request closed before it is resolved comes back a few days later.
- Using one deadline for everything. A suggestion and a service outage cannot run on the same clock.
- Counting calendar hours when the team only works on weekdays. The SLA then fails every weekend without anyone doing anything wrong.
- Looking only at the average. One request forgotten for weeks drags the average up, while the median shows how the rest are really going.
- Measuring by hand. When the times come from a spreadsheet filled in at the end of the month, nobody knows any more when each request actually arrived.
A practical example in a technical support company
Imagine a technical support company with six technicians and around 40 clients on maintenance contracts, receiving close to 120 requests a month in a shared inbox. Every request seems urgent, and the contract promises a "quick response" without saying how quick.
For four weeks, the company logs every request as a ticket, still without targets. In this example, the figures reveal three things. The median first response is three business hours, which looks fine. Yet one in five critical requests waited more than a day, because it landed in the inbox of a technician who was out on a job. And almost half of the open tickets are in fact waiting for a reply from the client.
With this data, the company defines four priorities, sets deadlines like those in the table above and pauses the clock whenever a request is waiting on the client. Triage rotates weekly between team members, and critical requests now alert the person responsible before the deadline expires. At the end of each month, the team meeting reviews three figures, compliance by priority, the age of open requests and reopened tickets.
What changes in this example is not the amount of work. Critical requests no longer depend on who happens to receive them, and the contract now states in hours what it used to state in adjectives.
How Engi360 handles requests with an SLA
Engi360 is the Engibots operations management platform for teams that bill hours or run projects for clients. Client tickets are one of its base modules, alongside hours, leave and absences, and projects and tasks.
- Tickets with SLA. Each request becomes a ticket with a deadline, which the client follows and replies to on a protected page, with no account needed.
- From request to work. Requests that lead to work become tasks with a deadline, and hours are logged by task on the same platform.
- Satisfaction at closure. An automatic CSAT rule sends the client a satisfaction survey when the ticket closes.
- Rules and dashboards. Rule-based automation of the kind when X, if Y, then Z, configurable dashboards and an AI assistant that reads the operation.
The free plan includes client tickets, with up to 10 open at a time, the whole team for the first 14 days and then up to 3 users, with no credit card. Automations and CSAT are included from the Professional plan upwards. When client requests live in one tool and hours in another, our article on centralised operations management looks at the real cost of scattered tools and how to prepare the move to a single platform.
Frequently asked questions
What does SLA mean in customer support?
SLA stands for service level agreement. In customer support, it sets the maximum time to reply to and resolve each request, depending on its priority.
What is the difference between first response time and resolution time?
First response time runs from the moment a request arrives until a person on the team first replies. Resolution time runs from arrival until the request is resolved. An SLA usually sets a deadline for each.
Does an automatic reply count as the first response?
It should not. An automatic acknowledgement tells the client the request has arrived, but nobody has handled it yet. The first response is the one written by a person who has looked at the request.
Does the SLA clock run at night and at weekends?
Only if the SLA says so. Deadlines are commonly counted in business hours only, within service hours and excluding public holidays, and the clock usually stops while the request is waiting for a reply from the client.
How is SLA compliance calculated?
It is the number of requests handled within the deadline divided by the total number of requests in the period, multiplied by 100. It is best calculated by priority, because an overall figure hides late critical requests.
Does the Engi360 free plan include client tickets?
Yes. Client tickets are one of the base modules in the free plan, with up to 10 open tickets, the whole team for the first 14 days and then up to 3 users. Automatic CSAT and automations are included from the Professional plan upwards.