There's a lot of 'talk' about experience level agreements (XLAs), but very little in terms of practical guidance for IT service managers and directors on how to successfully bring XLAs into your own organization. This is where that changes – this in-depth Practical Guide to XLAs provides actionable advice from how to get started, through to common mistakes to avoid.
.jpg)
Positioning SLAs this way creates no real direction for IT, won't create a positive change for end-users or service desk agents, or give you a true insight into your IT service experience.
Therefore, you also need to apply this to XLA positioning. Create a goal and meaning behind each XLA you design and define how it's going to add value to your end-users. Setting up an XLA just because industry experts (or this guide) say so, isn’t enough to do it. Discover what you want to solve or improve for an end-user with XLAs before you set them.
You can still use SLAs in conjunction with XLAs, however, make sure you're measuring the right things - i.e. XLAs to measure experiences and outcomes, SLAs to measure outputs.
Another common mistake is using a “one-size fits all” approach, similar to what has been found in SLA usage. XLAs need to be tailored to experience and an organization’s problems or needs. Furthermore, SLAs focus on what you can physically measure: time, budgets, tickets, etc. This completely misses the most important thing - the end-user’s experience.
Make sure that XLAs are measuring the most important and valuable outcomes instead of traditional operational data.
Another negative use of SLAs has been that they've remained the same, measuring the same outputs over time. This means they're rarely reviewed or updated to reflect changing business needs and priorities. With XLAs, you need to be continuously measuring your end-users experience and then updating your XLAs according to the received experience data. End-users’ experiences will change over time, therefore different goals and targets will need to be set in order to meet end-users’ needs.
It could even be said that the most important usage of XLAs or any experience-related measurement is to identify areas to improve. SLAs might help you to understand what is wrong with the process or service itself, but they can't be used to determine where the experience is lacking.
As already stated, experience level agreements are different to service level agreements. Even though only one word is different and it's still a three letter acronym, they're not the same and it's important to differentiate them.
HappySignals CEO Sami Kallio, differentiates the two as “SLAs measure the process, XLAs measure the outcomes and value.”
In order to differentiate XLAs from SLAs, as well as not to create confusion among your IT team, start to define what experience means within your organization.
Experience is not just an organizational change or new way of measuring, it’s a cultural change. We recommend reading up on organizational change management for maximum success in getting your end-users on board with XLAs.
Instantly swapping SLAs for XLAs is something we don’t advise. Yes, we’re pioneering for a change in measurement and experience, but we don’t recommend scrubbing out SLAs completely. In fact, our customers generally run both in tandem with each other.
Make sure you go through the necessary organizational change management process to introduce your end-users to this change. This is not an overnight procedure, therefore take time with the process, introductions, and transition to XLAs.
The biggest thing to adhere to, and something that has been mentioned above, is that XLAs are not a set-in-stone set of metrics that can be left here forever. You must adapt them, change them, and keep track of them.
Experience is a continuous evolution.
Now this is probably the biggest point for you to follow. Using XLAs without experience management misses the big picture.
As stated in the introduction – XLAs are just one piece of the puzzle. In order to understand the rest of the puzzle and to truly integrate XLAs you need to have experience management.
You may have already started to wonder how your XLAs can measure experience. Or how you find out what your end-users feel about your services. Perhaps how you can identify problem areas? Or even how you can gather actionable data around the impact XLAs will have on your IT services and processes for your end-users?
MSPs have traditionally focused on delivering to agreed-on service levels. Where when a service level agreement (SLA) target is turning red, there’s a focus on remedying the situation. However, if an SLA is green, people won’t necessarily look at it – because they think the service is operating well. But just because an SLA target is green doesn’t mean that the customer, or the end-user, is happy with the service and the MSP. This disparity might be seen via people-centric metrics such as customer satisfaction (CSAT). But it might not.
Experience measurement and management and XLAs, on the other hand, allow MSPs to better understand what’s working well and what’s not (and to address the highlighted issues). This is because there’s an improved understanding of how end-users actually feel about the services they receive and the business impact of any issues. This insight allows an MSP to put the customer at the heart of delivering services and improving them.
For years, traditional MSP SLAs have pushed the service providers to work – and think – in a certain way, but, at some point, most people eventually understand that there’s a conflict between the MSP and end-user view of service performance. Take CSAT questionnaire feedback as an example. The feedback requests tend to be delayed, there’s usually little response, and the questions asked might be removed from what’s actually important to end-users. Ultimately, the CSAT data offers a limited and perhaps skewed view of what end-users think of their MSP’s performance.
For MSPs to really understand their customers’ issues and challenges, they instead need to provide end-users with the opportunity to submit real-time feedback on services based on what matters most to them. This capture of experience data, in high volumes, allows an MSP to see where and why there’s unhappiness or a poor end-user experience with certain services or products they’re providing.
It might, for instance, identify that a new or revised process brought in to help the service provider has caused end-user issues with the service and experience degrading as a result. For example, there’s now a lack of contact or the end-user is asked the same question multiple times. However, despite the issues, the SLA target could still be met, and the MSP views the service as good while the end-user experience is poor and the customer’s – or customers’ – employees are unhappy.
With experience management, MSPs can work together with their customers – using more and better data to have a common understanding of how well services are delivered. This insight identifies the priority issues to tackle, and the MSP can apply corrective measures more quickly (with the affected end-users seeing the services they use getting better through the changes the MSP applies).
Importantly, these improvements don’t stop with a single customer’s issues – because MSPs provide services to multiple customers, relevant learnings and improvements can also be applied to other customers. The issue could again be a process or a particular way of working that’s causing end-users problems no matter the customer, and instead of changing it for just one customer it can be changed for the others too.
Experience management should become the centerpiece of any IT culture, however, getting there is not an overnight process.
We’ve created a way for IT to start adopting an experience management mindset today. Following the concepts of Maslow’s Hierarchy of Needs, we’ve created the experience management pyramid. In order to successfully achieve an experience management culture, your organization must transition through each stage in order.The first level of the pyramid begins with continuous measurement, something that has been reiterated throughout this document. Continuous measurement is the foundation of experience management because, without it, there’s no suitable data from which to gain actionable insights. In this step, your end-users give continuous feedback on the services they receive. You may be thinking “Oh great, a load of negative feedback,” but we‘ve found that on average 75% of feedback is positive.
Experience data should not be owned by one person – it's important to share it between your teams, employees, and partners. This creates transparency of any issues and makes it everyone’s job to improve by creating combined goals to reach together.
From the collected experience data – now that teams and partners are aligned – it’s time to set targets based on the outcomes you want to achieve. Following the advice given above, make sure you set targets that are focused on your end-users and their experiences, as well as the value that these targets, when met, will bring to your end-users.
Customer satisfaction is often confused with customer experience because they sound very similar. There are, however, key differences between the two.
In short, CSAT measures the transaction that happened and how satisfied an end-user was with the interaction between them and the service provider. So you could be satisfied with the service you got, but not the end result of that service or how you initiated it. Experience metrics measure the end-to-end experience, everything that happened before, during, and after.
Traditionally, experience in IT has been measured via a once-a-year survey or through random surveys after some tickets have been handled by the service desk.
The issue with a once-a-year survey is that they’re very generic and they don’t react in the same speed that the world does (you only have to look at the global pandemic to see that). Generic survey questions also mean that you’re potentially asking end-users to rate something they've no experience with. For example, perhaps they don’t use a particular service that is mentioned in, say, question 36.
A better way is to have focused audiences and ask for regular, daily feedback from a small group of end-users. This way you’ll get a continuous stream of responses and see the effect of changes made instantly. For example, having a big enterprise resource planning (ERP) project for multiple years, rolling out to one location at a time, would allow you to learn as you go and improve the experience after each rollout.
You need to measure all aspects of IT, not just the IT service desk. This means topics like devices, enterprise applications, remote working, the office environment, support services, and so on. Each measurement will have its own consumer in the IT department. It’s also likely the IT management team and CIO will want to see them presented in one view or report.
Companies can start with a small selection of topics and then expand to more topics as they start to learn the new ways of thinking about service development.
In order to set goals for IT, we need to be able to measure and manage the targets we set. That is why you can set targets in HappySignals.
Basically, after setting targets, you’re highlighting all aspects of the end-users’ experiences in all the views you see in HappySignals.
Sharing the targets is important, which is why you can use the live screens (our digital signage tool) to display the real-time tracking you have in your office or remote locations.
Experience level targets should be reviewed regularly because end-user expectations change over time. These targets are inputs for your continuous improvement process, or even for your DevOps process.
Find out how to implement XLAs in practice:
When using a real-time analytics tool, like HappySignals, you can instantly understand that experience is multidimensional. Meaning that depending on the person who looks at the data, they need to be able to drill-down based on the data they’re responsible for.
For example, a country manager will click on a specific country to see how the experience is with different services, channels, or assignment groups. But a service owner for email services will just click on “Office365” and see how it’s being experienced in different locations, by different business units, and so on.
IT management teams should treat experience data as the business intelligence (BI) data they use to run their operations. Just like in sales, the sales dashboard is regularly looked at to lead and manage the sales team, this is the equivalent tool for modern CIOs.
Listen to how the CIO of Campari Group describes the importance of this.
