Common XLA Mistakes and How to Avoid Them

You’re looking to introduce experience management in your organization – but where do you start? What’s involved in the journey from the status quo to where you want and need to be with employee experience management? And, how to avoid many of the common experience level agreement (XLA) mistakes encountered by other organizations?

Blog_XLA_mistakes

So, you’re looking to introduce experience management in your organization – but where do you start? There’s the need to understand what experience management is, plus what it means in the context of your organization.

There’s also the need to appreciate what’s involved in the journey from the status quo to where you want and need to be with employee experience management. Finally, and it’s something that can be easily overlooked, there’s the need to avoid many of the issues and common experience level agreement (XLA) mistakes encountered by other organizations. 

To help, this article outlines many of the common XLA mistakes that your organization will face when adopting an experience management approach.

The spectrum of potential XLA mistakes

When looking to avoid making the most common XLA mistakes and adoption pitfalls, there are two helpful mistake “groupings” to consider: 

  1. The mistakes traditionally made with service level agreements (SLAs) – of which there are many, including the misuse of traditional metrics, that shouldn’t be brought into the new performance management approach. These can be split into three sub-areas: SLA “positioning,” SLA creation, and SLA use.
  2. The common mistakes encountered in the adoption of XLAs and experience management. These can also be split into three sub-areas: “confusion”-based issues, adoption issues, and usage issues.

Importantly, these aren’t two mutually exclusive sets of mistakes. Instead, there are causal relationships between the two and overlaps. For example, the incorrect use of SLAs, without any management “course correction,” is likely to lead to the incorrect use of XLAs and experience measures. 

  1. Don’t let SLA “positioning” issues become XLA “positioning” issues

Starting with a positive – the intentions of SLAs are often right no matter how poor the execution (which is covered in the next two sections). However, this is not always the case.

This could be where the purpose of SLAs is not understood or where SLAs are used for the wrong reasons (which in turn leads to many of the other SLA issues listed here). For example, instead of being a platform for improvement, SLAs might only be in place within an organization because:

  •  The organization was simply following IT service management (ITSM) best practice “by the numbers” – perhaps “We need SLAs because ITIL says so.” Sadly, these SLAs are often simply “shelf-ware” rather than positive change agents.
  • The IT department wanted to be able to defend its performance – perhaps “I hear what you’re saying but we hit all the agreed service level targets.” With the SLAs used negatively rather than positively.
  • The SLAs have been inherited from an earlier service management top team that was using them for their intended purpose. So, they’re there but with no real purpose, direction, and motivation.

Of these, it’s the first one that’s most likely to derail your organization’s move to experience management.

  1. Don’t let SLA creation issues become XLA creation issues

In addition to “nailing down” the reasons for the introduction and use of experience management and XLAs, it’s also important not to replicate the potential issues with how SLAs were previously created. For example:

  • There’s no, or insufficient, involvement by the customer(s) – so, to say that they’re agreed-on performance targets is a misnomer. A variant of this is where only a subset of the spectrum of stakeholders is involved in a generic SLA’s creation, with it missing their key needs and expectations. The customer is also unlikely to know their obligations within the service relationship, even if they’ve been documented in the SLA/XLA.
  • SLAs are based on so-called “best practice” metrics and targets – which usually means that “they’re commonly used by others” rather than being what’s best for your organization. The same is true with XLAs – that another organization’s portfolio of experience (level) targets is unlikely to fully map to the needs of your organization.
  • The SLA metrics and targets are focused on what’s easy to measure rather than on what’s most important to the customer(s) – with this usually being the measurement of what’s being done rather than what has been achieved through what’s being done. So, ensure that your experience measures are focused on the most important outcomes rather than the operational activities that help to deliver them.

If this type of issue isn’t recognized within the SLA status quo, then it’s likely that similar mistakes will be made in the adoption of experience management and the introduction of XLAs.

  1. Don’t let SLA use issues becomes XLA use issues

How often in IT do we highlight that it’s not the tool that’s wrong, it’s how the tool is being used that’s wrong? This thinking is commonly applied to the employed technology, but it’s also applicable in the context of SLAs. So, there might be issues with how SLAs are being used (or misused) within an organization. For example:

  •  They’re only ever used to call out poor service provider performance – potentially by the customer(s).
  • The metrics are only used to show that targets are being hit, never as a springboard for improvement. This is one of the biggest issues with SLAs and something that needs to be addressed as part of the adoption of an experience management approach and XLAs.
  • Neither the movements in performance metrics nor the relationships between different metrics (and movements) are understood. For example, a positive move in one metric will cause a negative movement in another unless the relationship is understood and carefully managed. Some links between metrics can be leveraged too. For example, with experience management, employee happiness goes up as employee lost productivity goes down – with an hour reduction in lost productivity equating to a ten-point increase in happiness.
  • They’re simply not used – which of course means that they’re never reviewed and updated to reflect new business priorities either (which is also a common issue even where they are used).

