Building Service Level Agreement - 5 Points
A service level agreement (SLA) is a key component of an IT organization’s overall service level management (SLM) strategy. A good SLA functions as a communication vehicle for you and your customer(s) to manage each other’s expectations. By definition, an SLA is an agreement—not a contract. Whether you work with an IT department that is performing services for internal customers, such as a human resources department, or you’re a consultant who offers IT services to clients, your SLA should be a clear outline for those receiving services and those who are providing them.
SLAs can come in several varieties. An Enterprise SLA is an agreement between the service provider and all customers of an entire organization. A Customer SLA is an agreement between the service provider and a specific customer group of the organization. A Service SLA is an agreement between the service provider and the customers of a particular service.
Reasons that you, as an IT consultant, might advocate developing an SLA with customers include:
- A newly implemented SLM strategy by the IT organization.
- A new technology or product is going “live” from development or test stage.
- Customer concerns regarding the delivery of IT services.
- Customer desire to choose how much service they want IT to provide.
Regardless of the type of SLA you’re creating, you should include five sections: descriptions of service, service standards, duration, roles and responsibilities, and evaluation criteria.
First of two parts
In the next installment of this two-part series on SLAs, we’ll look at the five things that can derail a good service level agreement and how to correct them.
Descriptions of service
At the heart of your SLA are the services you provide. Writing specific descriptions of your services requires you to understand what you can offer your customers and affirms to your customers that you know what they need.
Service providers will often create a service catalog to make describing what they offer to their clients easier. The catalog should contain all of the services you provide, including applications, infrastructure, and other business functions.
Those of you who have not yet created a service catalog may find that the best way to begin gathering information for your catalog may be by talking with your customers—who know what systems they’re using—and your customer’s service desk, which knows what services your customers most frequently request.
One of my challenges as the SLM coordinator for my organization was explaining to my customers the relationship of the service catalog to the SLA. Since the service catalog is a separate document from your SLA, it’s important that you make them both accessible—your company’s intranet is a great place for your customers to view them.
Once you have established the services that you’re providing, you’ll be ready to consider your standards, which would include concepts like availability and reliability as well as response and resolution times.
For example, availability should be defined within agreed-upon targets. If your customer’s normal business hours are from 7:00 A.M. to 6:00 P.M., it may be appropriate for the services you provide to support their business processes to be available during the same time.
Each of the services you provide will also have regular operating hours and scheduled time for maintenance. This information needs to be illustrated in your SLA.
You’ll also need to determine what you can offer to your customers if a disaster or emergency happens. Will you be able to provide the same hours of operation during one of these scenarios?
Other standards that you may wish to include involve response times and resolution times. Will these be the same for all of your services or will they be dependent on the business urgency and impact?
Regardless of what you decide, make sure that the IT employees who will be delivering the services to your customer have input and know at what level they are expected to perform.
Your SLA should specify when the agreement begins and expires. I mentioned that an SLA, by definition, is an agreement rather than a contract. Duration information is one concept that carries over from items you would find in a typical contract.
The start date of your SLA allows you to begin tracking IT performance on the same date (unless otherwise specified). If you’re providing a new service or simply revising the services you have been offering to your customers, allow enough time to communicate the details of the agreement to them.
Consider when your SLA will expire. When you negotiate maintenance contracts or equipment leases on behalf of your customers, you may enter long-term agreements with other service providers. Keep these facts in mind when negotiating with your customers.
For example, in an effort to keep costs low for your customer, you may have entered an 18-month lease for equipment that your customer uses. If your SLA expires after only 12 months, your customers may not be obligated to keep paying for your services and you’ll be faced with finding another way to fund the equipment lease.
Roles and responsibilities
Managing your customers’ expectations and those of IT can be tricky if you do not designate everyone’s responsibilities in your SLA. You and your customers have obligations to each other that must be well defined. Some of your customer’s responsibilities may depend on your corporate IT strategy. For example, some companies stress the importance of direct access or self service to maintain a low cost position. If this is true of your customer’s organization, you may want to request that your customers review self-help materials before calling your service desk.
Another basic requirement might be that your customers become familiar with company standards for PC software purchases and installation. Customers should also be expected to report incidents to the service desk when they happen and not hours or days later.
The customer representative
Typically, one person represents all of your customers for the purposes of discussing and negotiating the delivery of IT services. Additionally, the customer representative has the responsibility to communicate the information contained in the SLA to the customers he or she represents.
The customer representative should be from the middle of the organization—a director instead of a vice president or other senior officer—because at that level of the organization, a director will be aware of the business unit’s strategy and understand the concerns that his or her employees have regarding IT services.
Service level manager
Finally, the person who is responsible for IT service level management, usually referred to as the service level manager, is accountable both to the IT customer and the IT department. The IT service level manager is responsible for negotiating, maintaining, and reporting against the SLA with your customers. That person will also meet regularly with the customer representative to discuss performance and any service concerns; I suggest these meetings be held quarterly.
Without evaluation criteria, you’ll have no objective means to determine how well your IT organization is performing. Use caution when you sit down with your customer representative to select metrics. Be sure that your IT organization has tools in place to track what your customer is asking for before you agree to the measurement.
One of the mutual benefits of an SLA is that you and your customer determine how you will judge the service they are receiving. By establishing objective measurements, you eliminate the guesswork.
Remember that your customers may still be unhappy or disappointed with your performance, even when IT meets target goals. If the motivation and attitude of your IT staff is poor, it will have a detrimental effect on your customers’ perception of how well you really performed.
Your customers will expect metrics to be meaningful and geared toward their view of IT service delivery. When I first entered the IT arena 12 years ago, it was common for an IT organization to publish performance metrics that touted the reliability of the mainframe, number of days without unscheduled downtime, and transactions processed per minute.
These metrics were meaningful to the IT organization, but they were less meaningful to our customers. They were examples of system-based metrics instead of what customers want nowadays, which is service-based metrics. As an example, for an availability measurement of an application to be meaningful, it should reflect the end-to-end service delivery—the application, platform, and infrastructure availability—not just the application. While these components are necessities in an SLA, you may need to include many other measurements because of your specific environment.
Is an SLA worth your time?
If you’re still not convinced that writing an SLA with your customer is extremely beneficial for both of you, consider these final thoughts. Writing an SLA with your customer will provide you with better understanding of your customer’s business, the effect the IT services have on your customer and their ability to carry out their business processes, and ultimately an even better relationship with your customer.