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. \n\nFollowing are answers to common questions about SLAs and tips on how your organzation can craft effective SLAs with your vendors and partners.\n\nWhat is an SLA?\n\nA 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.\n\nA 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.\n\nWhy do I need an SLA?\n\nSLAs 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.\n\nAny 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.\n\nIdeally, 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.\n\nWho provides the SLA?\n\nMost service providers have standard SLAs \u2014 sometimes several, reflecting various levels of service at different prices \u2014 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.\n\nWhen 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. \n\nFor more, see "9 IT outsourcing RFP response red flags."\n\nWhat's in an SLA?\n\nThe 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.\n\nMetrics 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.\n\nWhat are key components of an SLA?\n\nThe SLA should include components in two areas: services and management.\n\nService 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.\n\nManagement 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.\n\nThis 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.\n\nFor more, see "10 do's and don'ts for crafting a more effective SLA."\n\nWhat is an indemnification clause?\n\nAn indemnification clause is an important 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.\n\nIs an SLA transferable?\n\nShould the service provider be acquired by or merge with another company, the customer may expect that its SLA will continue to be in force, but this may not be the fact. The agreement may have to be renegotiated. Make no assumptions; however, bear in mind that the new owner will not want to alienate existing customers, so may decide to honor existing SLAs.\n\nHow can I verify service levels?\n\nMost service providers make statistics available, often via an online portal. There, customers can check whether SLAs are being met, and whether they're entitled to service credits or other penalties as laid out in the SLA.\n\nUsually these processes and methodologies are left to the outsourcing company to identify, ensuring that such processes and methodologies can support the SLA agreement. However, it's recommended that the client and the outsourcing company work together during the SLA contract negotiation to eliminate any misunderstanding about the process and method of support as well as management and reporting methods.\n\nFor critical services, however, customers should invest in third-party tools to automatically capture SLA performance data, which provide an objective measure of performance.\n\nWhat kind of metrics should be monitored?\n\nThe types of SLA metrics required will depend on the services being provided. Many items can be monitored as part of an SLA, but the scheme should be kept as simple as possible to avoid confusion and excessive cost on either side. In choosing metrics, examine your operation and decide what is most important. The more complex the monitoring (and associated remedy) scheme, the less likely it is to be effective, since no one will have time to properly analyze the data. When in doubt, opt for ease of collection of metric data; automated systems are best, since it is unlikely that costly manual collection of metrics will be reliable.\n\nDepending on the service, the types of metric to monitor may include:\n\nWhat should I consider when selecting metrics for my SLA?\n\nThe goal should be an equitable incorporation of best practices and requirements that will maintain service performance and avoid additional costs.\n\nIn addition to defining the services to be provided, the contract should also document how the services are to be monitored, including how the data will be captured and reported, how often it will be reviewed, and who is involved in the review.\n\nIs there room for negotiation on SLAs with cloud service providers?\n\nCloud vendors are more reticent about modifying their standard SLAs because their margins are predicated on providing commodity services to many buyers. However, in some cases, customers are able to negotiate terms with their cloud providers.\n\nWhether or not there is wiggle room, it is critical to understand and scrutinize the SLAs in a cloud computing contract to determine whether they present any significant risk.\n\nCan I create joint SLAs shared among multiple vendors or service providers?\n\nCustomers can create joint metrics for multiple service providers that factor in cross-supplier impacts and account for impacts that the vendor can have on processes that are not considered in-scope to their contract.\n\nIT organizations managing multiple service providers may want put in place operating level agreements (OLAs), which outline how particular parties involved in the process of delivering IT services will interact with each other in order to maintain performance.\n\nIf I opt for outcome-based pricing with an IT outsourcer, do I still need SLAs?\n\nIT outsourcing deals in which service providers\u2019 compensation is linked to business outcomes achieved have grown in popularity as companies evolve from pure time and materials or full-time-employee based pricing models.\n\nIn these cases, the outcome is a business result rather than a specific activity, task, or resource. But even in an outcome-based deal, SLAs serve as important indicators of performance against those business outcomes. SLAs for these deals will not outline technical or operational requirements for given tasks; rather, they outline end-client goals. For this approach to work well, those outcomes must be unambiguous, there must be ways to measure achievement of the outcomes, roles and responsibilities must be clearly defined, and the supplier must have control over the end-to-end service required to deliver results.\n\nCan we create SLAs for shadow IT?\n\nIT can harness the power of shadow IT services and solutions and mitigate associated risks by taking the same types of SLA IT uses to manage the performance of IT service providers and apply them to shadow IT. The IT organizations can take several steps to build an SLA framework for technology services delivered outside the IT organization and measure and report on their performance.\n\nWhat happens if a provider doesn\u2019t meet agreed-on service levels?\n\nSLAs include agreed upon penalties, called service credits, which can be enforced when\n\nvendors miss minimum performance standards. Provider and customer agree to put a certain percentage of monthly fees (typically equal to the vendor\u2019s profit margin) \u201cat risk\u201d from which these credits are drawn when SLAs are missed. This approach is intended to incentivize provider performance without being overly punitive.\n\nBest-in-class IT organizations avoid using SLA provisions as punishment for their IT partners and use SLA metrics as an opening for productive conversations around performance, priorities, and the future direction of the engagement or relationship.\n\nWhat are \u201cearn backs\u201d?\n\nSome vendors may ask for the right to \u201cearn back\u201d paid service credits. Such a provision allows providers to earn back the service credits they\u2019ve given up for SLA defaults by performing at or above the standards service level for a certain amount of time. While providers may argue that an earn back provision is only fair, it can undermine the service credit approach altogether.\n\nHow often should we revise our SLAs?\n\nAs businesses change, so do its service requirements. An SLA should not be viewed as a static document. In fact, SLAs should include a clearly defined framework for modification during the term of the contract. The SLA should be reviewed periodically, specifically if:\n\n\u2022 The client's business needs have changed (for example, establishing an e-commerce site increases availability requirements).\n\n\u2022 The technical environment has changed (for example, more reliable equipment makes a higher availability guarantee possible).\n\n\u2022 Workloads have changed.\n\n\u2022 Metrics, measurement tools and processes have improved.\n\nThe SLA is a critical part of any supplier agreement, and it will pay off in the long-term if the SLA is properly thought-out and codified at the beginning of a relationship. It protects both parties, and, should disputes arise, will specify remedies and avoid misunderstandings. That can save considerable time and money for both customer and supplier.