Service Level Agreements (SLAs) are a key part of IT Service Management (ITSM). SLAs are agreements that define what users and customers can expect from the IT services; define targets for suppliers; and provide suppliers, customers and stakeholders with regular information on how the services are delivering on these expectations. This information is used to drive improvements. Using SLAs can support effective working relationships between IT and the business, as both should be involved in SLAs’ creation, maintenance and use. Service Level Management is the process responsible for SLAs in an organization.

Basics of SLA

What is an SLA?

A Service Level Agreement 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.

 

What is an Underpinning contract?

An Underpinning Contract (UC) describes a contract between a customer and a supplier, which includes SLAs for the services provided. The UC will also contain contractual clauses that aren’t directly related to the service levels, such as how to use subcontractors, technical standards required of the supplier and who owns the intellectual property rights for the services. For every requirement in a contract, it is good practice to indicate what will happen if the requirement is not satisfied. Including targets for adherence in SLAs is a useful mechanism, as compliance can be measured and reported. This can include targets for submitting change requests within a specified time period, attending service review meetings and adhering to policies for providing knowledge. Using SLAs provides a higher profile for any failures, and can result in financial penalties if these have been defined.

 

SLA, OLA or 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 agreement, 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:

 

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.

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 Process 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:

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.

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, the method, format and frequency of reporting 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. Reports should be automatically produced from the data captured during monitoring, as this will give an accurate view of the true SLA achievement. 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 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, it is standard practice to include 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. This can result, however, 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?

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.

What is the role of SLAs in a business?

Users expect to know what levels of service they will receive. They may not be interested until they experience issues, but it is still good practice to include them in an SLA, ensuring the contents are presented in a manner users can understand. SLAs help a business to manage its suppliers, by establishing their expected performance. There is a risk to a business that publishes its SLAs to external customers without ensuring the service levels can be fulfilled. Customers will consider these service levels as promises, and will quickly become dissatisfied if they fail. Even one failure can result in lost customer loyalty.

SLAs in the digital age

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 services provided from the cloud

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.

Reinventing the SLA

Some organizations focus on the service-level achievement of their individual IT services rather than the service customers actually receive. This often leads to what is called the “Watermelon” effect, where the SLA metrics show all is well (“Green”), but the customer is unhappy (“Red”). A typical example is when service reports show all service levels are being fulfilled even though the services had unplanned downtime during the workday. This is usually because the service levels have been designed from an IT perspective, looking at one IT service at a time. This can be avoided with a technique known as “Outside in.” SLAs should be initially designed from the customer perspective, looking at the services it consumes and its business requirements for good service. The service levels for the IT and related services, such as the service desk, should then be designed to fulfill these business requirements. This results in service levels that reflect both the customer experience and the individual IT and other services that create the experience.

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.

Best practices for implementing and operating SLAs

The contents of an SLA will evolve from the service-level requirements (SLRs) that are created during the initial design of a service. These contents should be unambiguous and written in an easily-understood style. Although they will form part of a contract if the supplier is external, they should avoid using legal language and terminology. There are several steps to creating an SLA:

1. Document objectives and capabilities
2. Gain mutual understanding
3. Create a draft SLAs
4. Negotiate SLAs
5. Sign and communicate the agreement
6. Use and review the SLA

Sample template for SLAs

An organization will normally adopt a standard template for all SLAs. This supports common understanding by those who have a need to understand the service levels in ITSM, IT, and the customer’s organization. It also supports comparison of SLA achievement across different service providers. A standard template may not be possible with providers who supply commodity services when the customer will have to accept the format the service provider uses. A typical SLA template includes the items in the following table:

Service name(s):
Approval information
Related contractual information
(not required for OLAs)
Brief service description(s)
Desired outcomes from the SLA
Communications
Service reporting
Service reviews
Criticality
Security
Service times
Support times
Support requirements
Service level targets
Exclusions
Service continuity 
Technical standards
Responsibilities
Pricing model (only if charges are made for using the service(s) )
Change history
Associated documents
Glossary of terms

Other ITSM Resources