When is a Service Not a Service? What ITSM Can Learn from Uber

A recent trip – OK, failed trip – with Uber got me thinking about not meeting customer expectations in IT service terms. Or to be precise, when a service isn’t a service. Or at least it isn’t a service that can be consumed despite it being “available.”

When Uber Was “Available” but Useless

We live just north of Peterborough (in the UK), which is a 15-20-minute car drive from the city center. Uber belatedly started its service in Peterborough a few years ago, but it didn’t work where we live. But then it did, or at least I thought it did.

This article takes my less-than-stellar experience with Uber – OK, the Uber app – and considers it through an IT service management (ITSM) lens. Hopefully, it might also make you think about the services your IT organization offers and delivers, and how they are perceived by your end-users/customers.

A Real-World Example: When Uber Doesn’t Deliver

As far as I know (I must have read it somewhere), Uber doesn’t offer a taxi-like service. Instead, it can – via an app – put people who need a lift in touch with those who can provide one. You could say that Uber merely makes the connection, but – crucially – it also sets the price and, by extension, an expectation (at least on my part).

I can request an Uber from my home. I will get told the cost (by the app). But as this article explains, I might get little more (other than frustrated).

Ultimately, while an Uber driver bringing me home from Peterborough can “bend my ear” about also using Uber for lifts into Peterborough, the available service (in terms of connection, rather than travel) is not necessarily a usable service (in that I don’t get my desired outcome or value).

When is a Service Not Actually a Service?

I needed to collect our car from Northampton – it’s a long story. Taking a train or a bus was a two-plus-hour trek rather than a one-hour car ride from my home. For example, the train journey involved going in and out of London – imagine it as the other two sides of a triangle for the trip I needed.

However, I could get an Uber-requested “lift,” or at least I thought I could.

I spent an hour trying to get a driver to pick up my job at the price Uber set. It was an hour wasted (although I did do other things while trying). I could understand it, though – the driver would likely need a paid journey back to Peterborough to make it worth their while (especially at the price set by Uber).

To me, as the customer, I wrongly thought I was being offered a service at an agreed-upon price. But alas, I wasn’t – I couldn’t actually buy it, because no one wanted to deliver it. You could argue that the Uber service was working, but I didn’t get the “lift” service I wanted (and needed).

However, It Wasn’t Just a Long-Distance Issue

I tried the Uber app at home again. Yes, I could request a driver to take me to collect my car from north of Peterborough city center (a 15-minute trip). But again, I wasted circa 20 minutes trying to get a lift at the price Uber had set.

You guessed it, I couldn’t get anyone to pick me up, and my Uber passenger score was 4.89, so it’s not like I’m the “passenger from hell.”

Was the Issue the Price or Efficiency (or Perhaps Inconvenience)?

The honest answer is that I don’t know, as this likely depends on any drivers close enough to take the job.

Would I have happily paid more? Yes. Did I know how to express this on my Uber app? No.

I was stuck with wanting to engage a service that I couldn’t buy. The app kept offering it to me (as its service), at roughly the same price, but couldn’t deliver.

Other than wondering how I was going to get to my car (which wasn’t really difficult once I ruled out Uber), I couldn’t help but think about the parallels with ITSM and IT support. Do we ever offer services that we can’t deliver? Or do end-users/customers have different expectations of the service they’re engaging with?

Sorry, it’s just how my mind works.

What ITSM Can Learn from Uber

If you’ve ever been to an ITSM conference or read a thought-piece on digital transformation, Uber was likely held up as a poster child for using technology to improve upon and perhaps reinvent a manual way of working. I know I’ve experienced these. It seems we, as a community, can learn a lot from Uber’s success story.

But what about when Uber “goes wrong”? Which can, of course, include “user error” – given that I might have been able to override what I was offered to get what I needed.

Expectation Management in IT Services

Expectation management is a good place to start. I expected to get a lift to collect my car (as Uber serves my area and I was offered a price) and, thanks to many successful past Uber journeys, I also expected it to be an efficient and frictionless experience. Sadly, it wasn’t. It was an offered service (or was it?) that, in reality, wasn’t available.

Had my expectations been managed better, i.e. being warned that drivers might not want to collect me for the quoted price, I’d have simply shrugged and immediately moved on. But perhaps I would never have tried or returned to Uber knowing this?

I know part of the issue is me and my expectations. The more I think about the mechanics of the Uber app and service, the more I understand that the price is merely what Uber thinks is fair rather than what a driver would do the job for.

Expectation management has long been an issue in ITSM, especially post the so-called “Consumerization of IT.” But hopefully, my simple example will get you thinking about the occasions when your IT service delivery and support don’t work as expected. I’m thinking about the potential frustration and lost time with chatbots in particular. Can you see this happening and make changes to reduce the frustration and lost time?

Ease of Use vs. Outcome Delivered

The Uber app is designed for anyone to use without training or manual reading. It’s designed to be simple.

But what good is this simplicity if a user can’t get the outcome they need (and are willing to pay for) from it?

Again, whether it’s an employee-facing chatbot or another capability designed and delivered by one group and used by another, there will likely be instances where either the capability or the user doesn’t perform as intended.

These scenarios will happen. After all, we can’t (and can’t afford) to plan for everything. But in the case of my app-use issue, surely there’s data to show that the issue persists and that something can be done, even if only a “fudged workaround.”

So, can your IT organization identify what’s not working well and take appropriate action? Or is it too busy celebrating what works well to notice any issues? It all comes down to data, analysis, metrics, and insights.

Metrics That Actually Matter

Whether the data related to people like me (requesting Uber rides in “fringe” locations) is seen as exceptions or as a metric, surely the data (and from all around the world) is sufficient to show that it’s an issue.

Am I being naïve to think that if it’s not financially (or logistically) viable to provide a reliable service to “fringe” areas, you don’t offer that service? Surely, in the case of Uber and my location (and many others globally), the data shows there’s an issue that needs to be addressed. A service is offered that might waste people’s time and fails to deliver the required outcome.

When a Service Isn’t a Service

Right now, while at home, I believe I receive a “Only if a driver is local and wants to pick you up” service from Uber (and the drivers that use the platform). Although I haven’t managed to consume it yet. It’s been a while since I heard the ITSM adage of “a service being available but unusable” – maybe that applies here?

Personally, I’d have preferred to have my expectations better managed up front, and I can now only treat this Uber “service” as unavailable in my home area going forward. Or, leaning into the above adage – it’s available but unusable.

In a world where it doesn’t take much to lose a customer (although I’ll still likely use Uber when in a city), it seems an odd situation. Some new customers might experience this “fringe” situation as their first Uber experience; it’s not a great one.

It reminds me of what I’ve said about the IT service desk for nigh on the last two decades, one bad experience can be enough to prevent further contact (no matter the reasoning). And how often is the issue related to communication, including expectation setting?

I’m sure there are many more learnings we can take away from my simple, and perhaps silly, Uber issue.

When is a service not a service? For me, it’s when you can’t consume it when you think (and are led to believe) you can. Part of this is expectation management, and I’m sure in an ITSM context, this is the root of many service dissatisfaction issues.