Here’s a common situation: The client organization that has hired you as an IT consultant has decided to implement a service level agreement (SLA) with its customers. You have a good idea of what needs to be included in an SLA, but are you prepared for the challenges that could derail your SLA?

Let’s review five problems that can get in the way of establishing a good SLA for your client and your client’s customers: lack of organizational readiness, length and language, lack of support, poor customer focus, and unrealistic performance targets.

Second of two parts

The first installment in this series on service level agreements discussed the five things consultants must do to ensure that they have a good service level agreement.

Lack of organizational readiness
One of your first responsibilities as an IT consultant will be determining why your client is interested in developing an SLA. With this information, you’ll establish the scope of the project. Lack of purpose and scope can spawn problems as you begin. For example, will you be responsible for just the SLA or will you be offering advice on the SLM program as well?

How well do you know the organization with which you’re consulting? Are the customers of the IT department satisfied with the level of service they’re currently receiving? If they’re pleased with the performance of IT, developing an SLA with them will be much easier.

The greatest challenge from the organization will most likely come from the IT department. Understanding the corporate culture and the employees’ willingness to change is crucial. Implementing an SLA will drive a real culture change with an emphasis on service. You could be in for an uphill climb if the IT employees aren’t prepared to provide explanations for poor service or make changes to provide better service in the future.


Creating an SLA between IT and its customers is not intended to fix problems between both parties. An SLA can definitely be a vehicle to improve communications, but if the relationship is damaged, writing an SLA isn’t a tool to fix it.

Length and language
Particular components are essential to a good SLA: a description, service standards, duration, roles and responsibilities, and evaluation criteria should all be included. But including the right ingredients is only the first step.

When writing your SLA, it’s easy to think of it as a contract rather than what it really is, an agreement. It may be easy for you to stipulate the terms of the service and want to specify the exclusions and other specifics. But if your client’s customers have trouble reading it or believe that it’s filled with too much legal jargon, they’ll be hard pressed to follow or understand the terms. And if your SLA becomes too long and resembles an encyclopedia, customers and IT will be less likely to refer to it, much less follow the terms specified.


Submitting an agreement to customers that is too short, too long, or full of legalese, will cause everyone frustration.

Lack of support
Lack of support from your service providers—internal and external—will be a difficult obstacle to overcome when building an SLA. When you’re working on the agreement and your client’s customers indicate their requirements, the supporting mechanisms—commonly referred to as operating level agreements (OLAs)—should already be in place.

For example, if the customers require a 15-minute response time for a high-severity incident, the IT organization must have processes in place to support the customer requirement. OLAs may need to be put in place between the organization’s service desk and second-level support personnel that can accommodate the 15-minute response time. Likewise, if the organization is depending on third-party support, contracts must be in place with those vendors to achieve a 15-minute response time to the customers.


By ensuring that OLAs and contracts are in place prior to working on the SLA, as a consultant, you can better advise IT and the customers about what level of service can actually be delivered, based on agreed-upon processes and procedures.

Poor customer focus
It’s easy for most IT service providers to describe deliverables in terms of systems rather than services. Many IT employees see themselves as providing support for things like customer information systems, work management systems, databases, mainframe platforms, Microsoft NT servers, and workstations.

Your job as a consultant will be to help remind IT that the reason they exist is to support the customer.

Take describing an e-mail service as an example. An e-mail service consists of multiple components, including the server application, the client application, the workstation, the LAN, and the server. If any one of those pieces fails, the service is unavailable to the customer. Unless your service offering considers these factors, you may find that the customers are unhappy with the service and the agreement.


Focus on the role of the customer. It is absolutely essential that all of the services described in the SLA have a customer orientation.

Unrealistic performance targets
Performance targets can derail a successful SLA from two sides: the customer and IT. Write the SLA with the customer in mind, and be sure that the targets are specific enough to provide meaningful measurements.

I learned a valuable lesson from one of my customers when we were developing an SLA. I thought I understood his requirements well enough to suggest a performance target that I believed the IT staff could achieve. IT was providing a bill-printing service for the customer. We were going to measure the performance of a “quality bill-printing service.”

Based on my customer’s service needs, I interpreted “quality” to mean on-time. My customer, however, defined “quality” as bills that were clear and crisp. Your SLA should be specific enough that there is no question from IT or the customer about what is being measured.

The SLA must also include targets that IT has the opportunity to achieve. Meeting a 15-minute response time 100 percent of the time is a major accomplishment. After missing the target one time, IT may not try as hard to respond within 15 minutes because that target has already been missed for the reporting period.

Finally, when advising your clients about performance targets, be sure they can measure what they’re committing to. If IT cannot measure a target, doesn’t know how to measure a target, or has no plans to try to measure a target, suggest that it not include that target in the SLA. There’s no way to lose credibility with a customer faster than to fail to deliver what you told them you could provide.


Set measurable, realistic service requirements.

Final thoughts
Developing an SLA is hard work, and you must avoid many pitfalls while drafting the agreement. If you take time to explore all of the customer’s needs and requirements and understand what IT can deliver, designing an SLA can be worry free. Once the agreement is in place, IT and its customers will enjoy an improved relationship with manageable expectations. And both parties will thank you and appreciate your role as the IT consultant.

Common mistakes when developing an SLA

Have you made errors in developing SLAs for clients or been forced to adhere to unrealistic or flawed expectations in an SLA you had to follow? Post your comments below.