SLA 101

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.

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:

• 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.

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.