What is an SLA (service level agreement)?

The acronym “SLA” shows up in IT support contracts, SaaS offers and customer service dashboards. It shapes both perceived quality and the price of a contract. But what is an SLA exactly, what does a service level agreement contain, and how do you run it day to day? Here is the plain, practical explanation, with example deadlines and the pitfalls to avoid.

What is an SLA, exactly?

SLA stands for service level agreement. It is a contractual commitment between a provider and a customer that defines, in writing, the service to be delivered and the performance level expected. In other words, an SLA turns a vague promise (“responsive support”) into measurable targets (“a first reply within 4 business hours”).

You meet SLAs in two main contexts. On the cloud and managed services side, an SLA guarantees, for example, the availability of a server or an application. On the customer service and help desk side, it frames how quickly requests are handled: time to pick up a ticket, time to resolve it, hours covered. In both cases the goal is the same, align both parties’ expectations and make quality verifiable.

What is inside a service level agreement?

A well written SLA is more than a single deadline. It spells out several elements that prevent misunderstandings the day a dispute arises.

• Scope: which services, channels and users the agreement covers.
• Service level indicators: the metrics tracked and their quantified target (deadlines, availability, resolution rate).
• Hours of coverage: the time windows and days the SLA applies, often business hours, sometimes 24/7.
• Measurement method: how and when time is counted, and what pauses the clock (for example, a ticket waiting on the customer).
• Exclusions: cases that are not covered (planned maintenance, force majeure, misuse).
• Penalties and remedies: credits, discounts or enhanced support if the commitment is missed.
• Escalation procedures: who to contact, and through which tiers, when an incident gets worse.

Which metrics does a support SLA track?

An SLA only has value if its indicators are measurable without ambiguity. In customer service, four families of metrics come up most often.

First response time measures the gap between a request arriving and the first reply from an agent. It is the most visible commitment for the customer: it reassures, even if the full resolution takes longer.

Resolution time measures the total time to close a request. It is almost always tied to the ticket’s priority: a blocking outage and a minor question do not share the same target.

Availability (uptime) mainly concerns online services. It is expressed as a percentage, and reading it holds surprises. A 99.9% commitment still allows nearly 8 hours 45 minutes of downtime per year, while 99.99% only tolerates about 53 minutes over the same period. Two seemingly close figures hide very different requirements.

Hours of coverage define when the commitment applies. An “8am to 6pm, Monday to Friday” SLA is not the same as a “24/7” SLA: the second costs more and requires teams working in shifts.

What are the types of SLA?

There are three classic ways to structure a service level agreement, depending on the target.

Many vendors combine these approaches. A tool may offer a service-based SLA shared by everyone, topped up with shorter deadlines reserved for premium plans. The SLA level then becomes part of the pricing grid.

SLA vs SLO, OLA and KPI: what is the difference?

Four acronyms orbit the concept and are often mixed up. Telling them apart clears up many contracts.

• SLA: the contractual agreement, facing the customer, with its targets and penalties.
• SLO (service level objective): the internal target the provider aims for, often stricter than the SLA to keep a safety margin.
• OLA (operational level agreement): an internal agreement between the provider’s teams (support, infrastructure, dev) that ensures the customer SLA can be met.
• KPI: the performance indicators used to measure whether the SLA is met, without being contractual commitments themselves.

The SLA is the promise made to the customer, the SLO the target you set behind the scenes, the OLA the contract between internal teams, and KPIs the way to verify all of it.

To dig into the performance measures that feed an SLA, read our article on customer service KPIs, several of which (response time, resolution rate) map directly onto service level commitments.

How does support software drive SLAs?

Tracking SLAs by hand in a spreadsheet is unworkable as soon as a team handles any volume. That is exactly what a ticketing system or a full help desk manages: it applies automatic SLA policies to every ticket.

In practice, the tool starts a countdown as soon as a request arrives, based on its priority and the customer’s contract. It pauses the clock when the ticket is waiting on the requester, shows a time-remaining indicator and sends an alert before a breach. A dashboard then aggregates the SLA compliance rate over the period, which makes the commitment measurable and verifiable.

Here is an example SLA grid by priority, as you can configure it in most help desks (indicative values, adjust to your own activity):

• Urgent priority: first reply within 1 hour, resolution targeted within 4 business hours.
• High priority: first reply within 4 hours, resolution within 1 business day.
• Normal priority: first reply within 8 hours, resolution within 2 business days.
• Low priority: first reply within 1 day, resolution within 5 business days.

On budget, SLA management is usually included in the mid-tier plans of support software, billed per agent per month, with more advanced rules (per-customer SLAs, multiple calendars) reserved for higher plans, sometimes on a custom quote for large organizations.