Beyond20: A ServiceNow Elite Partner What's New & Changed in the ITIL 4 Service Level Management Practice

What’s New and Changed in the ITIL 4 Service Level Management Practice

Erika Flora
Written by Erika Flora

Why Service Level Management (SLM) and Service Level Agreements (SLAs) are so important in serving customers

SLAs. They are the backbone of delivering products and services to customers. Customers want them because they provide an overview of ‘what they will get’ from a particular product or service, how available the product or service will be, how quickly we will respond, how often we will keep them updated, and, most importantly, how we will fix them when something goes wrong. The list goes on. Service providers don’t generally love creating and publishing SLAs as we’re often held to these demanding standards. However, I would argue that, without them, we’re held to the impossible standard of everything, all the time, for free. If you don’t have SLAs in place, put them in place. If they’ve gone stale or customers hate them, it’s worth looking at ways to improve them.

What This Article Covers, Including SLAs and XLAs

This blog article will provide an overview of some Service Level Management-related concepts and definitions including SLAs and the new concept of Experience Level Agreements (XLAs). We’ll also look at what’s new and interesting about the ITIL 4 SLM practice and compare it to what existed in ITIL v3 (for those of you that are familiar with that version). Then, I’ll share my thoughts on why getting this stuff right can make or break our customers’ perception of us, how they interact with us, and the overall health of that relationship.

Where do Service Level Management and SLAs fall in ITIL 4?

Let’s start with the purpose behind the ITIL 4 Service Level Management (SLM) practice:

Purpose: 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.

As mentioned above, one of the most powerful tools a service provider has at their disposal is putting some sort of SLA in place that sets expectations, drives productive and meaningful conversations with customers, and allows better management and improvement of our overall performance. That’s done as part of the ITIL 4 Service Level Management practice. Here’s a diagram from the ITIL 4 SLM practice that’s helpful in visualizing the activities involved in it.

 

SLA ITIL 4

 

Service Level Management Concepts from ITIL v3

The SLM practice in ITIL 4 falls into the broad category of “Service Management” practices, basically those concepts that have been a part of the ITIL books since the start and form the basis of the concept behind Service Management. For any of you that have studied or taken an ITIL v3 training course, the SLM practice (which used to be called a process), has been around for more than a decade.

A lot of the basic concepts from ITIL v3 are the same: the importance of creating SLAs that are measurable and realistic to achieve, writing SLAs in plain, customer-focused language (essentially, avoiding tech jargon that confuses customers), as well as reviewing our team’s performance against SLAs, discussing ways to improve performance, and revising SLAs as needed. The difference in the ITIL 4 SLM practice is that there’s a lot more detail around each of these items and practical advice throughout – 33 pages of good information, in fact (I’ve included information on where to find the entire practice guide at the end of this article).

Does Service Level Management Still Reside in ITIL’s Service Design Phase?

The short answer is no. ITIL 4 does away with the service lifecycle, replacing it with the concept of the Service Value Chain or SVC, which is a much more iterative and incremental way to look at how work is actually done when delivering products and services; and Service Design is now its own separate practice.

New Service Level Management Concepts in ITIL 4 (and Some That Have Gone Away)

There are, however, some interesting additions to the SLM practice in ITIL 4, namely the inclusion of: business-based targets, different types of SLAs (beyond what you may have learned in ITIL v3), which we will talk about in the following sections. One notable omission in the ITIL 4 SLM practice is that of Operational Level Agreements (OLAs) and Underpinning Contracts (UC). Before you get your tissues out, we’ll talk about why these concepts went away.

What is a Service Level Agreement in ITIL 4?

The definition of an SLA, though it has changed slightly from the ITIL v3 definition, remains essentially the same, namely:

SLA: a documented agreement between a service provider and a customer that identifies both services required and the expected level of services.