Avoiding the common SLA mistakes with your introduction of XLAs

The above three sections offer up a worrying list of example SLA issues and, importantly, many of these can still be present if not addressed when XLAs and experience management are introduced within your organization.

 So, please ensure that you know about these common SLA mistakes, and potentially others within your organization, such that you and your colleagues do what you can to prevent them from being replicated within your adoption of an experience management approach. For example, not appreciating the purpose of XLAs or creating XLAs with minimal customer input.

The common issues encountered in the adoption of experience management and XLAs

The three sets of SLA-related issues described above aren’t everything that needs to be considered when your organization is seeking to avoid the common XLA mistakes and adoption issues – because there’s also the need to avoid the issues related to the introduction of experience management itself. 

As with SLAs, these experience management and XLA-related issues can be split into three sub-groups: confusion-based issues, adoption issues, and usage issues.

 1. Avoid the common confusion-based issues

The use of the word “confusion” might be a polite understatement here because this is where – for whatever reason – the new XLAs and experience are insufficiently different from the traditional SLAs and the performance metrics within them. Here the common mistakes could be any or all of the following: 

  • Not fully appreciating how XLAs and experience (level) targets differ from the SLA equivalents. This might even be the use of the new terminology despite nothing changing for the better – with this simply a case of “rebranding” SLAs to follow current ITSM and management trends. To help differentiate XLAs and SLAs, my advice is that that SLAs measure the process, XLAs measure the outcome and value. So, please remember to look at what you’re measuring and the “why.”
  • There’s a common understanding of what “experience” is but not of what experience means within your organization. For example, what makes up an experience for your organization’s employees using your organization’s IT services and support capabilities. This can be considered the next step along to the above bullet – where the difference between XLAs and SLAs is known but what experience measurement means for your organization isn’t.
  • Unawareness of the size of the change needed for XLAs and experience management to succeed – that it’s not just an operational change but that one is also needed in mindsets and organizational culture. Plus, that over time this might also necessitate personnel changes.
  1. Avoid the common adoption issues

Some of these overlap with the common SLA mistakes. For example, XLAs are introduced as a “good thing to do” rather than to fulfill a certain IT or business need or purpose. However, there are also other common issues here that include: 

  • Taking a big bang approach – immediately swapping out the traditional service level targets for the new experience (level) targets. Instead, HappySignals customers often run both measurement perspectives in parallel such that the new targets can be tweaked as necessary and key stakeholders can be assured of their suitability and worth (including in the context of replacing many of the traditional metrics).
  • Forcing the new metrics on IT employees. As with many changes that involve the introduction of new technology or technology-based services, it’s easy for the impact on people to be overlooked. Instead, there’s a need for organizational change management to help transition the change – including the minimization of the likely resistance to change.
  • Viewing experience management as a “one and done” change. Instead, it needs to be treated as something that will continually evolve, driving improvements in operations, services, and outcomes along the way.
  1. Avoid the common usage issues

Again, many of the common mistakes listed for SLAs above are also relevant to XLAs. But there are also additional mistakes that are related to the use of experience management and XLAs:

  • Missing the opportunity to provide real-time feedback to service providers for motivational purposes. This is where IT service desk agents can see a stream of positive feedback from the people they’ve already helped.
  • Not using experience-based performance measurement data to improve. This includes not diving deeper than the symptoms to understand the root causes. For example, that the reassignment of issues and requests, potentially repeatedly, significantly affects both employee happiness and lost productivity.
  • Failing to prioritize issues and improvements. This includes overlooking the connectivity between different issues, or different improvement activities, such that any improvements made are likely suboptimal.

It’s a long list of potential common XLA mistakes and adoption pitfalls but, as the adage states, being forewarned makes you forearmed.

So, if you recognize many of the above issues and would like help, then please take a look at our Practical Guide to XLAs.

Also, if you don’t recognize any of the above issues and XLA mistakes, then it might be time to look a little closer at how you’re measuring your IT performance and the outcomes being delivered to your organization.

 

Improve your IT end-user experience

 

Related content