Service Level Agreements: A Whistle-Stop Tour

A service level agreement, commonly known as an SLA, is an agreement that outlines the expectations of both sides in a service provider-customer relationship. Importantly for service providers, it’s one of the most effective ways to manage customer expectations and, in turn, your relationship with the customer.

Yet it’s not uncommon for IT professionals not to use them within their IT organization as they don’t know they exist, how valuable they are, and above all else how to create and use them.

So let me take you on a whistle-stop tour of SLAs to help you to better understand what they are and to realize their value to you as an IT service management (ITSM) professional. Then I’ll finish up by sharing some quick tips that will help to make them a reality in your business.

So What’s an SLA?

An SLA outlines what is, and isn’t, included in the provision of an IT service – for both the service provider and the customer. For example, you could have an SLA for a particular IT service that includes the targets, or obligations, for service availability, response time, or even the first contact resolution (FCR) fix rate. The SLA should work at both a qualitative and quantitative level and should outline what both parties are committed to and should expect over the duration of the service lifespan. Importantly, the SLA should set a realistic expectation of how the service will be delivered for all parties involved.

It’s also important to remember that although SLAs are high level descriptions of the expectations and services that will be provided, they are NOT contracts. Contracts, if needed, can be handled separately with the required level of legalese. Instead SLAs should be written in simple, easy to understand language that all involved parties (including stakeholders) are able to comprehend.

Why Do You Need to Use SLAs?

Now that you know what an SLA is, you still might be wondering why you’d want to introduce yet another activity into your already jam-packed ITSM ecosystem. However, the reason is pretty simple – transparency.

Not only do SLAs ensure that both parties feel equally represented in an agreement that outlines the services that will be provided by the service provider, and that both of their sets of requirements will be met and catered for by the agreement, SLAs also act as a reference point for any disagreements which could arise in the future.

It’s important to remember that this SLA capability works both ways – it’s not only for the customer receiving the service but also the service provider delivering it when the customer is not fulfilling their obligations. Of course, it might be that the service contract is failing because the service provider has promised standards higher than they can actually meet. Perhaps due to pressure from the customer or senior executives. The result of course, is that the service provider is setting itself up to fail from the outset, as they don’t have the necessary resources to effectively deliver the service as promised.

So ideally an SLA allows the service provider to set realistic and achievable targets for its service or services, and thus ensure that all customer expectations are managed from the outset.

What Happens if SLA Targets Are Not Met?

There are two schools of thought here: (1) the adversarial school where SLA failures are met with financial penalties, and (2) the partnership school where leeway is given and both parties work together to improve performance against the SLA (which might mean lowering targets even if only for the short term).

While SLA targets should ideally be met, the SLA document itself should not be concerned with the contractual outcomes of failing to meet those targets. Instead, the SLA document should be something that all parties should be able to use, with everyone familiar with what’s important, and the contract can be used to cover particular outcomes that deviate from the SLA targets.

This is important, as overly penalizing the service provider for failing to meet SLA targets encourages lower targets and thus potentially lower performance. If faced with highly punitive penalties, wouldn’t most service providers feel incentivized to offer and/or push for low service standards in the SLA? I know I would!

How to Create an SLA

While the SLA structure and content is entirely up to the service provider and their customers, an SLA will usually, as a minimum, contain five key sections:

1. A description of the service or services
2. A quantitative and qualitative description of the expected service standards
3. The duration of the agreement
4. The roles and responsibilities of each party involved in the agreement
5. Evaluation criteria and key success metrics

Of course, you may have received or even written SLAs with far more detail than this. So feel free to expand on these five sections but always remember that SLAs should be written as a joint discussion between the service provider and service receiver. And be written in simple, easy to understand language. For example:

Wrong: Supplier responsibilities
Provision and maintenance of 1000 network-enabled Xerox 4000 PR16-879723 printers.

Right: Supplier responsibilities
We’ll provide a managed color printer service across 1000 locations.

Wrong: Client responsibilities
The client will not tamper, adjust, or share the IP address for the 1000 Xerox 4000 PR16-879723 printers.

Right: Client responsibilities
The client will use the supplier-provided IT system securely and as intended.

If created in a collaborative way, SLAs will evolve and develop throughout the two-way discussion and that’s okay. As long as the final document makes each party feel comfortable that their needs will be met by the agreement, you’re on the right track.

Making Sure an SLA Is Fit for Purpose… and Is Purposefully Used

While there many predefined SLA templates available out there on the Internet, it’s important that you take the time to build each SLA to match your own use-case scenario requirements. For example, the marketing team’s requirements might not be the same as the sales team’s requirements, and perhaps in this case you would need separate language for each team in the “Roles and Responsibilities” section. What’s more, your organization might put more of an emphasis on different success or evaluation metrics than another organization, leading to a poor use-case fit and a poorly-defined SLA.

Above all else, once an SLA is in place, please make sure it’s well circulated and not stuffed in a drawer somewhere – as not only can you use it to manage the expectations of your customers, but also of your team. It’s a visual representation of your commitment to your customer and a way to hold yourself and your team accountable to that customer.

Short On Time? Here are Three Key Points to Take Away

1. An SLA should make both parties feel happy about the service relationship.
2. An SLA should describe the relationship at a high level and allow all involved individuals to understand and engage with the document.
3. An SLA should contain both qualitative and quantitative targets and success metrics, but should avoid discussing penalties for failing to meet these.

Image credit