Service Level Agreements (SLAs)

Service Level AgreementsService Level Agreements (SLAs) are excellent tools for making performance visible and accountable.

However, SLAs aren’t used as frequently as you’d think. In part, because it takes time and resources to create, then monitor and manage them.

Sometimes SLAs are used incorrectly and become the wrong management tool. For example, working with a Procurement client in an RFP process recently made this clear to me. They’re considering an SLA, which in reality is not an SLA.

If used in its current form, this SLA may actually minimize supplier value, rather than creating a strong supplier relationship for greater value.

In this situation, the SLA is being used as a hammer, as financial recourse against the supplier for under performance. And that makes sense, not paying for service that wasn’t delivered, or not delivered in the agreed manner. But that only works if…if…if the SLA is created correctly. There lies the challenge for business owners and Procurement.

SLAs are more than a punishment. When used wisely, SLAs are tools that validate performance, help manage expectations, and improve communication.

But first, let’s define Service Level Agreement.

What is an SLA?

An SLA is a formal agreement that’s mutually agreed to by the service supplier and the business unit owner (manager for service recipients).

SLAs contain one or more metrics with quantitative outcomes and include management elements for reporting and reviewing.

SLAs began in the late 1980s by telecom companies for their corporate customers.

Now, SLAs are common in outsourcing/off-shoring for IT, data centers, service desks, BPO (Business Process Outsourcing) HRO (Human Resources Outsourcing), etc.

For facility maintenance and services, SLAs are not as frequently used. When facility SLAs are used, it’s often by companies that are highly outsourced and already have an SLA mind set. In these companies, often high-tech firms, SLAs are part of their vendor management toolkit.

Components of an SLA

For an SLA to be useful it needs a lot of up front work, requiring service knowledge (what’s realistic – what’s not) and access to site-specific information (baselines, trends, etc.)

SLAs often have more than one service metric included. To visualize this, imagine a table with the following components as column headings and rows for metrics:

Name of the metric (text data)

The name is a concise text label that easily distinguishes it from another metric within the SLA.

Brief description (text data)

A short sentence that further clarifies what this metric is about.

Target Range (numeric data)

This is the numeric range where performance data is expected to fall – meaning, no punishment in lost fees, or incentive reward is offered for performance in this range.

Owner (text data)

This identifies the party responsible for tracking and reporting outcomes – either the service supplier or the business unit owner.

Reporting Process & Source (text data)

This states the frequency and method with which the performance data is collected and reported.


This is where performance data outside the target range is addressed. It has several sub-components:

Condition (numeric data)

These are multiple numerical ranges for each metric where data is:

1) Below target (failing), such as < 70%

2) Above target (high performance), such as >98%

3) OPTIONAL: Slightly below target, a range above “failing” but “below target” – may trigger a unique workflow (see below)

Workflow (text data)

This is the activity that begins when performance data falls into one of the conditions listed above, such as data below or above target.

Activities can include:

* Alerting service suppliers of non-performance
* Escalating performance up to business owner for urgent review
* Beginning reward for high performance in the next period
* Analyzing service for improvements, obstacles, etc.

Consequence (numeric and/or text data)

This is the contractual action to be carried out based on performance data, and can include:

* Fee reduction (should only be profit portion for services)
* Credit earn back (for high performance)
* Reduction in service levels (re-scope specifications)
* Provide supplier preferred opportunities for additional business

Metric Location

This identifies where in the service contract the mutually agreed SLA exists, such as Janitorial Services contract dated 6/30/09, section 9.2.3.

#1 Not an SLA when outcomes are beyond Suppliers’ Control

SLAs should be for service outcomes that are 100% within the supplier’s control.

Otherwise, suppliers wouldn’t agree to be penalized (lose profit) for outcomes outside their control.

For example, at a facility, security guards are required to search all handbags of employees entering.

But customer satisfaction scores for security may be low reflecting employees dislike of having their bags searched.

In this situation, customer satisfaction wouldn’t be an appropriate metric for an SLA, as the facility policy, not supplier performance, is driving satisfaction down.

#2 Not an SLA when it’s a KPI

Suppliers are paid, and expected to contribute to service outcomes not fully in their control. Here, supplier value is tied to a more complex service system.

For example, day janitors, during the course of their duties, interact with building users. Smiling and holding doors open can greatly contribute to user satisfaction.

This is part of the expected value suppliers provide. But business owners’ can’t make suppliers’ performance the sole driver of satisfaction because of this.

In these situations, Key Performance Indicators (KPIs) are the management tool of choice.

Here supplier performance is tracked and reported using KPIs. By noting trends, improvements and course corrections, business owners bring these aspects of performance into focus and under supplier management.

#3 Not an SLA when it’s dictated

If terms, metrics, targets and consequences are dictated by managers to providers, there’s no “agreement” in SLA.

In this instance, business owners are better off not calling it an SLA, and just calling it service requirements.

Unless service suppliers are involved in SLA development, there will be understandable, built-in causes for conflict and disagreement. Suppliers will always be able to say they didn’t explicitly agree with such and such, or that targets are unrealistic and consequences disproportionate.


Though not KPIs, SLAs are the tool of choice to validate, adjust and reward supplier performance from a contractual standpoint. SLAs come with very specific requirements for their creation, review and management.


In addition to personal experience with SLAs in services, this article drew upon the following resources:

“How to Establish Service Level Agreements” by Naomi Karten

The SLA Toolkit by ITIL (Information Technology Infrastructure Library)

The section “Service Level and Performance Management” of Supplier Relationship Management.

Leave a Reply