SLAs can have all levels of formality and be legally binding or not. What matters is that our SLAs promote common understanding, are measurable, and are reviewed and changed as things change (more so with a tailored service than an out-of-the-box service), either internally or on the customer side.

A ‘tailored’ service means that there is significant flexibility in target service levels that should be agreed before service delivery and consumption start, whereas an ‘out-of-the-box’ service has one or more pre-defined service levels to choose from, without much flexibility.

What are the 3 types of SLA in ITIL v3 and how do they look in ITIL 4

For those that have gone through ITIL v3 training, you may recall that there were three common types of SLAs that we as service provider organizations would create. They are as follows:

  • Service-based SLAs, which defined one particular service for multiple customers
  • Customer-based SLAs, which defined all of the services that one customer consumed
  • Multi-level SLAs, which often contained a combination of services and customers

In the ITIL 4 practice, these types have been pared down to two simple types: tailored and out-of-the-box SLAs.

SLA requirements and metrics in ITIL 4

I like this recommendation from the ITIL 4 SLM practice – based on ITIL’s guiding principle of “keep it simple and practical”: Do not try to put everything in the agreement, but focus on what matters and can be realistically measured and managed.

This diagram does a nice job of showing how the scope of, in this case, a tailored solution shrinks along the way, prior to writing an SLA. The practice guide includes a similar diagram for out-of-the-box services.

figure 2.2 tailored services sla itil 4

 

Not everything is going to fit within an SLA, nor should it. Instead, the SLM practice guide recommends getting those things “…through the collection of [frequent customer feedback].” This can be done several ways, including: through conversations like service review meetings, automated dashboards that provide SLA data and the ability for customers to interact with the dashboard and provide feedback, customer surveys, and even social media sentiment.

New concept in ITIL 4 SLM: Creating SLAs with business-based targets

The SLM practice now includes verbiage around setting “business-based targets” as it stresses how we as service providers can write better SLAs by basing everything on what our customers care about and what they’re trying to achieve, not just on operational metrics that make sense to us. SLAs serve us (and those we serve) best when they are written in plain English, are easy to understand, take our customers’ needs and perspective into account, look at how they are using the service and what the service is allowing them to do, and promote conversation. The SLM practice includes a new term, that of “service quality”, which should be considered as part of SLAs.

Service Quality: the totality of a service’s characteristics that are relevant to its ability to satisfy stated and implied needs.

Service quality can refer to items that are agreed-upon and documented in the SLA; however, it can also refer to expectations that are implied or assumed by our customers, so it’s important to know what those things are, collect feedback, and address them to improve as an organization.

I find this statement in the SLM practice extremely helpful when looking at service quality: “To maintain an effective service relationship, services should be financially viable for both service providers and service consumers.” This is key—particularly when delivering services that bring revenue in—to ensure that we keep ourselves in check and don’t give too much away for free. In order for SLAs to work well, services need to be cost effective for customers and profitable for providers. Even if we’re not “charging” for services, there is value in understanding how much time and money we’re spending supporting particular services so we can better manage where our staff is spending their time (and whether it’s in the right places).

New concept in ITIL 4 SLM: Focus on the User Experience

In ITIL v3, there tended to be an emphasis on Warranty. In ITIL 4, this has been updated to include an equal focus on Warranty (when a service will be there), Utility (what the service does), and user experience. We know that how you provide a service is just important as, if not more than, what you provide. In fact, under the section that speaks to ITIL’s Guiding Principles, it recommends to, “Focus on outcomes for the service consumer organization and on user experience more than on technical details and associated metrics.”

New concept in ITIL 4 SLM: The introduction of XLAs

One of the concepts that’s alluded to in the SLM practice (with mention of the user experience and business-based targets), but not specifically called out, is that of Experience Level Agreements (XLAs). XLAs are important in understanding the impact we’re having on the customer experience. Unfortunately, very few KPIs used in IT departments are based on factors like customer experience, empathy, and emotions; and XLAs can help us as an organization develop our capacity for digital empathy.

