Most service desks have sat through this meeting. The monthly report is green across the board: tickets answered on time, resolved on time, satisfaction at 4.3 out of 5. Then someone from the business says, quite politely, that everyone they talk to thinks IT is slow.
Both things are true. The SLA measures what the service desk does. It doesn’t measure what it’s like to spend the day on that laptop.
People call this the watermelon effect, green on the outside and red in the middle. Experience level agreements (XLAs) are meant to fix it. They’re also at risk of becoming one more slide in the quarterly review, so let’s be clear about what they’re for.
What an SLA can’t see
An SLA is a promise about tickets. That’s useful, but it has three blind spots.
Most friction never becomes a ticket. Someone’s laptop takes four minutes to reach a usable desktop every morning. They stopped noticing months ago, and they’d never think to report it. It shows up nowhere.
A ticket closed on time isn’t a problem solved. If the fix was “restart and see how it goes” and the problem is back on Thursday, the SLA has just recorded two wins.
And the satisfaction survey only reaches people who raised a ticket, right after it was closed, which is about the moment they’re happiest with you.
What goes into a decent XLA
An XLA should describe what working life is like for a group of people, measured in a way both sides trust. We’d put three kinds of measure in it.
Something from the devices. Boot and login time, crashes, network drops, how quickly the apps people use all day respond. Measured on the device, not reported by anyone.
Something from the people. A short pulse survey, one or two questions, sent to everyone, not only to people who raised tickets. How people feel about their tools matters even when the telemetry looks fine, and sometimes it tells you the telemetry is measuring the wrong thing.
Something about repeat problems. How many issues came back within a few weeks of being fixed. This is the one that keeps a service honest.
Keep it short. Four or five measures you’ll actually look at beat twenty you’ll skim.
Agree the baseline before the target
The mistake we see most often is setting the target before anyone knows the starting point. “Experience score above 80” means nothing until you know the estate sits at 64 today, and the Manchester office is at 52 because of one bad Wi-Fi rollout.
Measure for a month first. Look at the spread between sites, departments and laptop models, not just the average. Then agree what better looks like, and by when.
Make it something you can act on
An XLA that only lives in the monthly report is just a nicer-looking SLA. The point is that when a measure moves, someone finds out why and does something about it. That means getting from “the score dropped for the sales team” to “it’s the new VPN client on these 200 laptops” in an afternoon, not a project.
It also means fixes should show up in the numbers. If you sort out the VPN problem and the score for those devices doesn’t move, either the fix didn’t work or you were measuring the wrong thing. Both are worth knowing.
For service providers, it changes the deal
If you run IT for clients, an XLA changes what you’re selling. You stop being paid for answering tickets quickly and start being judged on whether people can work. That’s a risk if you can’t measure experience. If you can, it’s an advantage: you can show a client improvement they’d otherwise never see, and you spend less time arguing about whose fault a bad week was.
Measuring it and fixing it in one place
We built Nanoheal so measuring experience and fixing what hurts it happen in one place. The experience score is patented, pulse-survey answers sit on the same boards as the device data, and when a number moves you can see which sites and device groups drove it, then switch on the fix for them. If you’re writing your first XLA, or rewriting one that’s turned into box-ticking, we’re happy to talk it through.