The service-delivery paradox

It almost sounds like a (romantic?) thing from the past. A service delivery manager who’s meticulously managing an agreed service level agreement (SLA) for a client, department or business unit. If you’re in the IT business, I’m sure you’ve heard some stories or two about SLA’s from hell or organisations wanting to implement immeasurable key performance indicators (KPI’s). Which by itself is a contradiction.

Meanwhile in India

During the height of the offshore outsourcing wave, an acquaintance of mine had a rather interesting experience with a certain Indian based company. He was reviewing some KPI’s in an SLA for his client. The KPI stated that the IT service desk in India had to answer all phone calls within 30 seconds.

But the SLA never mentioned anything about the outcome of those calls. Of course, all KPI’s where performing at a 100% level in the appropriate dashboards. But nobody could tell him what the level of customer satisfaction or rate of resolution was. In the end he found out that the IT service desk couldn’t even measure first response times in the first place. The delivery of the SLA was only partial and the measurement of the KPI a downright joke. Off course, the unknowing client was promised something else.

Closer to home…

This next example I’ve witnessed from first hand. The Dutch National Police, Fire Brigade and Ambulance Services where to be equipped with a new digital communication system: C2000. The old, analog system – which you could easily intercept with a portable FM radio – was to be phased out.

A large tender was set up, and eventually won. A big role out and training programme ensued. But then someone had the quite unpleasant experience of losing communication inside a building. It turned out that the C2000 system didn’t always work indoor properly, prompting the Fire Brigade to switch back to their old analog communication gear for understandable safety reasons. This lack of network coverage also occurred in hospitals, tunnels and other buildings.

What was the case? The tender didn’t explicitly state that C2000 was supposed to work indoors, so suppliers of the communication equipment didn’t offer that feature. Which was regarded later as ‘extra’ rather than ‘essential.’ When margins are thin and competition is high, a supplier won’t be eager to invest in an extra feature the customer didn’t specify. Makes sense right? Now try explaining that to a public safety professional who is confronted with that issue on street level.

Overpromise, under deliver

So we’ve concluded that these service-delivery paradoxes happen more often than one may think. It’s a classic situation of sales gone wrong. Either by writing tenders so specific, that a competitor even risks losing a bid when he doesn’t meet requirements exactly. Or by overpromising but under delivering in the sales process. Wooing ill-informed or unknowing customers to buy products or solutions. Luring in prospects with the promise of saving a lot of operational costs, getting a quick return on investment and more efficient operations. After the deal is closed, sales moves on while the service delivery manager can start managing this operational nightmare.

Some suppliers even make money by selling low priced and thus attractive but tightknit contracts for a very basic level of (IT) service, wherein prices fly to the moon if anything happens that cannot be solved by first line support. Reversed gamblers fallacy, I’d say. But are you willing to place your bet on a contract like this?

What’s (not) in the contract?

I personally don’t believe in these kind of SLA’s. They entirely lack service, to begin with. These ‘level agreements’ mainly uphold nasty discussions between clients and suppliers about ‘what is or is not in the contract.’ The first expecting the agreed level of service, the latter knowing they can actually never deliver it..

I do believe in experience level agreements (XLA). This new kid on the block is all about measuring user experience and customer satisfaction. Or as Giarte, founders of XLA, put it: “[An]… experience level agreement is a mind set and tool box to rethink enterprise IT. It applies design thinking to combine ‘tech’ and ‘touch’. Abstract drivers of success become tangible and manageable”. I like it!

X stands for extra

Keep in mind: XLA’s don’t replace SLA’s. XLA’s are in addition to SLA’s. So you could say that the X also stands for ‘extra.’ In my first example, the SLA was probably met for the full 100%. In an alternative Excel realm somewhere in India. The XLA, however, would be somewhere in the below zero region. Just like the temperatures in the Netherlands were last week. XLA forces suppliers out of their role of just being a simple, ice-cold supplier who you only distrustfully talk to when your (legacy) IT systems aren’t working. Sometimes even being the same (legacy) systems the organisation used to run themselves, before outsourcing it to an IT management company.

XLA’s are all about establishing long term partnerships and thus mutual trust when running IT operations. Starting from a strategic perspective, rather than an operational one. My regular readers will know I’m a keen advocate of partnerships and co-creation opposed to regular client-supplier relationships. Especially since the fact that organisations running legacy IT systems will need to reduce technical debt and improving customer service and business continuity by transforming in to organisations that are able run more flexible, cloud based solutions.

How to implement XLA

Are you interested in implementing an XLA into your business? Here are some things to keep in consideration. An XLA usually consists of the following of the following elements:

• Strategic goals
• An understandable translation of those strategic goals into indictors;
• A solid determination on how these goals are to be measured;
• A dashboard which includes customer and end user values, based on indicators;
• A conversion table that translates individual indicators to a more generic score on Customer satisfaction, end user satisfaction and total service level.

For the dashboard, I suggest you use or implement a real time dashboard tool. Need advice or assistance with these steps? I’m happy to see what I can do you for you.