Is IT outsourcing moving from SLAs to XLAs?

7 Min Read

The sweeping powers of digitization and customer-centricity are shaping the business world today, and these two trends have developed an alarming correlation. The more people rely on technologies, the bigger the impact of a poor customer experience.

Users don’t typically remember the characteristics of a product, but they do remember how they felt when using it or when it failed in a critical moment. That means IT solutions should now cover both technical and user experience expectations.

This state of things pushes IT outsourcing companies to pivot from service-level agreements (SLAs) to experience-level agreements (XLAs). Let’s discuss the differences between them and reflect on the possibility of XLAs replacing SLAs.

What are XLAs?

XLAs are contracts concluded between IT service providers and customers. Providers use them to establish quality levels of using the solution in clear terms for users. In other words, XLAs attempt to provide better IT experiences with a focus on end-users.

XLAs use hard and soft data to measure user satisfaction levels. As a result, IT service providers introduce customer satisfaction KPIs as a combination of functional and emotional interactions with the solution. This allows them to constantly improve the technology and optimize the user experience.

XLAs vs SLAs

To understand why the existing SLA practice has become subject to modification, we need to look at it closer.

An agreement designed to mitigate IT outsourcing risks, SLAs define the service level the customer expects from an IT outsourcing partner. SLA relies on such metrics as service availability, capacity, defect rates, and security. It means the solution can meet business-level requirements without providing guarantee end users will be happy with it. For instance, the service is available 99.5% of the time as per the concluded SLA, but users can experience occasional critical outages or extremely slow performance during peak times.

For this reason, growing demand has appeared for modifying SLAs. All to factor in user experience and measure business outcomes from both the business and user perspectives.

How to quantify XLAs?

Because SLA metrics are quantifiable, everyone easily knows whether the contract requirements have been met or not and can then administer the corresponding penalties. But XLAs measure an intangible concept: user experience. How do you measure something qualitative like this?

To deal with this challenge, companies can measure the following data:

  • Hard data looks at IT performance analytics, the product’s impact on user productivity, user interactions with different components, and such.
  • Soft data focuses on user sentiment analysis, issue statuses rated by users, and user feedback. As user evaluations can be extremely biased (users can have different perceptions of such attributes as slow or critical), the common definitions of problems should be clearly defined.

Each experience category accumulates a score that helps measure service outcomes and user experience. It enables the search for components causing a poor experience or slow adoption. This also helps evaluate the overall experience and defines the probability of a customer recommending the service provider to others.

XLAs can also drive the shift from penalties to continuous improvement using closed-loop feedback cycles. When users are dissatisfied with some service outcomes, they can submit their problem and get it fixed. Such an attitude results in boosting their satisfaction levels throughout the project.

XLA challenges

As XLAs attempt to measure user experience, IT service providers will deal with lots of subjective and biased evaluations, often ending up in a losing position. For example, a few instances of a poor experience can cast a shadow on the overall project. These situations force a service provider to apply additional efforts to change this perception. Otherwise, the customer can channel this negativity in their review or recommendation.

Other users will be reluctance to provide consistent and sufficient feedback, especially with positive outcomes that are often taken for granted. As a result, a score can gravitate to lower indicators even though the majority of users are satisfied yet prefer to stay silent.

Service vendors need to propose XLAs to those customers who have already established a feedback routine with their users, be it consumers or employees. Users should be encouraged to provide their feedback regularly across different touchpoints. In this case, there’s a low chance that a few cases of a negative experience can skew the overall metric. What’s more, an XLA itself can promote feedback collection by making it a binding requirement.

In search of a healthy mix of XLAs and SLAs

SLAs define IT service success, focus on the expected quality of service, and outline the work to be done. This effort turns cooperation between service providers and their customers into measurable outcomes. SLAs are here to stay, but it has become clear by now that they need to evolve and accommodate user experience quantifications.

SLAs ensure that all kinds of technical issues are solved quickly and maintain the minimal service level. However, they aren’t geared towards optimization and proactivity to help avoid similar issues in the future. Business leaders understand that users make a product a success, so their experience matters. Companies couple SLAs with XLAs trying to change IT service motivation and focus on improving user experience.

Summing it up

The customer experience rush affects IT outsourcing too, giving rise to the new concept of experience-level agreements. Traditional SLAs will keep measuring the technical side of cooperation between service providers and customers. XLAs are here to attempt to measure and improve user experience.

Share This Article
Ivan Kot is a Customer Acquisition Director and Solution Consultant at Itransition, focusing on business development in verticals such as eCommerce, Business Automation, and cutting-edge tools such as blockchain for enterprises. He began his career as a developer, taking different positions in both web and mobile development projects, and eventually shifted focus to project management and team coordination.