SLA agreement

Instead of vague statements such as "technical support works well", an SLA sets clear boundaries: how quickly the provider picks up a ticket, how long it takes to fix a critical outage and what share of time the service must be available (uptime).

An SLA records the agreement between the service provider and the service recipient:

• provider: the IT department, an outsourcing company, a cloud service provider, facilities management;
• recipient: a business unit, a corporate customer, an individual user.

An SLA rarely exists as a standalone legal contract. It is usually an annex to a service contract or an internal policy for service teams. The strength of an SLA lies in its measurability: every parameter can be verified against logs and reports.

Types of SLA

In service management practice, there are three main types of SLA in IT:

1. Service-based SLA. A single agreement for all users of a particular service. For example, an SLA for corporate email: the rules are the same for a manager and for the CEO.
2. Customer-based SLA. An agreement that covers all services provided to a specific customer (or department). For example, a VIP customer gets stricter incident response times than users on the basic plan.
3. Multi-level SLA. A more complex format divided into levels. For example: the corporate level (general rules for all employees), the customer level (additional guarantees for a specific department) and the service level (specific metrics for a business-critical ERP system).

SLA, OLA and UC: what is the difference?

In ITIL (the IT Infrastructure Library), a Service Level Agreement always comes with two other types of agreement. They work together to cover the entire chain of responsibility.

• SLA (Service Level Agreement) — an agreement between IT and the business (or between a provider and a customer). The customer cares only about the end result set out in this document;
• OLA (Operational Level Agreement) — an agreement between teams within the provider's organization. For example, the first line of support must pass a complex incident to the second line within 15 minutes, and the second line must respond within an hour. The customer never sees this document, but without meeting its OLAs the provider cannot meet the SLA;
• UC (Underpinning Contract) — a contract with an external supplier or subcontractor. For example, the SLA guarantees the customer that a server will be available, but the server itself is provided by a data center under a UC. The terms of the UC must be no weaker than those of the SLA.

Why you need an SLA

Introducing a service level agreement solves several critical business problems at once:

1. Managing expectations. An SLA clearly defines what counts as normal and rules out inflated demands.
2. Objective quality assessment. With an SLA, the argument "you work too slowly" becomes constructive: "this month you missed the response time on 15 tickets out of 100".
3. Prioritizing work. Service desk agents know which ticket to tackle first. A server that is down (critical priority under the SLA) gets fixed before a broken printer (low priority).
4. Reducing risk. Penalties set out in the SLA motivate the provider to keep the infrastructure running.

Who uses SLAs?

Historically, the term came from the IT industry (ITIL/ITSM standards), but today a service level agreement is used wherever there is an internal or external service:

• IT and telecoms: cloud providers (server availability guarantees), software developers, technical support teams;
• B2B outsourcing: accounting services, cleaning, security, logistics;
• internal shared services centers: HR administration (how quickly HR must process a leave request), legal support (how many days a lawyer has to review a contract).

SLA structure: what an agreement includes

A well-written document should leave no room for ambiguity. A standard SLA structure includes:

1. Service definition. What exactly is provided? A detailed description of the service (for example, "Workplace support").
2. Service hours. When is the service available? (for example, 24/7, or business days from 9:00 to 18:00).
3. Incident and priority matrix. How requests are classified (from "Critical" to "Low").
4. Target metrics. Specific figures: response time, resolution time, availability percentage.
5. Responsibilities of the parties. What the customer must do (for example, grant access in good time) and what the provider must do.
6. Penalties and incentives. Penalties for missing metrics (usually a percentage of the service fee) and, less often, bonuses for exceeding them.
7. Reporting and review procedure. How often SLA reports are produced and under what conditions the document can be changed.

Key service level metrics

Service quality is controlled using SLA metrics. The most common are:

• response time: the time from when a ticket is submitted to when an agent picks it up (or replies to the customer);
• resolution time: the time from ticket creation to full resolution of the problem;
• MTTR (Mean Time to Recovery/Resolve): the average time to restore service after a failure;
• availability (uptime): the percentage of time the service is fully operational (the famous "nines", for example 99.99%);
• FCR (First Contact Resolution): the share of tickets an agent resolves on first contact, without passing them to other support lines.

How to write an SLA: step by step

You can write an SLA that actually works, rather than gathering dust in a drawer, in five steps.

Step 1. Define your service catalog. Make a complete list of what you do. Do not write "Ensuring IT operations"; write "Corporate email support", "PC repair".

Step 2. Prioritize requests. Describe how a critical incident (the website is down) differs from a service request (someone needs a new mouse).

Step 3. Set realistic metrics. Do not set a 5-minute response time if there is only one engineer on shift. Rely on historical data. Metrics must be measurable and achievable.

Step 4. Agree on responsibilities. Discuss penalties with the business or the customer. They should be proportionate to the cost of the service.

Step 5. Configure the rules in your service desk. An SLA is useless if a person with a stopwatch is tracking it. All metrics should be tracked automatically in your IT system.

How to monitor SLA compliance

Tracking SLA performance manually (in Excel or by email) leads to errors and disputes with the customer. To automate the process, organizations use service desk systems with the Service Level Management (SLM) practice built into their architecture.

In service management systems (for example, SimpleOne ITSM), metrics are monitored automatically:

• configurable indicators. The system does more than start a timer. You define clear conditions for when the clock should start, when it should pause (for example, while waiting for the user to reply) and when it should stop;

• visualization through widgets. Agents do not need to keep deadlines in their heads. A dedicated widget right in the ticket form shows a real-time countdown to the deadline for each target metric (SLO — Service Level Objectives);
• automated actions and escalations. If the response or resolution time approaches a critical threshold (risk of an SLA breach), the system can automatically change the ticket's priority, move it to the top of the queue or notify the shift lead so they can step in;
• a single contract repository. All approved requirements and agreements (SLAs, OLAs, underpinning contracts) are stored in the system and tied to specific services in the service portfolio. This removes disputes: at the end of the month the platform generates transparent reports for each customer based on hard system logs;
• traffic-light balanced scorecards — a SimpleOne platform tool for visual management of KPIs and metrics. It lets you build summary dashboards with color-coded results and quickly spot deviations.

Common SLA implementation mistakes

1. SLA for the sake of an SLA. The agreement is written in dense legal language and filed away, while support works "however it turns out".
2. Unrealistic targets (the watermelon SLA). The provider promised 99.99% uptime and 10-minute incident resolution without the staff or architecture to deliver it. Reports are all "green" (the watermelon's skin), while customers are furious (red on the inside).
3. Metrics disconnected from the business. The SLA covers "server availability" but not "billing availability". The server is up, but customers cannot pay. The business does not care about the server; it needs the service.
4. Forgetting OLAs and UCs. You promised to fix the customer's problem within 2 hours (SLA), but your external vendor's contract only requires it to replace a failed hard drive within 24 hours (UC). You will inevitably miss the deadline.

Summary

What is an SLA? It is a guarantee of predictability in the relationship between customer and provider.

Having an agreed document takes the emotion out of disputes: instead of looking for someone to blame, the parties open the responsibility matrix and look at the numbers. However, an SLA only works together with the right automation tools — without an ITSM system, it is practically impossible to monitor commitments in real time.