Designing SLA Structure & SLA Content in ITIL - Comprehensive Guide
Designing SLA Structures, and SLA Content in ITIL®

Designing SLA Structures, and SLA Content in ITIL – Comprehensive Guide

Last updated on 12th Jul 2020, Blog, General

About author

Arunkumar (ITIL Configuration Manager )

He is a Award Winning Respective Industry Expert with 11+ Years Of Experience Also, He is a TOP Rated Technical Blog Writer Share's 1000+ Blogs for Freshers. Now He Share's this For Us.

(5.0) | 18635 Ratings 784

In my previous Service Level related article (ITIL Service Level Management – making sure that what you want is what you get), I’ve tried to emphasize the importance of Service Level Management. If that article got you thinking about the topic of SLA, then we have a treat for you; within this article we’re going to explore different options to ensure that all services and customers are covered with best-suited Service Level Agreements (SLAs).

Service-Based SLA

As a service provider, the list of services you provide (e.g., e-mail, file share, desktop management, etc.) is contained within a Service Catalogue.  Each service has been designed with its own properties (utility), which can be translated into business expectations in the form of capacity, availability, security, or continuity (warranty).

Subscribe For Free Demo


If the services you provide are uniform across a wide customer base, then a service-based SLA is the most appropriate way to go. Each service has its own SLA parameters, which don’t change with customer specifics – as there are expected to be none.

Even though there might be some variations in terms of class of service (e.g., bronze, silver, gold), customer-based SLAs are the most straightforward, and the easiest to implement and maintain. However, the biggest downside is the fact that customer-specific requirements can’t be taken into account.

A good example of a service-based SLA would be any kind of cloud service.

Service Based SLA

Customer-Based SLA

Customer based SLA

As the complete opposite to the service-based SLAs, customer-based SLAs put all the customer’s requirements and expectations into a single document. This means that all the services you provide for a specific customer will be described and contained in one SLA per customer.

Even though customers prefer such agreements, they are much harder to manage, and in the case of change in one service, the whole document must be rewritten and signed again – covering the whole service group.

Course Curriculum

Learn ITIL Training Course to Advance Your Skills & Career

Weekday / Weekend BatchesSee Batch Details

Despite the obvious disadvantages, from my personal experience customer-based SLAs are probably the most common SLA types out there. This is not surprising, as Service providers use this framework to display their orientation and focus toward the customer and as mentioned before, customers prefer such arrangements.

Multi-Level SLA



When providing services, either internally or externally, to very large organizations, it may be very challenging to balance SLA types and classes. In order to cope with this issue, a multi-level SLA framework is often broken into three distinct groups:

  • Corporate level SLA – covers all generic service level management (SLM) issues, which are common throughout the organization, but are less prone to changes during the contract.
  • Customer level SLA – covers SLM issues specific to a customer group, or business unit (BU), regardless of service being used. Good examples of such specifics would be service hours, which should match the BU’s working hours (e.g., night shifts, WAN/internet connection bandwidth, etc.)
  • Service level SLA – covers all specifics within a single service in relation to a specific customer (one for each service). For example, email-specific measurables and targets (KPI) are contained within the email SLA, and the same goes for file-share services, desktop management, etc.

Selecting An Appropriate Framework

SLA frameworks are quite straightforward in terms of their applicability.

  1. Service-based SLAs are suitable for generic services (e.g., cloud), and may be used by Type I, and even Type II service providers (ITIL Service Provider types – Type I: Internal service provider, ITIL Service Provider types – Type 2 or Shared Services Unit), as their services are already tailored to meet business demands, and they provide services to a single organization or BU.
  2. Customer-based SLAs are widely used by Type III service providers (ITIL Service Provider types – Type 3 or External Service Provider) because customers prefer to have a single agreement with one provider. Type II providers can use this framework as well, in case they treat individual BUs as individual customers with specific requirements.
  3. Multi-level SLAs are mostly present in large corporations (though not always) that require special treatment in the form of a mixture of generic and specific demands, which must be documented in detail, but at the same time must not generate overhead in management, or overlap in documentation.

Important Decisions

One important piece that could define your SLA framework selection may be service performance monitoring capabilities; nothing should be included in the SLA unless it can be monitored and measured effectively. If you deliver services over a common shared infrastructure (e.g., internet), there is no point in leaning toward customer-based SLAs, as your service performance is directly related to an important piece of infrastructure that is totally out of your control (the internet).

Different SLA frameworks present different options; within a customer-based framework, when negotiating SLA targets with the customer, it’s recommended that you have outlines of the SLA drafted instead of giving a “blank piece of paper.”  Such drafts, however, should not be too detailed, as the customer may feel like negotiations only go one way.  On the other hand, for service-based SLAs, the customer expects a very detailed and informative SLA document right from the beginning of the negotiations.

For any service-oriented organization it’s extremely important to implement a working SLM process. It’s seemingly complex, and many organizations feel discouraged regarding SLM implementation – but you don’t have to be one of them. My suggestion is that after learning best practices on this topic, you simply start making changes you know you must benefit from. Waiting for things to change by themselves is definitely not part of best practices. 

An SLA document typically consists of:

An introduction to the SLA, what does this agreement propose

Itil Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download

A Service description, what service this SLA supports and details of the service

Mutual responsibilities, who’s responsible for what part of the service

Scope of SLA

  • Applicable service hours, from what time till what time is the service available according to the agreement
  • Service availability, how much is the service available during the service window and outside of the service window
  • Reliability
  • Customer support arrangements
  • Contact points and escalation; a communication matrix
  • Service performance
  • Security
  • Costs and charging method used

Are you looking training with Right Jobs?

Contact Us
Get Training Quote for Free