How Can You Create an SLA that Helps to Delight Your Customers?

IT people tend to like technology, and we like things to be clear and unambiguous, with proper facts and figures. In some other areas of expertise people are more comfortable with things that are abstract, less well-defined and harder to measure, but we tend to stick to the facts. This cultural difference can lead to big problems when it comes to negotiating and agreeing on service level agreements (SLAs) with our customers.

We want the content in our SLA to be well-defined and unambiguous. All our books say that metrics should be SMART (specific, measureable, achievable, relevant and time-based), and everyone in IT agrees that SLA targets must be written like this. The trouble is that our customers are often quite bad at defining SMART targets, so we usually have to do it for them. We don’t just ask the customers what they want and write that down, because their ideas aren’t SMART enough, so we go to the customer with a generic SLA and tell them that we can negotiate this number or that number, but we rarely agree to completely change the whole way we write about services. One result of this approach to negotiating SLAs is that customers don’t feel ownership of the SLA, they think of them as “the IT SLAs”.  In many cases customers think that the SLA is there for the IT department to hide behind, reporting numbers that mean little to the business but failing to deliver the services that they really want.

I have seen some truly horrible behaviour from IT departments where they think meeting the SLA is all they are supposed to do.

---

• One IT department had a target that they should close 98% of Priority 1 incidents within 4 hours and 95% of Priority 2 incidents within 8 hours. Towards the end of one quarter an operations manager sent an email to service desk staff saying that the target for Priority 1 incidents would be met, even if the next Priority 1 incident took too long to resolve, but there was a risk that the target for Priority 2 incidents would be missed – so everyone should focus on Priority 2 incidents even if there was a Priority 1 incident open. The customer found out about this and was extremely angry. The IT department met their SLA, but the customer experience was very negative and it took a long time to re-establish trust.
• Another customer was very unhappy because there had been a number of service outages that had had a significant impact on the business, but IT pointed out that the service had met the 99.5% availability target, and didn’t seem interested in addressing the issue.

How can we bridge this gap between what IT can measure and report, and what our business customers really care about? One approach that I have seen used very successfully is to include both what we can measure AND what the customer wants in the SLA. This is how it works:

1. Find out what the customer really wants

Start by asking the customer what they want from the IT service. Let them tell you in their own words and write this down. Get the customer to check that what you have captured really is what they want, and let them reword the statements until they are happy with them. Here are examples of some things that customers might ask you for:

• Downtime of the service should not have a significant impact on the business process
• Data should be protected so that there are no embarrassing security breaches
• When we have a problem it should be fixed quickly
• If we need to change the business process then IT should be agile and not get in the way of the change
• Transactions should be fast enough that they don’t delay staff when they are trying to serve customers
• If there is a disaster then the IT systems should be recovered by the time the rest of the business recovery plan needs them

Once you have a complete list, ask the customer to confirm that if you achieve all this, will they then be delighted with the service. Make sure you really have captured what they want. Most (maybe all) of these things won’t be measureable. Don’t worry about this, we’re going to think about measurement next. You have to start by moving out of your comfort zone to the place where your customer is, before you ask the customer to move a little bit towards where you are.

2. Think about what you can actually measure

Take each of the customer statements and think about what you could measure that would be relevant to this. Accept that you can’t actually measure the thing the customer really wants; this doesn’t mean that you can’t make a relevant measurement. There is a great book by Douglas W. Hubbard called How to Measure Anything: Finding the Value of Intangibles in Business, which explains that a measurement is any observation that reduces your uncertainty. Hubbard shows how you can measure anything you need to, and you can measure it to any level of accuracy you want if you are prepared to invest enough effort.

Taking some of the examples above, here are some relevant measurements you could make:

• When we have a problem it should be fixed quickly
  • Priority 1 problems will be resolved within 1 hour
  • Priority 2 problems will be resolved within 8 hours
  • etc.
• If we need to change the business process then IT should be agile and not get in the way of the change
  • Initial assessment of any change request will be complete within 24 hours
  • Minor changes will be implemented within two weeks of the change being approved
  • A plan for implementation of major changes will be available within four weeks of the change being approved
• Transactions should be fast enough that they don’t delay staff when they are trying to serve customers
  • 99% of logins will complete within 10 seconds
  • 99% of sales transactions will complete within 20 seconds
  • 100% of sales transactions will complete within 40 seconds
  • etc.

3. Discuss the measurements with your customer

Explain to the customer that you are going to measure and report these numbers, and ask if they agree that achieving the numerical targets will tend to indicate that you have achieved the real customer target. Make sure they understand that the numbers are NOT the real target, they are just what you will measure.

The customer may suggest some other things you could measure, or they may want to change the numbers. This is fine, you are now working in your space, negotiating numerical targets with the customer.

4. Make regular measurements and discuss achievements with customers

You can now measure your agreed numerical targets and capture the results in regular customer reports. Don’t make the mistake of thinking that achieving the numerical targets proves that you have delivered what the customer wants. When you hold your customer meeting you should be making statements like:

“The SLA target says ‘Transactions should be fast enough that they don’t delay staff when they are trying to serve customers’, and the figures we measured this month show that 99.5% of logins completed within 10 seconds and 100% of sales transactions completed within 20 seconds. Are you happy with this?”

You can also use the numerical measures to show trends, to help the customer understand whether you are improving the service.

Note that you haven’t told the customer that they are happy, or that the measurements prove that the target was achieved. What you have done is reported the numbers and asked the customer if they are happy. They can now respond to this by confirming that they are happy, or by explaining why these measurements aren’t quite right. Maybe they will say that some logins took 3 or 4 minutes and this was a big problem, so you can now add another measurement to capture a new numerical target of “100% of logins complete within 30 seconds”.

Summary

The whole point of this approach is that you are measuring and reporting things that you can control and understand, but that you are framing your reports in language that the customer cares about. Remember that you should NEVER tell the customer that the numbers mean they are happy. The numbers are simply an indication that you can use to show trends, and to help the customer express what they want in terms you can understand.

What kind of language and measurements do you have in your SLAs? Are you brave enough to step outside your comfort zone and start writing SLAs in customer language?

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.