“You have to start with the customer experience and work back towards the technology, not the other way around.”

Steve Jobs

How XLAs are Different from SLAs

SLAs are important to put in place, as they provide details on how a service technically performs and supports what customers are trying to do. XLAs, on the other hand, provide details on how a service is received by customers and the experience that it leaves them with. XLAs define what are called “experience indicators”, or XIs, to determine whether we’re delivering desired outcomes for customers. Coined by Giarte in Amsterdam, XLAs are becoming more and more popular. With that said, XLAs are not meant to be a substitute for SLAs. Rather, XLAs are a complement to SLAs that focus on customer experience and sentiment.

The Expanded Details on Service Review Meetings in the ITIL 4 SLM Practice

I like that ITIL 4 has an emphasis on service review meetings. The SLM practice document includes a lot more guidance than what was contained in the ITIL v3 version. Here’s the essence:

“Service reviews can be interval-based or event-based. Interval-based reviews take place regularly at agreed time periods. The intervals depend on factors such as: previous satisfaction with the service, the number of changes introduced to the service since the last review, likelihood of changes to service expectations/requirements, and so on. However, regular service reviews do not usually occur more than once a month. Yet, service reviews do not work effectively if performed at intervals longer than three months. Event-based service reviews may be triggered by events such as a major incident, a request for a significant change in the service, or a change in the business needs/requirements of the service.”

What has gone away in the ITIL 4 SLM Practice – OLAs and UCs

What’s missing in the ITIL 4 publication is any mention of documents called Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). There are several reasons these terms were removed, most notably that, in practice, everyone calls everything an SLA. The only difference is your perspective. In some cases, you may be providing a service; and in other cases, you may be consuming a service from, say, a vendor. However, the agreement is still between the two parties. The only difference is what side of the relationship you’re on.

Adhering to strict terminology for the other types of documents was, often, confusing for service providers and didn’t add a lot of value to the conversation. In fact, it was often an area of confusion for ITIL v3 students and most people just memorized the terms to successfully pass the exam – and went back to calling everything an SLA after class. I, personally, think the change is a good one as it simplifies the terminology we use. (side note: If you find value in using the terms OLA and UC, feel free to keep using them. No one’s telling you that you shouldn’t or can’t, they’re just no longer terms that are defined as part of the ITIL 4 framework).

With that said, we definitely want to be mindful to avoid putting ourselves in a bind by agreeing to an SLA when there are supporting SLAs that conflict with it or make it impossible to write. Several years ago, we worked with a large retail customer that couldn’t effectively put an SLA in place with their customers because the supporting SLA with a vendor didn’t include any details around resolution times – only response times. Unfortunately, their legal department put the SLA in place without consulting with IT first, resulting in, essentially, a resolution time of “infinity”. Not so fun. 

Additional resources that can help you in your SLM journey

AXELOS’s Service Level Management practice guide provides lots of additional details and is available for free as part of a MyITIL subscription for those that have taken and passed an ITIL 4 Foundation course (otherwise, it’s $50 for a one-year subscription). If you are responsible for creating, reviewing, or improving SLAs for your organization, it’s a worthwhile read.

Pro Tips for Creating and Revamping Your SLAs

One of the foundational items to have in place to be able to write good SLAs, however, is to first have a solid list of the services you offer as part of a service catalog (it’s hard to write SLAs when you’re missing clarity around the “S”). Otherwise, you’ll end up re-writing your SLAs before long, and that is definitely no fun for anyone involved. Putting a great Service Catalog together is a deceptively difficult thing to do, and most organizations stop short before getting it to “great”. Don’t have a solid list? Not to worry, we can help (and have helped hundreds of customers with this very thing), and in a matter of days, no less. Here’s a link to our 2-day Service Catalog workshop to learn more.

Originally published April 04 2020, updated January 01 2024
ITIL/ITSM  
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]