Sample Service Level Agreement (SLA) Template

A Service Level Agreement (SLA) is a contract between a service provider and customer. It includes a set of promises by the service provider about what the service involves, the acceptable levels of any interruptions or limitations to the service, plus the consequences of exceeding these levels.

Here's what you need to know about these agreements, and how to create, display and get users to agree to your own.

What is a Service Level Agreement (SLA)?

An SLA is a common part of the documentation when a customer agrees to pay for a service, whether that be for a set period or indefinitely. It's not intended to cover every part of the contractual relationship between the service provider and customer.

Instead, it's designed to cover three specific points:

• What exactly is the service being provided?
• What promises does the service provider make regarding measurable "levels" of service such as availability, quality and completeness?
• What happens if the service provider fails to meet these levels?

In theory, an SLA could work for any type of service with quantifiable elements.

For example, St Mary's University has an SLA for lawn maintenance:

In practice, SLAs are most commonly used for online services and business support services. That's partly because the service is usually provided remotely, and partly because the service is designed to be available either consistently (e.g. during office hours) or constantly (e.g. 24/7 access).

Both of these elements create the potential problems that an SLA tries to solve.

Some businesses use a Service Level Agreement for internal operations, for example with the IT department agreeing to provide a particular level of service to the rest of the business. However, in this guide we're only covering SLAs between service providers and customers.

How Does a Service Level Agreement (SLA) Work With Other Legal Agreements?

As noted, an SLA is not usually the sole formal agreement between the service provider and customer.

Other legal agreements could include:

• A Terms and Conditions agreement, which lays out the service provider's general rules and policies, for example acceptable payment methods or how to resolve disputes.
• A contract to cover the specific relationship between the service provider and customer. This often details the price the customer pays and any special exceptions or alterations to the Terms and Conditions agreement.

It's possible to combine some of these elements into a single document, though an SLA may work better as a separate document if it's particularly detailed. Two ways to avoid confusion are:

• If you combine documents, clearly label each section so customers can check specific elements of the agreement.
• If you have multiple documents, make sure each one refers to the other documents that affect the relationship between the service provider and customer.

Do I Legally Need a Service Level Agreement (SLA)?

It's very rare you are legally or contractually required to have an SLA. The only time it might usually happen is if you use a platform or technology to provide a service to customers and the operators of the platform or technology say you must have an SLA with customers.

However, having an SLA is usually a very sensible idea for several reasons.

Why Should I Have a Service Level Agreement (SLA)?

Having an SLA helps avoid ambiguity and disputes about whether you have or haven't provided the promised service, and what happens if you haven't. This saves you time and money dealing with the dispute, plus the risk of paying damages or compensation for which you hadn't budgeted.

An SLA helps to create certainty for your business. Because you know the agreed service and service levels, you can allocate the necessary resources to meet your commitment. You can also monitor your service levels and head off problems or shortcomings before they cause a breach of your commitment.

Another reason for having an SLA is that it creates trust with customers. They may be more attracted to doing business with you because of the specifics of your SLA's promises, the fact you are being clear and open about what you offer, or both.

What to Include in a Service Level Agreement (SLA)

Exactly what to include in an SLA will depend on the nature of your service. However, many of the following points will be worth including:

Service Description

Set out exactly what your service covers. The goal here is to be concise but also comprehensive, which can be a delicate balancing act. Think carefully about any points of possible ambiguity, for example elements of the service that customers may wrongly assume are or are not included.

Educare fully explains what its service includes before going on to the service level commitments:

Service Levels Provided

This should cover any guarantees you want to make that cover quantifiable elements of your service. This could include:

• Availability/up-time of service. This could be stated as a minimum percentage or time of availability, or a maximum percentage or time of unavailability.
• Hours during which you will provide service.
• Maximum response times to service requests, including any variations for different priorities of incident.

If necessary, clarify and define what you mean when you use particular terms. For example, downtime could refer to a website being slow to respond, certain features being unavailable, or the entire website being offline.

Google confirms the meaning of "downtime" and a key limitation on its calculation:

AirIT explains how it assigns a priority to issues, which affects the response time guaranteed under the SLA:

Arlo gives clear, quantifiable commitments in clauses that addresses uptime, response time to support requests and incident management:

Measuring, Reporting and Review

Explain how you will calculate the figures for the relevant service levels, again seeking to remove any ambiguity.

Say how often you will review service levels to check compliance and whether the customer can record and measure non-compliance themselves.

