From SLA to XLA: measure what users experience, not just the target

It happens to many IT organizations: every SLA report is green, and yet users complain. Incidents get resolved within the target, availability is fine, but the experience is poor. That is called the watermelon: green on the outside, red on the inside. An XLA, an experience level agreement, turns it around and makes the user's experience the starting point. This article shows what an XLA adds to your SLAs and how to start without building a measurement circus.

Why a green SLA can coexist with angry users

An SLA measures what the IT organization does: how quickly an incident was picked up, how often a system was available. Those are useful agreements, but they say nothing about how it felt for the user.

An incident resolved within the eight-hour target can still be a lost workday for the user. A system that was 99.5 percent available may have been down exactly during month-end closing. And a user who had to call back three times for the same problem counts in the report as three neatly handled incidents. The target was met, the experience was ruined.

What an XLA does differently

An XLA records agreements about the experience instead of only the execution. Not "incidents are resolved within eight hours", but "users can get back to work quickly after a disruption and rate the handling at a seven or higher on average".

That requires different measurements. Alongside the process side, you measure how users perceive the service: a short question after handling, a periodic measurement per service, and signals from the work itself, such as repeat incidents about the same topic. More importantly: you discuss the outcomes and attach improvement actions to them.

An XLA does not replace your SLA. The basic agreements about response time and availability remain necessary. The XLA lays the real question on top: did it actually help the user?

How to start without a measurement circus

The trap with XLAs is starting too big: measuring everything, building dashboards, and concluding after six months that nothing changed. Small and concrete works better:

1. Pick one service or audience. For example incident handling, or the services for one specific department.
2. Ask one experience question. A short question after handling is enough to start: were you helped well, and what could be better?
3. Discuss the outcomes monthly. Not as a grade, but as a source of improvement actions. The open answers are worth more than the average.
4. Pick up one improvement per month. Visibly improving based on feedback is exactly what gives users trust, and the team energy.

Only once this cycle runs is it worth formally recording experience goals as an XLA. The agreement follows the practice, not the other way around.

What it delivers

Steering on experience takes the discussion away from reports and brings it back to what service delivery is for: users who can get on with their work. Teams see what their work achieves instead of only whether the target was met, and improvement actions come from real feedback instead of assumptions. Quality becomes something you watch grow, not something you defend afterwards.

Frequently asked questions

Can we scrap our SLAs then? No. SLAs remain useful as basic agreements about response times and availability. The XLA adds the experience side the SLA misses. Together they tell the whole story.

Will users not get tired of all those surveys? Only if you ask too much and too often. One short question after handling, plus a compact periodic measurement, is more than enough for most organizations.

Do we need special tooling for this? Not to start. Most ITSM tools can send a satisfaction question after handling. Begin there and only look at additional tooling once the improvement cycle is in place.

Want to move from green reports to services users are genuinely happy with? book a call and we will look together at where the experience and the numbers diverge.

Further reading

• Service-level agreement (Wikipedia)
• Customer experience (Wikipedia)