How to Negotiate a Service Level Agreement

Why do I need to document my SLAs?

If you haven’t documented your SLAs because you’re worried about putting expectations in writing, I beg you to reconsider.

Whether your SLAs are documented or not, customers will always have expectations around the services you provide. That will never go away. The thing is this: if you don’t have a documented SLA, the expectation will inevitably become “everything all the time for free.” And when that impossible level of service isn’t met, your team will be seen as a frequent source of frustration to your customers.

Documented SLAs also help IT staff understand which incidents, problems, and requests to resolve first, and allow IT leadership and customers have productive, data-driven discussions around where to spend money. Not every IT service can be available 24/7 (there’s a lot of cost to that), so having a discussion around SLAs can help the organization spend its money on the most important services.

So, if you’re thoroughly convinced it’s time to improve your existing SLAs or start a few new ones from scratch, read on. Here are three steps to help get you started, and a few tips for avoiding pitfalls down the line.

Get Service Level Requirements from your Client

The first step in writing an SLA is talking to your customer and gathering their requirements. ITIL calls this Service Level Requirements. Do not revise or create SLAs without involving your customer, period. If you fail to consult them, I promise you will always miss the mark. Here’s an example:

A customer of mine was designing a new IT service for their finance department. They assumed the new service needed to be available 24/7 and architected it accordingly. It wasn’t until they had a conversation with their customer that they found out the finance department had back-up, manual processes they could rely on for up to THREE DAYS. This revelation saved the company tens of thousands of dollars.

ProTip: If your customers have never been involved in creating SLAs with IT, help them out. Bring an SLA template with some basic options to the discussion.  Otherwise, they won’t know where to start or truly understand the cost implications behind what they are asking for. If you have historical information/benchmark data from other customers or some common packages and cost information, that can be really helpful during the discussion.

Make sure IT can deliver to the Service Level Target

Gathering requirements from your customer does not mean you take whatever they say as gospel and write it all up without consulting IT. Never, ever agree to an SLA with customers before checking with IT to confirm what’s being requested is reasonable. Everything has a cost, and you don’t want to get into a situation where you are over promising and under delivering. The goal of Service Level Management is to make sure you have agreed, ACHIEVABLE targets in place.

This is a negotiation! The Service Level Manager should be going back and forth from the customer to IT until the requirements and target match. And that, friends, is when you have a Service Level Agreement!

Make SLAs measurable and easy to understand

Do not put anything that cannot be measured in an SLA. Claiming a service will be “fast” or “great” isn’t going to do the trick here. How exactly do you measure “great”? Stick with specific timeframes for ticket resolution, availability, etc. – you’re looking for anything that can be referenced and clearly reported upon.

Second, unless this is a legally binding contract with another legal entity, make your SLAs easy to read and understand. Keep the ‘shalls’ and ‘shalts’ out of it, along with any other legalese. It should be perfectly clear to the non-IT reader.

Continual Service Improvement (CSI) through the Service Review

Even the clearest, reader-friendliest SLA in the world is meaningless if it isn’t current, though. Be sure to update them annually at a minimum. It doesn’t make sense to work toward meeting an SLA from, say, five years ago. Undoubtedly your organization’s needs – and those of your customers – have changed significantly in that time. The Service Review meeting is a great forum for this.

Ideally, you should be holding a Service Review meeting with your customers at least quarterly.  In it, you’ll see how you are keeping up with your Services and customer’s needs – and if you’re meeting your SLAs. If you keep up with these quarterly meetings, the reviews and revisions of your SLAs should occur more or less automatically (which may get you out of that annual review meeting).

If you don’t have a regular Service Review meeting with your customer, you’ll need to keep (or schedule) that annual meeting to review your SLAs. Customers’ needs change over time and it’s our job to keep up with them, so don’t let the reviews get away from you.

Additional Tools: The SLAM and the SIP

The best and easiest tool to use when talking through SLAs with your customers is called a SLAM chart. That’s a Service Level Agreement Monitoring Chart.  It’s a simple Stoplight chart that provides a helpful visual showing which SLAs you have met, which may be close to breaching, and which (if any) have been breached.

If one of your Services does breach an SLA, you should put a Service Improvement Plan (SIP) in place. A SIP is a formal plan to implement improvements to a process or IT service. It will feed into your Continual Service Improvement Process to hopefully prevent future breaches.