Service Level Agreement | SLA Best Practices

Basics of SLA

What does an SLA stand for?

SLA stands for Service Level Agreement. An SLA is a formal, structured agreement between two parties to provide one or more services to a mutually agreed level. One of the parties is always the customer of the services. The other party is the supplier that provides the services. A supplier can be part of the same organization as the customer (service provider) or in a different organization (external). The SLA can be a physical or electronic document. Appropriately authorized individuals from both parties should sign the document. It extends the definition of a service from the one contained in the service catalogue, and provides an agreed and guaranteed minimum level of service performance.

What does an SLA contain?

An SLA describes the services it covers, the scope of the services; the service characteristics, including the hours when it is available and the hours that are supported; the targets for these services (known as service levels); and the responsibilities of both parties, including responsibilities for review and maintenance of its contents. It can also include a pricing model, with any charges for using the service and penalties that are payable for failures to fulfill the service levels. The SLA should be written from the viewpoint of the customer, to facilitate understanding.

Service Level Agreement (SLA), Operational Level Agreement (OLA), Underpinning Contract (UC)

These different terms can be confusing, especially to those who aren’t qualified in ITSM that included them. It is important to remember that there should always be a formal agreement on the levels of service a supplier provides a customer and documented in an SLA. This ensures the customer is aware of what he or she can expect, and the supplier is aware of what he or she must provide. The term isn’t as important as having it in place and using it. Many organizations just use the term SLA to refer to all of these three types of service level agreement. That can significantly simplify the conversations between all parties, especially those outside ITSM, as most people understand the concept of service levels. Using the term SLA throughout the conversation is more likely to lead to success in your use of ITSM. In the remainder of this SLA Best Practice guide, this term will be used for all three types of agreements, including those with internal providers and those that are part of a contract with external suppliers.

Benefits of SLAs

Well-developed and -implemented service level agreements can benefit the customer, the users, and the suppliers, including internal IT. These benefits are best realized through careful design, planned implementation, active use, and continual improvement. Some benefits of SLAs are:

Help guarantee good service and satisfied customers
Provide end-users with an expectation of the quality of service they can expect to receive
Help to avoid misunderstandings or confusion about what must be done
Provide a trusted source of information for the agreement
Make the customer and the supplier be attentive to the details of the services
Protect suppliers from ambiguous and unstated requirements

How many SLAs should an organization have?

It is good practice for an organization to have one SLA per supplier, which includes all of the services the supplier provided. This simplifies the creation of the agreement, as the general requirements will be the same and the services will often have the same service levels. The SLA can be subsequently updated to add new services or remove retired ones. There is no limit for how many services should be in one agreement. It is also good practice to ensure SLAs exist for every supplier, including internal ones. This helps to ensure the expectations of the customer are explicitly stated and the suppliers understand them, and the customer understands what service it can expect to receive.

SLA Management

What is a multi-level SLA?

A multi-level SLA is a structure used to avoid duplication and reduce the frequency of updates to the SLAs, whilst allowing the flexibility to customize them for specific customers and services. Using a multi-level SLA structure is typically for documenting service levels when the suppliers are within the same organization. It can also be particularly useful when an external supplier provides multiple services, which mostly share common requirements, but where certain services have different service levels or requirements, such as 24 x 7-support requirements. A typical multi-level SLA structure has three levels:

Corporate level, covering requirements common to every customer within a business. An example is an SLA for every user of an email system, so passwords can be changed every 30 days.
Customer level, covering requirements specific to a particular customer or set of customers within a business, including all services delivered to it. An example is a standard level of service availability for all services provided to one customer.
Service level, covering requirements for specific services. This is the lowest level and can be used if a specific service has requirements and service levels that are different from the standard for the business or a customer.

Who is the customer in an SLA?

The customer is the person or organization who uses the services. The customer can be internal or external to the organization. All businesses provide services to external customers. These can be services based on IT, such as cloud-based applications, or non-IT services, such as a holiday booking call center. The customer for the services can be individuals or other companies. Even when it’s impractical for external customers to sign an agreement formally, SLAs should still be created, as they provide a clear and precise description of what the customer can expect and drive improvements in service quality.

Which types of services should be included in an SLA?

SLAs can be useful whenever there is a need for a formal agreement between two parties, detailing the expected levels of service, accompanied by the associated responsibilities. ITSM has traditionally only included IT services, including the service desk in SLAs. Service levels and the associated agreements, however, should, in fact, be used for any type of service. These can include labor-based services, such as providing consultancy; commodity services, such as supplying consumables; and technical, non-IT services, such as supporting fire alarm systems. SLAs can also be used for process-related activities where there is a need to define, monitor and measure compliance. This can include attendance at formal meetings, targets for responding to complaints and achieving deadlines for submitting bills.

Which process is used for managing SLAs?

