Chinasourcing > Reserch > An Introduction to Service-Level Agreements (SLAs)
An Introduction to Service-Level Agreements (SLAs)
[  Date:2007-8-9  Font Size:


SLAs are a critical component of any vendor contract. Beyond listing expectations of service type and quality, an SLA provides remedies when requirements aren't met.

By Lauren Gibbons Paul

A service-level agreement (SLA) is nothing more than a type of contract between two parties. In the context of managed IT services (in which SLAs most frequently appear), SLAs dictate the quality and type of service that will be provided to the client in exchange for a fee. SLAs also provide the remedy, such as a reduced fee structure, that will apply in the case of a service outage.

So, for example, if the contract specifies 99.9999 percent uptime and that is not met, the customer would have the right to reduce its bill by an agreed-on percentage. SLAs are important because they set the tone for the relationship between the parties and will govern if and when things break down. A "good" SLA is a balance between being thorough and clear on one side, while not being overly onerous on the service provider on the other.

Table of Contents

  • What is an SLA?
  • Why is it important to have an SLA?
  • Which side should prepare the SLA?
  • What are the basic components of an SLA?
  • What about indemnification?
  • Are SLAs transferable to a third-party provider?
  • How can I be sure the service provider is meeting the service levels set out in the SLA?
  • What is SLA monitoring and verification?
  • What are some SLA metrics?
  • What should I consider when selecting metrics for my SLA?
  • What are the typical uptime provisions for an IT network services provider?
  • Should we review our SLAs periodically?

What is an SLA?
A service-level agreement (SLA) is a document that spells out two or more parties' rights and obligations under a contract for work (such as between a company and its service provider). The main purpose of an SLA is to spell out the level of service that will be provided under the agreement. An internal IT services organization may also provide an SLA to its internal business "customers."

The classic example of an SLA is with a network services provider or telecom provider, where the document dictates what penalties the provider will incur if its performance falls short of specified levels. Usually, in this case, the penalties will follow a stepped schedule - for example, "If the network is down for an hour, the customer is entitled to a 10 percent rebate of its monthly network service fees; if the network is down for two hours, the customer is entitled to a 20% rebate of its monthly network service fees" and so on.

Why is it important to have an SLA?
It is as important to have an SLA as it is to have a contract for business arrangements of all types -- because it constitutes a single document that contains the terms of the agreement as understood by both parties. With the SLA in place, it is much more difficult for either party to claim ignorance if the agreement breaks down. CIOs should expect to have an SLA (reviewed by their legal counsel) in place for every significant service relationship they have.

Which side should prepare the SLA?
Most service providers will offer a standard SLA as part of the work agreement. Ideally, you should use that as a starting point. Give their SLA to your in-house counsel department, if you have one, and let counsel make adjustments that are favorable to your side. Or add some provisions that reflect your priorities. If time is of the essence, however, you may have to use the service provider's standard SLA.

What are the basic components of an SLA?
An SLA can comprise a few short pages up to a few hundred pages. The basic components are a statement of the parties' intent, an outline of the responsibilities of each party (including acceptable performance parameters with applicable metrics), a statement on the expected duration of the agreement, a description of the applications and services covered by the agreement, procedures for monitoring the service levels, a schedule for remediation of outages and associated penalties, and problem-resolution procedures.

What about indemnification?
The SLA should include a provision in which the service provider agrees to indemnify the customer company for any breaches of its warranties. Indemnification means that the provider will have to pay the customer for any third-party litigation costs resulting from its breach of the warranties. If you use a standard SLA provided by the service provider, it is likely this provision will be absent; ask your in-house counsel to draft a simple provision to include it, although the service provider may want further negotiation of this point.

Are SLAs transferable to a third-party provider?
The issue of transferability usually arises when the service provider is acquired by or merged with another company. If the new entity intends to carry on the acquiree's business as usual, the customer will have a natural expectation that the acquirer will assume the previous provider's SLAs. Unfortunately, this may not be the case. SLAs granted by one company do not automatically transfer to a new owner of that company. If your service provider has merged or been acquired, it is likely you will need to renegotiate the terms of the SLA. In many cases, however, the new entity will not want to risk causing ill will with the client base and will therefore assume any existing SLAs.

How can I be sure the service provider is meeting the service levels set out in the SLA?
Most service providers (especially in cases where high availability is critical, such as network services) make reports available, often on a Web portal. There, you can see how your application or system is faring, whether service levels have been maintained and whether you are owed any rebates for service outages. If the service being provided is mission-critical (that is, your business is in jeopardy if the SLAs are not met), you will want to consider using an SLA management tool or monitoring service.

What is SLA monitoring and verification?
Service providers typically have their own means of ensuring that SLAs are being met. But if the service is truly critical to your business, you should consider engaging a third-party monitoring company to monitor your SLAs, ideally in real-time, so you can be sure you are getting what you paid for. It's an extra layer of hassle and expense but key for that extra peace of mind.

What are some SLA metrics?
Most SLA metrics concern the quality of work to be performed by the service provider. According to Ian S. Hayes of Clarity Consulting in Beverly, Mass., a quality definition may contain several individual metrics that may form part of the deliverable's acceptance criteria, or that may serve as standalone measurements of a single aspect of service.

Examples of quality metrics include:

Defect rates. These are counts or percentages that measure the errors in major deliverables, including number of production failures per month, number of missed deadlines, number of deliverables rejected (reworks), and so on.

Technical quality. In the case of outsourced application development, this includes measurements of the technical quality of application code, normally produced by commercial tools that look at items such as program size, degree of structure, degree of complexity and coding defects.

Service availability. This indicates the amount of time/window of time that the services managed by the outsourcer are available, ranging from online application availability to delivery of reports by a specified time of day. Measures can be reported positively or negatively and usually incorporate some level of tolerance (for example, online application availability 99 percent of the time between the hours of 8:00 a.m. EST and 6:00 p.m. EST).

Service satisfaction. This relates to the client's level of satisfaction with the perceived level of service provided by the outsourcer captured for each major function through internal and/or external surveys. Ideally, these surveys are conducted periodically by a neutral third party. Although subjective, they are a good double check on the validity of the other SLA metrics.

What should I consider when selecting metrics for my SLA?
According to Hayes, it is important keep these guidelines in mind:

Choose measurements that motivate the right behavior. The first goal of any metric is to motivate the appropriate behavior on behalf of the client and the service provider. Each side of the relationship will attempt to optimize its actions to meet the performance objectives defined by the metrics. First, focus on the behavior that you want to motivate. Then, test your metrics by putting yourself in the place of the other side. How would you optimize your performance? Does that optimization support the originally desired results?

Ensure that metrics reflect factors within the service provider's control. To motivate the right behavior, SLA metrics have to reflect factors within the outsourcer's control. A typical mistake is to penalize the service provider for delays caused by the client's lack of performance. For example, if the client provides change specifications for application code several weeks late, it is unfair and demotivating to hold the service provider to a prespecified delivery date. Making the SLA two-sided by measuring the client's performance on mutually dependent actions is a good way to focus on the intended results.

Choose measurements that are easily collected. Balance the power of a desired metric against its ease of collection. Ideally, the SLA metrics will be captured automatically, in the background, with minimal overhead, but this objective may not be possible for all desired metrics. When in doubt, compromise in favor of easy collection; no one is going to invest the effort to collect metrics manually.

Less is more. Despite the temptation to control as many factors as possible, avoid choosing an excessive number of metrics or metrics that produce a voluminous amount of data that no one will have time to analyze.

Set a proper baseline. Defining the right metrics is only half of the battle. To be useful, the metrics must be set to reasonable, attainable performance levels. Unless strong historical measurement data is available, be prepared to revisit and readjust the settings at a future date through a predefined process specified in the SLA.

What are the typical uptime provisions for an IT network services provider?
When it comes to hosted network services, most companies will need at least 99 percent uptime; many providers will offer 99.9 percent uptime or higher. It is important to understand exactly what this means, as 99.9 percent uptime equates to 43.2 minutes of unplanned downtime per month. For many enterprises, that level of availability is not acceptable. It is a common practice for a provider to offer nearly 100 percent uptime for certain business-critical applications, but you must be prepared to pay for this guarantee. Many providers offer different levels of uptime guarantees, priced accordingly.

Should we review our SLAs periodically?
In a word, yes. The service-level commitments contained in the SLA are developed from estimates of current and desired service levels that are subject to fluctuation. Accordingly, the SLA should be viewed as a dynamic document and should be periodically reviewed and changed when the following events occur:

  • The environment has changed
  • The client's expectations and/or needs have changed
  • Workloads have changed
  • Better metrics, measurement tools and processes have evolved.

When it comes to SLAs, it is worth spending the time to get them right. As with any long-term relationship, it is best to have the expectations communicated as clearly as possible before the relationship begins. And if things do break down, it helps to have the remedy there in black and white without the need to renegotiate.


  • Previous: A Brief History of Outsourcing

  • Next: None
  • Forward   Print  Collection  Close  Go Top

    © 2007 Chinasourcing Co.,Ltd.