Service Level
Management and SLAs
The definitive guide
What is SLA management?
The ITIL 4 body of service management best practice guidance offers a clear purpose statement for service level management:
… The purpose of the service level management practice is to set clear business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored, and managed against these targets.
Source: AXELOS, Service Level Management ITIL 4 Practice Guide (2020)
Where a service level is “One or more metrics that define expected or achieved service quality,” and an SLA is:
“A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.”
ITIL 4 also offers a broader definition of an SLA as:
“A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.”
The bottom line is that an SLA should outline what is, and isn’t, included in an IT service. This detail is for the service provider and the customer, and should outline what both parties have committed to and should expect. It’s important to understand that SLAs are high-level descriptions of the expectations and services but are not contracts. Plus, that an SLA capability works both ways. So it’s not only for the service customer but also the service provider when the customer isn’t fulfilling their obligations.
What SLA management isn’t
Sometimes, in addition to knowing what something is, it’s just as important to know what it isn’t. In the case of SLA management, a good example is the wholesale adoption of industry benchmarks as SLA metrics (or service-level targets or service-level objectives (SLOs)).
While industry benchmarks are helpful, blindly adopting them as the target for any given service is not in the best interest of the service customer or the organization as a whole. Instead, a service provider should agree on service levels, service-level targets, or SLOs with the customer, rather than impose metrics on them because “this is what the industry says is the benchmark target.”
It’s not that the industry benchmarks are wrong; they’re just likely not representative of your organization - both in terms of the service provider and the service customer. Instead, they represent an amalgam organization based on the sample population, with the danger that this fabricated organization’s requirements are radically different from what your organization needs and can deliver.
What SLA management entails
The scope of the service level management practice in ITIL 4 includes:
- “Tactical and operational communications with customers regarding expected, agreed, and actual service quality, as well as their service experience. This includes the collection of feedback.
- Negotiating, entering, and maintaining SLAs with customers
Understanding the design and architecture of services and dependencies between services and other configuration items
- Continual review of achieved service levels versus agreed and expected service levels
- Change assessment
- Initiating service improvements, including improvements to agreements, monitoring, and reporting.
The service level management activities form two processes in ITIL 4:
- Management of SLAs
- Oversight of service levels and service quality (and the use of continual improvement)
The management of SLAs - or SLA management - process includes the following activities:
- Definition of customer requirements
- Viability analysis
- Drafting an SLA
- SLA negotiation
- SLA communication and enablement
- SLA review
The structure of an SLA and its content will depend on the service provider’s needs and its customers. However, an SLA will usually contain five key sections as a minimum:
- A description of the provided service or services
- The expected service standards
- The duration that the SLA applies for
- Each party’s roles and responsibilities (in terms of the SLA)
- Success evaluation criteria and metrics
The need for, and benefits of, SLA management
SLAs and service level management fulfill many essential needs - from better defining the parameters of a given IT service, through measuring its performance and addressing any shortcomings (by either the service provider or customer), to providing a platform on which to build service-related and operational improvements. It does this by focusing attention on what matters most
The benefits of SLAs and service level management are in line with this:
- Better alignment with business needs and improved customer satisfaction. SLAs allow the IT service provider and customer(s) to agree on what’s needed and possible - finding the right balance between the service delivery and support parameters and the associated costs.
- Prioritization on what matters most. For example, the speed of service restoration is based on the SLA-defined priority.
- Standardization of service delivery - with an SLA detailing not only what the service involves but also performance levels, including the consistency of IT support.
- Improved end-user experiences - as long as the service customer is focused on this when agreeing on the service parameters in terms of “what matters most.”
- A platform for service improvement - through the analysis of historical information and service reviews. Either party can use the SLA performance data to identify process improvement opportunities, changes to services, or revised SLA targets to better deliver against business needs and expectations.
SLA management in ITIL 4
vs. ITIL v3/2011
In addition to the generic ITIL 4 changes related to:
- Being service management rather than ITSM guidance
- Practices rather than processes
- The service value system
- Being service management rather than ITSM guidance
- Practices rather than processes
- The service value system
ITIL 4 also includes some service-level-management-specific changes.
The term “service quality” was introduced and is “the totality of a service’s characteristics that are relevant to its ability to satisfy stated and implied needs.” This concept encourages service providers to look beyond what has been agreed on in the SLA to consider customer expectations.
The terms “operational level agreements (OLAs)” and “underpinning contracts (UCs)” were dropped. The previous versions of ITIL had SLAs set up between IT and the business customer, with these supported by
- OLAs - the technical agreements between different IT service teams
- UCs - which applied to anything related to an external third-party or supplier
These three layers of SLAs made IT service delivery and support complex. So, ITIL 4 has streamlined this by having SLAs cover all aspects of service delivery, whether between IT and the customer, IT and IT, or IT and a third party.
In the ITIL v3/2011 service level management best practice guidance, there was a significant focus on warranty (ITIL 4 describes this as “Assurance that a product or service will meet agreed requirements. Warranty can be summarized as ‘how the service performs’ and can be used to determine whether a service is ‘fit for use’”). There’s now a greater focus on utility - “The functionality offered by a product or service to meet a particular need. Utility can be summarized as ‘what the service does’ and can be used to determine whether a service is ‘fit for purpose’” - and experience, plus the expectations on monitoring and reporting relative to these.
ITIL 4 also adds guidance on SLAs related to “out-of-the-box” services where tailoring is not permitted (versus ITIL v3/2011, which assumed that the service provider tailored every service to the customer, with SLAs tailored too). For example, “out-of-the-box” cloud services or outsourcing arrangements for smaller organizations.
If you want to learn more about the differences between ITIL 4 and ITIL v3, check out our Definitive Guide on ITIL.
How to start with SLA management
When starting with SLA management, there are some key steps that an IT service provider should take. Many are similar to introducing other ITSM capabilities that are ultimately focused on the co-creation of business value and not simply the addition of new processes and tooling.
- Focus SLAs on business value rather than IT operations. For example, look at the associated value stream(s) to understand who’s involved, impacted, and served before seeking “customer” input to a new or revised SLA
- Ensure that SLAs are a “two-way street” regarding their creation, content, and use. Effective SLAs and service level management require discussions, negotiations, agreements, and mutual understanding of the service in question between the service provider and service customer. It’s essential to get both parties on the same page to avoid one party thinking one thing and the other party another.
- Create SLAs with the ambition to be actively used rather than becoming “shelfware” that’s only opened when one party has a serious issue with the other. The document length and language, plus the aforementioned customer inclusion in creation, go a long way in helping to ensure this
- Make the responsibilities of both parties clear from the outset. This clarity will prevent any related disagreements later. Especially because, while the service provider will shoulder most responsibilities, the customer will also have responsibilities
- Support customer-facing SLAs with internal and externally-facing SLAs (previously called OLAs and UCs). This oversight is where many IT service providers fail with their SLA - that these supporting SLAs either don’t exist or don’t provide the commitments required for the customer-facing service-level targets to be met. For example, an SLA is unachievable because the fix-time agreed with a third party is longer than that approved for the SLA
- Use “exceptions” to build flexibility into SLAs - these are agreed-on reasons for service-level targets to be missed. Examples of SLA exceptions include peak periods caused by seasonal variations or the relaxation of availability targets if the customer requests a release is deployed with known errors. An extension of this is operating “in the spirit of,” rather than “to the letter of,” your SLAs. Because SLAs need to be about more than simply ensuring that all service-based targets are consistently met
- Build suitable performance measures into SLAs such that performance and success can be accurately reported. The SMART acronym applies here, with SLA service-level targets needing to be specific, measurable, achievable, relevant, and timely. These metrics and associated analytics will also drive service review meetings and identify continual improvement opportunities. This improvement might also relate to the metrics or targets themselves
- Leverage a fit-for-purpose ITSM tool. Not only for the aforementioned reporting and analytics but also the automated monitoring of service performance against agreed thresholds, including breach warnings
- Communicate the content and importance of SLAs and service-level targets to involved staff. This education or training will help their knowledge of what’s most important to end-users (and the service customer) and drive the right behaviors to focus on what matters most
- Don’t let SLAs conformance drive the wrong decisions and actions. Instead, empower the employees with the most up-to-date information to make informed decisions on what to do based on what they think is best for the customer and the organization
- Ensure that your SLAs and service level management practice fall under the purview of the corporate continual improvement efforts
- Don’t sign an SLA until all the involved parties agree on its contents and are committed and able to support it
How ITSM tools help with SLA management
ITSM tools offer capabilities related to the breadth of the service level management practice and the management of SLAs. These capabilities include creating and managing multiple SLAs, holding and documenting review meetings, and identifying and actioning improvements using forms and workflows. Plus the ability to see and manage performance against agreed service-level targets in real-time.
Example service level management and SLAs capabilities provided by ITSM tools include the ability to:
- Tailor individual SLA targets to different issues, services, groups, etc
- Leverage automated notifications to alert people of an approaching SLA breach or to the violation of SLA targets
- Analyze and compare SLA performance for individuals, resolution groups, etc
- Analyze SLA target adherence by service, issue, and request type
- Identify improvement opportunities - from unrealistic SLA targets through to the redesign of operational processes to better meet business requirements
- Visualize past and present performance against SLA targets from different perspectives such as business function
- Run a variety of reports related to SLA performance
To further explore the topic, make sure to follow these four tips to create an ITSM SLA.
The evolution of SLAs to XLAs
A current ITSM trend is using experience-level agreements (XLAs). These agreements are a reimagining of SLAs to focus on what’s most important. They quantify the end-user experience and IT service outcomes to measure performance in outcome and value terms, whereas SLAs usually focus on operations and outputs. Organizations will generally add XLAs to SLAs rather than replacing the latter with the former.