Service Level Management (SLM) is the process that negotiates SLAs between the customer and the supplier and aims to ensure they are fulfilled. SLM should ensure that all other processes used in ITSM support achieve the agreed service levels. This includes verifying all SLAs can support the agreed service-level targets, including those in OLAs and UCs. Service level management monitors and reports on the service levels documented in the agreed SLAs conducts regular service reviews with customers and suppliers, identifies required improvements, and then reports on and monitors improvement actions. SLM should be conducted in both the customer and suppliers.

SLA monitoring and reporting

The achievement of every service-level target documented in the agreement must be monitored and reported. How this is accomplished will depend on the precise nature of the service level. The method and frequency of monitoring should be defined and documented in the SLA. Similarly, for SLA reports, the method, format, and frequency on the achievement of the service level should be documented in the SLA. For complex targets and where penalties for failure exist, it is good practice to test all calculations before going live. SLA reports should be automatically produced from the data captured during monitoring, as this will give an accurate view of the true SLA achievement. SLA reports should be produced often enough to highlight trends in SLA achievement before failures occur and to generate confidence in the process. During the early stages of a service, weekly reporting can be used to verify if all processes, systems, etc. are working as expected. Reporting to customers can be reduced to a monthly interval and even quarterly as confidence is gained in both the services and the supplier; however, a good supplier would report internally more frequently to highlight issues before SLA targets are breached.

Penalties for not fulfilling SLAs

Where SLAs are included in an underpinning contract with suppliers, the standard practice includes penalties for service not delivered according to the agreed levels. The penalty can be a fixed amount for each failure or a variable amount on a sliding scale, depending on how much the target has been breached. It is very important to set the penalties at a level appropriate for the impact of the failure on the business. Setting SLA penalties too large can result in suppliers not signing the agreement, or requesting early contract termination. For the same reason, parties should agree to a cap on penalties when a sliding scale of penalties is included. When the total penalties during a period reach this cap, no more penalties are accrued. However, this can result in the supplier having no incentive to remedy the failures when the cap is reached. This can be overcome using a “repeat-failure” mechanism in the SLA, where the financial penalty is increased if the cap is reached during two or more consecutive periods.

How to leverage a service level agreement: The basics

It is important to use and apply consistently the details of the SLA agreement. Service-level achievement must be reported and reviewed between the customer and the supplier. If there are any failures to fulfill the agreed service levels, there is a possibility of breaching them, or when either party has failed to fulfill their responsibilities documented in the SLA, then they must agree on actions to be taken to investigate and resolve the reasons. If there are penalties for failure, then they must be routinely applied. One of the most common reasons for failure in SLAs with external suppliers is inconsistently ensuring the details of the SLA agreement actually occur. This includes preparing reports in the agreed format and delivered according to the schedule and applying any penalties whenever failures trigger them. If this is not done, then the supplier is more likely to challenge the customer when it eventually decides to apply the service level agreement. If both parties recognize issues with the agreement, then the SLA can be amended using the same approach as for its creation.

SLAs in Practice

What is the difference between SLAs and KPIs?

SLAs and KPIs both provide useful information. SLAs set baseline performance expectations with clearly described targets, duration, and penalties when service expectations are not met. KPIs on the other hand, are metrics that describe quantitative results on goals/expectations.

KPIs help in the evaluation of decisions, tracking progress on a goal, and monitoring the performance of a business goal. It is important to identify, track, report, and evaluate metrics that are indicative of the goals to be achieved.

In order to monitor service level performance, it is important to define metrics and KPIs the organization needs to meet its objectives

SLAs in the digital age

When a business provides the same online services to multiple individual customers and users outside the organization, for example, a financial institution providing online banking services, there will usually be a single SLA for all customers, describing the services and targets they will receive. It will not be possible to obtain agreement from all of these customers, so an SLA of this type is typically agreed with a representative, such as the internal product owner in the business for those services. If there is a user group for the services, then they should be consulted about the requirements for the service levels; however, it can be challenging to obtain consensus and agreement of the final SLA.

SLAs and cloud services

Suppliers that provide commodity services via the cloud should still use SLAs, as these provide their customers with a guarantee of the level of service they can expect. This can give them a competitive advantage. Most cloud providers offer the same standard SLA with common service levels to all customers. Some offer enhanced levels of support in tiered “Gold/Silver/Bronze” SLAs, where the customer receives improved service levels if the customer pays a larger fee. Customers who purchase cloud services must generally accept the offered service levels. A cloud supplier is unlikely to customize an SLA just for them.

Using SLAs to manage the risk of non-compliance with data protection laws

Service level agreements can help you comply with data protection laws, such as GDPR. As well as specifying targets for traditional ITSM service levels, such as availability, SLAs should also include targets for other types of requirements, including security. Having a target allows you to measure compliance. This could be as simple as a service level for responding to subject access requests, such as when an individual wants to know the stored data about them. This is particularly important if you are using external suppliers to deliver your business services.