Back to Resources
Creating an XLA from scratch is a process that’s more about articulating what good IT support should look like than making that into a workable deal that teams can implement daily. Experience Level Agreement provides service desks with a way to go beyond response and resolution times to measure the quality of the support experience.
Quality of IT delivery is not the problem for many organisations. It’s more about whether users feel supported, informed, and productive. That’s where an XLA can help. It provides a structured framework for service desk teams to establish service-level expectations, define service responsibilities, and evaluate and measure experience in a manner that facilitates continuous improvement.
What is an XLA?
The Experience Level Agreement (XLA) is a service management framework that describes the experience a user is supposed to have when interacting with a service. The SLA is about the technical side of the service, e.g., response time, uptime, etc., whereas the XLA is about the end user’s experience of the service.
That includes factors such as ease, clarity, confidence, how well they communicate, and the impact that support has on productivity. On a Service Desk, this creates a more level playing field by incorporating the human element as well as the operational aspects of service delivery.
🔗 Download Your Free Service Level Agreement Template
Why start with the user journey
A good starting point is to focus on the services that are most important to users in service journeys. The moments when experiences are most strongly shaped include onboarding, password resets, device replacements, accessing applications, logging incidents, and communicating with applications in the event of a major outage.
Specify the steps in the journey instead of a general statement such as “support should be helpful.” What does the user need at each step, what are they looking for, what is likely to make them mad, and what does success look like? That provides the XLA with real substance and makes it easier to measure later.
Step 1: Define scope
All XLA’s require a clear scope. Determine services, channels, user groups and journeys covered by the agreement. When you attempt to have all of it, the XLA becomes too extensive to deal with, too obscure to act upon.
An XLA for a service desk may be shorter and focused on some of the highest volumes of interactions with most users, or it may be one single, business-critical journey, like new starter support. The scope should be sufficiently specific yet broad enough to make a useful contribution.
Step 2: List outcomes
When the scope is understood, state the experience outcome. This is the user’s ‘good’ statement. It should be about the desired outcome of the service desk, rather than steps the service desk needs to take.
For instance, if you tell users that your tickets will be answered quickly, you might want to go ahead and say they will feel informed and reassured along the entire support process. This is much easier to tie to sentiment, communication quality, and productivity-based measures.
Step 3: Set responsibilities
The XLA can only be used if there is clarity of ownership. There are roles that must be assigned to someone to deliver the service, gather feedback, review it, and take action to improve it.
This is a particular point to consider in environments where internal teams, managed services providers, and technical resolver groups are all playing a part in the user experience. When responsibilities are not clearly defined, it becomes a report rather than a management tool.
Step 4: Choose the appropriate measures
An XLA should not be based on a single score, but rather on a combination of measures. Typically, the most useful XLA metrics are divided into three categories: operational, user sentiment and business outcome.
Operational metrics could be: Response time or resolution time. Sentiment measures can be satisfaction, effort, or confidence. Business benefits could range from saving time to improving productivity, reducing rework, or a lower number of repeat contacts.
The only thing that matters is taking measures that reflect the actual experience you want to improve. There are so many metrics that it’s hard to keep track, so target a handful of key metrics that are important to users and stakeholders.
Step 5: Specify feedback approach
An effective means of collecting experience data is required. This could be post-ticket surveys, journey feedback, pulse surveys, interviews, or reviews after certain interactions. The method should be easy to use so that users will respond, and informative enough to provide insight.
Avoid using annual surveys as the only measure. Experience is formed in the moment, and feedback is often most strongly expressed when it is received shortly after the service encounter. This is why the service desk XLAs are best integrated into the support process with feedback.
Step 6: Review cycle agreement
An XLA should not be a “one-and-done” document. It should be reviewed regularly to ensure that the data lead to action. To ensure the most effective practice is being followed, most service desks should review their work at least monthly or quarterly, depending on ticket volume, business criticality, and desk maturity.
Review cycle to evaluate performance, identify patterns, and determine what needs to be changed. The review should include the answers to the following simple questions: What is working? What is not working? What is changing? What will we do next?
Example XLA statement
This is a sample of a practical XLA statement:
The service desk will provide them with clear, timely and reassuring support, enabling them to return to work productively with minimal effort.
This statement is easy to say, easy to focus on the user and easy to measure. It can be backed up with satisfaction, effort and productivity indicators, but still allow space for operational controls.
Most frequently occurring errors
The typical error is creating too much of a ‘sla’. If the document doesn’t contain any response time, ownership, or escalation rules, it’s not really an SLA.
A second error is taking in feedback and not doing anything to change it. When users are asked for input and nothing is done, users lose trust in you and in your product. Measurement and improvement should be the bond in a strong XLA.
It is easier to write an XLA from scratch if you begin with the user journey, establish clear outcomes, and select measures based on real user experience. That translates to a service desk in which the agreement is more than just a performance metric. It’s a measure of support improvement.
