The all in one customer engagement suite
Everything you need to know about SLAs
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
The name(s) by which the service(s) is/are known, plus any unique reference code(s) that links it/them to the service catalog/CMDB
Approval signatories from the customer and the supplier
Date the SLA was signed
Related contract numbers
Start, end and review dates
Rules for renewal and termination of the agreement, including early termination
Sufficient information for the reader to understand what the service(s) is/are
A description of the business activities the service(s) and SLA support
Who uses the service(s)
A description of what the SLA is trying to achieve, including the intended outcomes. These can be “soft,” such as behavioral changes, as well as “hard,” such as highly available services
Person responsible at the customer, with contact details
Person responsible at the supplier, with contact details
Procedures for addressing exceptions, escalations, complaints, and amendments
Procedures for conducting service reviews for the services this SLA covers
Requirements and procedures for any satisfaction surveys for the services
Nature and frequency of reports, showing achievement against SLA service levels
Nature and frequency of service reviews
Required attendees at service reviews
Chair of service reviews
Criticality of the service(s) to the business
Any critical business functions the service(s) supports/support
Any critical asset(s) the service(s) uses/use
Any security requirements for the service(s) and the SLA
Times the service(s) is/are required to be available
Any specific exceptions, such as public holidays
Times support is available for the service(s)
Where to report incidents
Any different requirements for specific locations or groups of users
Resolution time targets
Service reporting targets
All other targets
Service continuity requirements, including target time to restore service and target time to restore normal service levels
Mandated technical standards
Any technical interfaces
Definition of the charges and how they are calculated
Rules for calculating any penalties for failure to fulfill service levels
Version history for the SLA, with dates and approvers
Any related SLA documents in a multi-level structure
References to related procedures not included in this document
Description of terms used in the document
Change & Release Management – It’s Complicated!
ITIL & DevOps – Compete or Complement?
5 Hacks for Good IT Service Management
The Paradigm Shift In ITSM
Start your 21-day free trial. No credit card required. No strings attached.
By clicking on "SIGN UP FOR FREE" you agree to our Terms and acknowledge having read our Privacy Notice
By clicking on "REQUEST YOUR DEMO " you agree to our T & C and privacy notice
Sorry, our deep-dive didn’t help. Please try a different search term.