A service-level agreement (SLA) defines the level of service you expect from a vendor, laying out the metrics by which service is measured, as well as remedies or penalties should agreed-on service levels not be achieved. It is a critical component of any technology vendor contract.
SLAs are a critical component of any outsourcing and technology vendor contract. Beyond listing expectations of service type and quality, an SLA provides remedies when requirements aren’t met.
Following are answers to common questions about SLAs and tips on how your organzation can craft effective SLAs with your vendors and partners.
What is an SLA?
A service-level agreement (SLA) defines the level of service expected by a customer from a supplier, laying out the metrics by which that service is measured, and the remedies or penalties, if any, should the agreed-on service levels not be achieved. Usually, SLAs are between companies and external suppliers, but they may also be between two departments within a company.
A telecom company’s SLA, for example, may promise network availability of 99.999 percent (for the mathematically disinclined, that works out to about five and a quarter minutes of downtime per year, which, believe it or not, can still be too long for some businesses), and allow the customer to reduce their payment by a given percentage if that is not achieved, usually on a sliding scale based on the magnitude of the breach.
Why do I need an SLA?
SLAs are an integral part of an IT vendor contract. An SLA pulls together information on all of the contracted services and their agreed-upon expected reliability into a single document. They clearly state metrics, responsibilities and expectations so that, in the event of issues with the service, neither party can plead ignorance. It ensures both sides have the same understanding of requirements.
Any significant contract without an associated SLA (reviewed by legal counsel) is open to deliberate or inadvertent misinterpretation. The SLA protects both parties in the agreement.
Ideally, SLAs should be aligned to the technology or business objectives of the engagement. Misalignment can have a negative impact on deal pricing, quality of service delivery, and customer experience.
Who provides the SLA?
Most service providers have standard SLAs — sometimes several, reflecting various levels of service at different prices — that can be a good starting point for negotiation. These should be reviewed and modified by the customer and legal counsel, however, since they are usually slanted in favor of the supplier.
When sending out an RFP, the customer should include expected service levels as part of the request; this will affect supplier offerings and pricing and may even influence the supplier’s decision to respond. For example, if you demand 99.999 percent availability for a system, and the supplier is unable to accommodate this requirement with your specified design, it may propose a different, more robust solution.
What’s in an SLA?
The SLA should include not only a description of the services to be provided and their expected service levels, but also metrics by which the services are measured, the duties and responsibilities of each party, the remedies or penalties for breach, and a protocol for adding and removing metrics.
Metrics should be designed so bad behavior by either party is not rewarded. For example, if a service level is breached because the client did not provide information in a timely manner, the supplier should not be penalized.
What are key components of an SLA?
The SLA should include components in two areas: services and management.
Service elements include specifics of services provided (and what’s excluded, if there’s room for doubt), conditions of service availability, standards such as time window for each level of service (prime time and non-prime time may have different service levels, for example), responsibilities of each party, escalation procedures, and cost/service tradeoffs.
Management elements should include definitions of measurement standards and methods, reporting processes, contents and frequency, a dispute resolution process, an indemnification clause protecting the customer from third-party litigation resulting from service level breaches (this should already be covered in the contract, however), and a mechanism for updating the agreement as required.
This last item is critical; service requirements and vendor capabilities change, so there must be a way to make sure the SLA is kept up-to-date.
