In this Alphabet Soup we look at SLA or Service Level Agreements.

A Service Level Agreement is an agreement between two or more parties where one party is the customer or client and the others are service providers for the customer. SLA's can also exist within an organization between, for example, different departments. An SLA typically defines what the customer can expect from the service provider. It spells out the services to be provided, the performance and reliability of the service, a description of any monitoring processes used by the provider to assure the service is operating as expected, clear steps for reporting issues, descriptions of anticipated (or guaranteed) issue response and resolution timeframes, and any consequences for the provider should they fail to meet the promises made in the SLA.

SLAs are best when written from the perspective of the customer and in plain language. This helps the customer understand what they will be receiving. Compliance for meeting the SLA must be measurable and reportable. What exactly will be measured and how it will be measured and reported are important aspects of any SLA.

SLAs are common in technology businesses, with service providers guaranteeing things such as uptime measured in percentages (often 99.9%). SLA's tend to offer customers peace of mind that should their service provider fail to deliver there is recourse for the customer. Most SLA's focus on aligning service provider promises with the needs of the customer business. If you have ever hosted a website or cloud-based program you most likley agreed to an SLA in the process, although it may have been called a WSLA (Web Service Level Agreement).

A SLA will likely contain the following sections:

1. Name of the Service being provided
2. Names and signatures of the people who approved the SLA
3. Date of approval
4. Related contractual information such as effective dates and rules for renewal or termination
5. Service descriptions including expected outcomes for the customer
6. Support contact information so the customer knows who to contact in the event of an outage or other failure
7. Information on the nature of the service in terms of how critical it is to the customer
8. Security requirements such that a failure caused by either party not meeting these requirements can be referenced
9. Times for which the SLA applies and doesn't apply. This is useful if, for example, your SLA promises human support, but you want to have exceptions for major holidays.
10. Other support requirements such as where to report issues or to define groups for whom the SLA does and does not apply. 
11. Targets that define things such as availability, performance, security, reporting and more
12. Exclusions such as maintenance windows and permitted downtime
13. Service continuity requirments that spell out the time to restore services in the event of an outage
14. Technical standards that apply to the service provided
15. Responsibilities for the customer, users, and service provider
16. References to any associated documents that further detail the SLA
17. A glossary of terms, if needed

SLAs essentially help to define the rules of the road between customers and providers or between different departments within an organization. They guide the activities of the service provider and give them metrics to make sure they are meeting expectations.

There are templates for SLAs available online, of course, but before you sign an SLA on either side it makes sense to have an attorney review the document.