If You Don’t Have an SLA, You’re Delivering Bad Service

Seems like everybody’s talking about Service Level Agreements these days. What’s the big deal? Can’t we just deliver good service, and not waste all this time with Service Level Agreements? Not if you want to give good service!

---

Simple Human Nature

Human nature is a funny thing. Remember back to Economics 101 with supply and demand, and all that jazz? One thing I remember very well: human wants are unlimited. Customers always want more. It’s how it works. In economics, it’s counter balanced with limited supply, and the tension in the middle sets the price that the market will tolerate. It’s an agreement, if you will.

It’s no different in delivering IT Services.

Did you ever hear that customers want it all, and they want it all for free? Left to their own devices, customers will always want more than IT is able to deliver. It comes down to this – you will never have satisfied customers until you:

1. Have clarity of what the service is (and is not!)
2. Agree on Service Level Requirements
3. Monitor and Report delivery against requirements

This is the basis of a Service Level Agreement (SLA). Keep reading to find out why you have to have an SLA to have good service.

Clearly Define Services

We all know about assumptions. About how, well, you know, how they’re not good, and breed misunderstandings?

Good service starts with a clear understanding of the service to be delivered. Without clarity, you’re fighting human nature to want more than you can deliver. Start with developing a service description by talking with your customers. What do they need? What are the critical requirements? It’s a great opportunity to see IT Services through their eyes. You might be surprised what you find out.

The goal is to have a straightforward description in plain language. It needn’t be lengthy, but should be easy for both customers and IT to understand. Be on the lookout for unstated assumptions. It’s important to include enough detail where there’s the potential for misunderstandings.

There a bit of an art to this. You don’t want to come to the customer with a blank page, but you also don’t want to come with a jargon-laden document written in legalese.

Agree on Service Level Requirements

Once you have a solid service description, it’s time to reach an agreement on the required performance. An SLA must have measurable targets for service levels.

Some questions to ask when creating requirements:

• If the service meets the stated requirements, will the business needs be met?
• Are there any unstated/assumed requirements?
• Are there circumstances where requirements may be different than stated (i.e. end of month, holiday season)?
• Can the requirements be measured?
• Is the description clear to both the business and IT? (Does it use terms that have different meaning to either?)

With solid service descriptions and agreed service level requirements, you now have a basic SLA!

Monitor and Report

Service metrics are how we know if the service is meeting the agreed-to level of service. Sadly, far too often they are little more than a running history of numbers achieved. Things like:

• Provisioned and delivered 213 new PCs last month
• Service Desk took 2,794 calls
• Average time to create new accounts was 10 business hours (down from 18 last month)

While these are interesting, they do nothing to demonstrate whether services are performing as agreed. What you want instead are metrics that directly address the service requirements in the SLA. Things like:

• Number and percentage of PCs delivered within 3 business days
• Number and percentage of calls answered within 2 minutes wait time

These types of metrics show actual performance compared against established targets (i.e. “less than 3 business days”). They directly address what was spelled out clearly and agreed to in the SLA.

Keep in mind that business requirements change over time. Just because you are meeting established targets doesn’t mean it always will. Don’t hold tight to ‘we’re meeting the SLA,’ as that’s a relationship killer, and a sure way to make very unhappy customers!

Bringing It Together

Here’s a quick example to pull these ideas all together.

The business states that they need 90% of all incidents resolved within 4 business hours.

A service description is created that describes what services are supported, contact information, and hours of operation. Add a service level requirement to have >90% of incidents resolved in 4 business hours, and you have a basic SLA.

Once agreed, service metrics are defined that measure how many incidents are resolved within 4 hours. (It might also be good to show the average resolution time.)

At the monthly customer review, the conversation goes something like this: This month 98% of incidents were resolved within the SLA target, with an average resolution of 3 hours (down from 3.5 hours last month.) Well within target; excellent service!

Unfortunately, the conversation goes on: “But what about the ABC outage? We were down all day on the last day of the month, and it kept us from making our monthly sales goals! I don’t care what your numbers say, you failed us (again).”

The stated goal was achieved. So, why isn’t the customer happy?

Because while most incidents were resolved in target, the most important one – the one that had the highest business impact – did not. The customer assumed we were talking about the important ones, because, to them, it’s just common sense. It never occurred to them that we would average high impact outages along with minor PC problems.

Rather than standing behind ‘we met the SLA,’ which only infuriates the customer, go back and take a closer look. Where are we lacking in clarity? In this case, it’s obvious that some incidents are more important than others. Sound familiar?

By defining and getting agreement for an incident priority process, each incident can be given a priority based on business urgency and impact. Metrics can now report resolution by priority, and we get closer to what the business actually wants: All high priority incidents must be resolved in 4 business hours.

In our example, the resolution rate drops to 50% for high priority incidents. Now we’re not looking so good, but we’re seeing it the way the customer does. We can now start having discussions around what we can do to improve.

Bottom line is that the business sees we understand what they need, and are working to meet it. What’s not to like?

Good SLAs Make Good Service

Without a clear understanding of what the service is, and what level of service is required, you can never make customers completely happy. They will always want more.

To give good service:

• Talk with your customers
• Clearly define what they need in a service description
• Establish and agree to service level requirements
• Measure and report service level performance
• Continually improve services not meeting requirements
• Look for changing service level requirements

You need to leverage human nature. Use SLAs to build clarity with your customers. Customers who know what to expect, and consistently get it are happy customers!

---

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