Splunk Inc.
12/20/2024 | News release | Archived content
SLA Templates: How To Create Service Level Agreements
From payroll to payments, e-commerce to cloud hosting, the world of IT service provision continues to evolve. For many of these tasks, businesses adopt cloud-based solutions, but ensuring a robust cloud service with minimum downtime and optimized uptime is challenging.
For every IT service, there is always an expectation: that the services offered meet the needs of those who use the services (and those paying for it). Of course, a given service can be developed without any involvement of customers, but you risk that customers may not want it, as the service may not support their desired outcomes.
Modern organizations consider customers and users as invaluable contributors throughout the IT service lifecycle and desire to collaboratively partner with them in value creation. The shared view of the customer’s expectation and the service provider’s capability is encompassed in a service level agreement (SLA).
In this article, we'll share the ins and outs of SLAs, including templates for creating both simple and more complex SLA documents. We’ll also talk throughout about best practices for protecting the rights of both parties (service provider and customer) and building mutual trust.
What is a Service Level Agreement (SLA)?
SLAs are formally defined in the service management practice of the ITIL 4 framework for IT service management. Let’s start with a definition:
Service Levels Agreements (SLAs) are contracts between service providers and customers (or any two parties) that identify and describe the services required and the expected level of service. SLAs should include:
- The services that you deliver
- Expected quality standards and performance metrics
- The units and prices for each service
SLAs are the place to be specific: include the exact uptime or response time in SLAs. This helps customers understand what to expect from your enterprise. It also ensures both stakeholders can hold each other accountable in case of any issues.
(Related reading: SLA vs. SLI vs. SLO: Understanding Service Levels.)
Structure of an SLA
An SLA can have a variety of formats, formality, and customer involvement. You can have:
- A specific SLA for a service, or one SLA covering multiple services.
- A formal document signed by all parties involved, or a publication on a website that clients read and acknowledge. (The latter are a form of SLAs that do not give room for customers to negotiate service levels.)
For example, AWS cloud service plans come with fixed terms and conditions, so customers choose the service levels based on their budget, as prices determine the quality received, including the service performance and support.
Customized services that are based on specific customer requirements will usually incorporate service level targets in the design, and hence the client pays for the level of quality in advance.
SLA examples with unique features
Here are some examples of SLAs from organizations that have included some unique features:
- University of Saskatchewan IT Core Services SLA Includes guiding principles that encapsulate the essence of the SLA, i.e., mutual benefit, collaboration, and transparency.
- Prague Airport SLA Includes timelines across the customer journey and the associated workload limits of airport equipment handling persons and baggage.
- DNSimple Nameserver Infrastructure and API SLA Includes definitions of service outages (plus what is not a service outage, i.e., exceptions) and credits to be applied in the event of an outage based on certain terms.
- Observe.ai Software Services SLA Includes service error descriptions with associated priority classification, response times, and status updates.
Alignment with internal and external stakeholders
The definition and agreement of SLA targets require alignment with internal and external stakeholders who play a role in supporting them. Incorporation of experience metrics measured from the customer perspective helps to prevent the “watermelon” effect for service reporting. When you have this watermelon effect, here’s what happens:
- All metrics look “green” from the service provider’s end.
- Meanwhile, from the user’s perspective, the service is ‘red’.
A regular review of the performance against targets and actual workload against the set limits should be held by the service provider and the customer (or business unit representing the customer) to ensure they remain relevant within the evolving operational context.
Elements and components in an SLA
According to the ISO/IEC 20000-1:2018 standard for service management, the constituent elements that are expected within an SLA based on service requirements are service level targets, exceptions, workload limits, and additional relevant information.
Let’s look at each component:
Service level targets
The service level targets are based on different dimensions such as:
- Availability: Service uptime or reliability measured as a percentage of availability, minutes of downtime, frequency of failures (MTBF - mean time between failures), or speed of restoration (MTRS – mean time to restore service).
- Performance: Service performance based on technical capacity characteristics, e.g., processor load, optimal utilization of memory, storage, or bandwidth, or latency.
- Quality: The integrity of the service data, including transaction success rate or error rate.
- Timeliness: The urgency of support offered to users, including response time and resolution time for requests and incidents.
- Experience: The perception that customers/users have of the service and support offered, such as satisfaction, effort, and loyalty.
Exceptions
Exceptions apply whenever circumstances arise that would prevent meeting of the targets, such as:
- Service continuity type disruptions that are outside the organization’s control
- Early life support periods
- Holiday periods or non-business hours
Workload limits
The workload limit measures the applicable volume of work within the SLA, such as:
- Number of users, transactions, or service components to be supported
Additional relevant information
Other information that may be relevant in an SLA includes:
- The description of the services and who consumes them
- Service charges and credits relevant to selected service levels
- Acknowledgement by the representatives of both the service provider and consumer
Now that we understand the background of service level agreements, let’s look at two templates that you can use right now to create your own SLAs.
How to format an SLA
SLA designs can take a variety of forms, as we’ll see below. What’s most important is to ensure that there is alignment of expectations by all parties involved—as we discussed earlier.
For example: without a comprehensive SLA, very little can be done about poor service when there is no definition of what good service is. Customers will assume that everything will be delivered and available at a 100% level all the time, which is a recipe for disappointment.
A well-articulated SLA formalizes a mutually acceptable position for the service provider and service consumer, ensuring value is co-created and sustained, resulting in a satisfied customer and a fulfilling service experience.
In the following sections, we’re going to show you templates for two approaches for SLAs. One is simple and straightforward, and one is more detailed and may be appropriate for multiple services and/or covering a large contract.
Template: creating a simple SLA
Here is a sample template that an organization providing end-user device support can create to manage SLAs with their corporate customers:
END USER DEVICE SUPPORT SLA
This Service Level Agreement is made and entered into thisand
Service Description
The services to be offered are as follows:
- Technical components description
- Support elements description
Service Level Targets
Service availability:
Service guaranteed performance:
Service support:
| Priority | Response Time | Resolution Time |
| Critical | ||
| Major | ||
| Medium | ||
| Minor |
Service Level Exceptions
Exceptional events:
Exceptional time periods:
Exceptional days:
Workload Limits
System Limits:
Human Resource Limits:
Escalation Matrix
| Escalation Level | Escalation Timeline | Name & Contact |
| First Line | ||
| Second Line | ||
| Third Line | ||
| Executive Level |
Roles and Responsibilities
Service Provider Roles:
- Provide services as per the contractual terms
- Provide monthly reports on service performance
- Communicate changes to service functionality and support in a timely manner
- Address issues raised within service level targets
- Furnish monthly invoices in a timely manner
Service Consumer Roles:
- Adhere to contractual terms
- Participate in service status review meetings
- Communicate changes to consumer environment within a timely manner
- Make payments against invoices in a timely manner
SLA Review
A formal performance review of this SLA will be conducted on the first working week of every quarter. Any amendments to the SLA will be discussed and agreed during this review.
Approvals
We have read the above SLA and hereby forge an agreement according to the conditions stated:
| Service Provider Representative | Service Consumer Representative |
| Name: | Name: |
| Designation: | Designation: |
| Date: | Date: |
| Signature: | Signature: |
Template: creating an in-depth SLA
The elements of a Service Level Agreement (SLA) template may vary depending on the nature of your business.
Since it is the most important document for cloud-based services, you must carefully draft all sections that favor both parties.
In this longer, more detailed SLA template, we’ll outline five sections:
- Section 0: Cover page or title page
- Section 1: Informative
- Section 2: Service scope
- Section 3: Performance
- Section 4: Duties and responsibilities
Section 0: title page of SLA
The first page, often called the cover page or title page, is an important introduction to the agreement. Let me outline how you can put up this page in your SLA:
SERVICE LEVEL AGREEMENT
Agreement ID: {SLA-xxx-xxx}
Version: {Add your version number}
Effective Date: {Add your date here}
Service Provider: {Service Provider Name}
Customer: {Customer Name}
Brief Description: This Service Level Agreement (SLA) defines the terms of service between {Service Provider Name} and {Customer Name} for the provision of {brief service description}.
CONFIDENTIAL
Key Contacts:
For {Service Provider Name}: [Name], [Email], [Phone] For {Customer Name}: [Name], [Email], [Phone]
| Authorized Signatures | ||
| —-------------------------- | —-------------------------- | |
| For {Service Provider Name} | For {Customer Name} |
Section 1: informative section
Any key information goes under this section to provide context and background information about the agreement. This helps both parties understand the purpose of the SLA.
Involved parties
Include a table that specifies parties, their roles, and contact information. To do so, you can follow this format:
| Stakeholder | Name | Contact Information |
| Service Provider | XYZ | Email: Phone: |
| Customer | ABC | Email: Phone: |
Change approval and implementation
In this sub-section, the service provider must specify conditions for requesting changes. Here’s how you can put it in your SLA:
- Any change in the agreement requires a prior notice of 30 days.
- Both parties must agree to the implementation of the new service terms and conditions.
Contract termination
Add a clear timeline about when and how the contract will end. It could be like:
- The contract can be terminated with a 45-day notice if either fails to meet the agreed terms.
Glossary of terms
Include definitions for technical terms and acronyms used in the SLA. Here’s how:
| Term | Definition |
| SLA | Service Level Agreement, a contract that defines terms and conditions between provider and customer |
| MTTR | Mean time to repair is the time a system failure recognition and rectification take |
| Uptime | The percentage of time that a service is operational and available |
| CPE | Customer premises equipment refers to hardware located at the customer's site |
Section 2: service scope and description
This section includes an in-depth description of the services you will provide. It may include the following sub-categories depending on your needs:
Service type
Define the type of service you're going to provide. For example, there are three common cloud services: SaaS, PaaS, and IaaS. So, you must mention which one you provide.
Duration and signatories
Include your agreement's start and end dates in SLAs to make sure everything is clear about when the terms apply. Next to these dates, add a designated space for signatures and ensure all stakeholders have signed after thoroughly reviewing the agreement.
Here’s how you can put it in your SLA:
| Stakeholder | Name | Signatories | Start Date | End Date |
| Service Provider | xyz | -- | MM/DD/YYYY | MM/DD/YYYY |
| Customer | xyz | -- | MM/DD/YYYY | MM/DD/YYYY |
Location
You'll be working with international clients most of the time, so incorporate their time zones into your SLA like this:
- Service hours from 8 AM to 5 PM Eastern Time (USA) will correspond to 2 PM to 11 PM Central European Time (Germany).
Quality specifications
Outline the expected performance and quality levels. If your SLA claims to provide 99.99% uptime and 52m 35.7s of downtime, the provider is responsible for ensuring it.
Deliverables
Under deliverables, specify the outcomes you will be delivering. To do so, you can follow this format:
The outcomes that {Service Provider Name} will provide include:
- A monthly uptime report
- User access logs
- Security audit reports
Section 3: performance metrics
Cloud providers don't care about the quality an individual consumer receives — they rather focus on overall quality. That's why your SLA must have different performance metrics to ensure accountability. The three most important ones to include are:
- Availability
- Response and fix times
- Reliability
Let’s see what each of these covers.
Availability
Availability defines uptime in percentage — the higher uptime percentage indicates the better quality of the service. Here's what these percentages mean:
| Percentage | Downtime per year |
| 99.99999% | 3.2 s |
| 99.9999% | 31.6 s |
| 99.999% | 5m 15.6 s |
Unavailability can result in financial loss, so it's not ideal to go below 99.9%. That’s why the service providers should commit to their claimed service availability criteria. For example:
- The support via phone and email will be available 24/7 with 99.999% uptime.
- Website hosting will be operational 24/7 with 99.9% uptime.
Response and fix times
The mean time to repair (MTTR) score measures the outage time. Your SLA must specify the maximum time allowed to acknowledge and resolve incidents and outages. Here's how you can mention it in your SLA:
- {Service Provider Name} will respond to server outage within 15 minutes and resolve it within 5 hours.
- {Service Provider Name} will acknowledge data breaches within 30 minutes and resolve them within 6 hours.
Reliability
You must also provide fault-tolerant services. However, outages are part of maintenance and nobody can predict the unplanned outages. That’s why it's better to include the number of planned outages.
For example, mention it like this:
- An outage is scheduled for December 26, 2024, which will last for 24 hours.
Section 4: duties and responsibilities
In this section, you define both parties' duties and responsibilities and the consequences of not meeting those service levels. Here are the sub-sections that you must include in your SLA:
Provider responsibilities
You can list the service provider's responsibilities like this:
The {Service Provider Name} responsibilities include:
- Managing security patches and updates for all underlying infrastructure.
- Encrypting all sensitive customer data at rest and transit.
- Ensuring secure management of all firewall configurations.
Customer responsibilities
You can list the customer's responsibilities like this:
The {Customer Name} responsibilities include:
- Maintaining their guest operating systems.
- Checking for vulnerabilities in any third-party software.
- Managing and locking inactive accounts within their systems to improve speed.
Violation of SLAs
When it comes to SLA violations, both parties include specific clauses and provisions to address potential breaches. The following points are examples of SLA violations:
- If the uptime drops below 99.9% in March, the {Customer Name} will receive a 3% discount on the service subscription fee.
- If the incidents remain unresolved for more than 5 hours, the {Customer Name} may request a meeting with {Service Provider Name} to discuss a remediation plan.
Pricing and discounts
Here's how to include different services, along with their units and pricing for different tiers:
| Service | Unit | Tier | Unit Price | Total Costs |
| Cloud Storage | 100TB | Tier 1 (first 50TB) | $0.025 per GB/month | $1,250 per month |
| Tier 2 (next 50TB) | $0.020 per GB/month | $1,000 per month | ||
| Data Transfer | 500TB | Tier 1 (first 300TB) | $0.09 per GB | $27,000 per month |
| Tier 2 (next 200TB) | $0.07 per GB | $14,000 per month | ||
| API Requests | 5,000,000 requests | Tier 1 (first 2 million requests) | $3 per million requests | $6 per month |
| Tier 2 (next 3 million requests) | $2.50 per million requests | $7.50 per month | ||
| Total Cost | $43,263.50 per month |
SLA best practices
A good SLA protects the rights of both providers and customers. It’s a lengthy process and requires careful planning to design such an SLA. In addition to following our SLA template, here are some best practices that you must follow:
- Track SLA performance: With the SLA dashboard, you must keep track of error rate, response time, and latency period to see if the provided service meets the standards.
- Create realistic targets: Ensure you set realistic goals. For example, it's not possible to achieve 100% availability. So, you must avoid making such claims.
- Take consistent feedback: Collect customer feedback and analyze the gaps to improve your SLAs.
Personalize your SLAs
Since every customer has different business needs, one SLA template can’t fit all. The service levels and performance metrics for cloud kitchens will differ from those for a cloud application in healthcare. So, you must communicate with customers and your IT team to create personalized SLAs that set realistic goals.