Your outsourcing contract needs XLAs, not just SLAs

I’ve lost count of how many clients have called frustrated, not because their managed services provider (MSP) was missing SLAs, but because meeting every SLA still wasn’t helping employees do their jobs. Tickets close on time, uptime stays above target, and scorecards are green across the board yet employees remain frustrated by broken processes, recurring issues, and support that feels transactional instead of useful.

The help desk resolves tickets quickly without solving underlying problems, so employees create their own workarounds. This is the watermelon effect: green on the outside, red on the inside. It remains one of the most persistent problems in outsourced IT today.

Patterns across major MSP relationships

I see this pattern across relationships with every major provider. These are sophisticated organizations with mature delivery capabilities that can absolutely hit the metrics you put in front of them. That’s precisely the problem.

Vendors optimize for whatever the contract measures. If your contract only measures operational outputs, that’s what your provider will focus on. They’re not doing anything wrong. They’re doing exactly what the contract incentivizes.

What I’ve seen time and again is that the contracts organizations signed five or seven years ago were designed for a different model of IT support, one that enforces compliance and control costs. They weren’t designed to drive outcomes or improve the employee experience, and in many cases, those contracts are still running.

Realigning a major MSP relationship isn’t simply a matter of telling the provider to do better. It requires changing what the contract measures. That’s where experience level agreements come in.

Why SLAs weren’t designed to measure what matters most

SLAs were built for an earlier era of IT. The logic was straightforward: define the service, establish operational standards, measure compliance, and apply financial consequences when performance falls short. It’s precise, auditable, and legally defensible.

But SLAs measure the process, not the outcome. A service desk can resolve 95% of tickets within the agreed timeframe and still leave employees feeling completely unsupported. An application can technically meet uptime standards while being so slow and unreliable that employees avoid using it. That gap, between what the contract measures and what employees actually experience, is where productivity leaks, morale erodes, and the business case for outsourcing quietly unravels.

I’ve sat in enough quarterly business reviews with providers to know how this dynamic plays out. The provider presents a polished scorecard. Every metric is green or amber. The client’s internal stakeholders raise concerns about employee complaints, escalating shadow IT, and department heads who have stopped submitting tickets because they’ve given up. The provider points to the scorecard and there’s no mechanism in the contract to address the gap.

That’s a contract design problem, not a provider capability problem. And it’s one that experience-based measurements like XLAs are specifically designed to solve.

The shift organizations need to make, and why it’s hard

When I work with clients on realigning MSP relationships, the conversation often starts with frustration, and the solution isn’t straightforward either. Organizations face real structural barriers to making this shift, like with baseline data, for instance. You can’t set meaningful experience targets without knowing where you’re starting from. Many of my clients have been operating on SLA-only contracts for years, sometimes with the same provider, and they have no employee experience data at all. They know ticket volumes and resolution times, but they have no idea how employees actually feel about the service.

Contract language is another issue. Major MSPs have mature commercial teams that are very skilled at navigating ambiguous commitments. Improving the employee experience isn’t a contractual commitment. A defined happiness score is, one that’s measured by a specific tool, and reported monthly with agreed escalation protocols when thresholds are missed.

Another is incentive alignment. The most common mistake I see organizations make is converting an XLA into a penalty mechanism. If the only consequence for missing an experience target is a financial deduction, providers will manage the number rather than the experience. The most effective XLA structures I’ve worked on combine penalties for persistent underperformance with shared gain mechanisms that reward genuine improvement.

Four ways to structure XLAs in an outsourcing contract

Based on what I’ve seen work across client relationships, there are four practical models for building XLAs into a contract. The right starting point depends on where the organization and the provider relationship currently are.

1. Commit to a defined experience score. The vendor commits contractually to achieving a defined satisfaction threshold. This is the most rigorous model and requires established baseline data on both sides. It works best when the relationship has been running for at least six to 12 months and both parties have experience measurement in place.

2. Commit to a digital experience score. Here, the XLA is tied to a broader digital employee experience (DEX) score that combines employee sentiment with technical telemetry. Providers like HCL and Cognizant increasingly support this model through partnerships with platforms like Nexthink.

3. Commit to continuous improvement. Rather than setting fixed thresholds immediately, both parties agree to a shared obligation to improve experience metrics over time, with targets reviewed and reset every six months. This is usually the best entry point for organizations that are new to experience measurement. It builds a data baseline, establishes a culture of shared accountability, and avoids the trap of locking in arbitrary targets before either party understands the benchmarks.

4. Commit to delivering the XLA capability. In this model, the provider takes responsibility for building and operating the measurement infrastructure itself. This works well when the client lacks internal XLA capability but still wants accountability built into the relationship from the outset. I’ve seen this work particularly well in new contract structures with Accenture and Capgemini, both of which have invested in building proprietary experience measurement frameworks.

What XLAs actually measure

Unlike SLAs, which focus on technical outputs, XLAs focus on human outcomes. The metrics I most commonly see built into client contracts include:

• Employee satisfaction scores
• Perceived lost productivity time
• Repeat incident rates for the same underlying issue
• Ease of getting support across different channels
• Task completion success rates
• Confidence in IT services overall

The goal isn’t to eliminate SLAs as systems still need uptime targets and response standards, and providers operate at a scale where those operational commitments genuinely matter. So the goal is to add the missing layer of whether or not employees feel supported and productive, not just if tickets are being processed.

The data infrastructure behind a working XLA program

Strong XLA programs depend on three categories of data working together. Getting this right is often where the real negotiation with providers happens, because data ownership and transparency are genuinely contested terrain in major MSP relationships.

Experience data (X-data): This is the human layer, how employees feel about their IT experience. It comes from pulse surveys, post-interaction feedback, and always-on feedback channels. Platforms like HappySignals, Nexthink, and Qualtrics are commonly used. One of the most important negotiating points I work through with clients is ensuring that this data is owned by the client, not the provider. Some MSPs propose operating the measurement platform themselves, which creates a structural conflict of interest.

Operational data (O-data): This is the traditional metrics layer already stored in ITSM platforms most common among our clients like ServiceNow or Jira Service Management. Most providers already produce this data and the value comes from correlating it with experience data, not treating it in isolation.

Technical data (T-data): This is the infrastructure layer comprised of device health, application performance, network latency, and endpoint health. Platforms like Nexthink and 1E collect this telemetry passively. When experience scores drop, correlating against technical data tells you whether the problem is the technology environment, the support process, or the service interaction itself. Without that triangulation, you know something is wrong but can’t pinpoint why.

The transparency problem

In my experience, the biggest failure point in XLA programs isn’t the metrics but transparency. When clients hide poor experience scores or providers obscure unfavorable data, the foundation of the XLA model breaks down.

I’ve seen MSPs manage the measurement platform and report improving scores, only for independent measurement to reveal a very different reality. The strongest XLA programs treat experience data as jointly owned, openly shared, and central to collaborative problem-solving.

Contracts create accountability, but governance drives improvement. Weekly working sessions, monthly reviews, and leadership steering meetings matter far more than scorecards alone. Building that level of transparency is often the hardest part.

The shift from service delivery to outcome delivery

The shift from SLA-only contracts to XLA-enabled outsourcing reflects more than a new measurement framework. It signals a fundamental change in how organizations define IT value. Cost and efficiency still matter, but leading organizations are now asking whether technology investments improve employee productivity, reduce frustration, and create better support experiences. That requires a different level of provider accountability.

MSPs can deliver experience-based outcomes, but they rarely prioritize them unless contracts demand it. XLAs formalize those expectations, and increasingly, organizations see them as the standard for measuring meaningful IT performance.