If you refer to percentages for uptime/downtime, be clear about the timescale. The period over which you calculate the percentage makes a big difference to expectations.

For example, a promise of 99.9% uptime across a year-long contract means a total of just under nine hours total downtime is acceptable. Customers might respond very differently if you racked this up by averaging 90 seconds of downtime in the middle of every night to the way they'd respond if your service was available consistently throughout the year but then their website was offline for eight straight hours.

Mews explains the schedule for calculating downtime, along with the important detail that it's based on unavailability across its entire customer base:

Set out whether, when and how you can review the commitments and propose an alteration. Set out the customer's rights after a change, for example if they can insist on the original service level commitment for a certain period, or if they can cancel without penalty after any change.

Exceptions to Your Commitments

Be clear about any exceptions you want to impose on your service level commitments. For example, you could say acceptable response times are longer, or the limits don't apply, during holiday periods. You might also say that the limits don't apply if you are unable to provide normal service because of a natural disaster.

Microsoft gives a comprehensive list of exceptions for its Azure service:

Customer Responsibilities

Set out any conditions the customer needs to follow for the service level commitments to be valid. For example, they may need to report any problems to you in a specified manner as soon as they become aware of the issue.

You could also say they aren't allowed to do anything that might compromise your ability to provide the service, for example running or allowing malware on their systems.

Foleon gives a clear list of customer responsibilities:

Consequences for Failing to Meet Service Level

Set out what happens if you fail to meet the service levels. Remember that this section is as much a commitment as the service levels themselves.

Possibilities include:

• You will offer a refund. (Explain how this is calculated.)
• You will offer service credit, for example extending the renewal date at which the customer next needs to pay.
• You will pay compensation for consequential loss.
• You will allow the customer to cancel the service without the usual penalties or notice period.

Remember, it's up to you to set out what you offer in the event of falling short of your service levels.

Amazon gives a clear explanation of when it offers service credit, how much, and how to use the credit:

Metapack notes the most serious shortfall can give the customer a right to cancel:

Now that you've seen some of the key components of a Service Level Agreement, let's look at where you should display your own when you have one created.

How to Display a Service Level Agreement (SLA)

When displaying your SLA, the two key points to remember are that customers must be able to see the SLA before signing up, and they must be able to check the SLA at any time after signing up/while receiving the service.

You should have the SLA readily available on your website. Having a copy on your site can help attract potential customers by showing your service level commitments.

If your SLA is very short, you could build it into a page with other legal information such as a Terms and Conditions agreement. If it's longer, it may work better as a dedicated web page.

Either way, make sure it's clearly marked and easy to find through your website's navigation. This could be through a direct link in navigation menus or by putting it in a "Legal" or "Terms" section.

Twilio has a standalone page for its SLA, clearly positioned within its legal section:

Communicate Better has a dedicated link in its footer menu:

After you write and display your SLA, it's time to get your users to appropriately agree to or consent to it. The next chapter will show you how to do that.

How to Get Consent to a Service Level Agreement (SLA)

For your SLA to be legally binding, it's vital you can prove your users have agreed to it. In some cases, a physically signed paper document may be necessary. In other cases, particularly when signing a customer up online, an electronic agreement will be enough.

You must make sure you have a clear signal from the customer that:

• They have read the SLA, and
• They agree to it as part of their contract to sign up to the service

Ways to do this include:

• Requiring the user to check a box or click a button specifically marked as agreeing to the SLA. (An "I Agree" checkbox or button)
• Require the user to take an action such as ticking a checkbox or changing a slider setting before clicking the button to agree.
• Require the user to give a digital or electronic signature showing agreement.

Merton Music Foundation uses a sign-up page that links to the full Service Level Agreement, then requires new customers to specifically accept the SLA as part of their contract:

Summary

Let's recap what you need to know about Service Level Agreements (SLAs):

An SLA sets out the service you provide, specific quantifiable promises you make about the service, and the consequences if you fall short. This type of agreement usually works alongside other legal documents such as a Terms and Conditions agreement.

Having an SLA can avoid ambiguity, create certainty and attract customers.

An SLA should cover points such as:

• Description of your service
• Quantifiable service levels
• Measuring and reporting setup
• Exceptions
• The customer's responsibilities
• Consequences if you fall short of the service levels
• What happens when the contract ends

Display your SLA prominently on your website, either as a standalone page or part of a legal section.

Get customers to confirm they have read and consent to the SLA when they sign up to a service. For added certainty, make this a clear and unambiguous signal such as ticking a box, clicking a clearly-marked button or giving a signature.