Where are you dropping the baton?

Do you remember the mens 4x100m relay at the Athens Olympics? Great Britain were hopeful of a medal, but the USA were strong favourites with a team that included the individual 100m and 200m Gold medallists, as well as the 100m Gold medallist from the previous games.

As Steve Cram said in the commentary,

“…if they don’t drop the baton they should win it, easily.”

Well, they didn’t quite drop the baton, but they certainly muffed one of the handovers pretty badly. The GB team, by contrast, had three almost perfect handovers, and just held on to win a thrilling finish.

And that’s why I want to talk about process maps.

What’s the link? I must admit that process maps can play a useful role in organisations, but in my view they often cause as many problems as they solve. To quote the process consultant Ian James:

“The irony is that the biggest opportunities for process improvement never show up on a process map.”

https://theprocessconsultant.com/process-improvement-handoffs/

I couldn’t agree more, and in particular what they are prone to do is to focus people on performing their own job well, rather than on delivering the best possible overall performance.

“I’ve done my bit”

You could look at a sprint relay race as four individual races glued end to end. If each of your runners is faster than the people they’re up against, then the team is bound to win, right? All they each need to do is concentrate on winning their leg.

As the USA team found out, that doesn’t always work.

If everyone concentrates only on “doing their job”, as defined by their little section of the process map, that tends to mean that they get very good at on-paper efficiency and meeting all their SLAs. Is that a bad thing? It can be if their efficiency comes at the expense of the customer experience.

The customer view

One of the many reasons that customer journey mapping is such a powerful technique is that it forces you to get away from an internal view of the experience. That has many benefits, but when it comes to improving processes the most immediate gain is that it forces us to see where the process stalls or derails completely from a customer’s perspective.

Very often these pain points turn out to coincide with handovers, whether implicit or explicit. Team A has finished their job, Team B hasn’t started theirs yet, and meanwhile the customer, who has no idea that Team A and B even exist, is left in limbo.

Handovers as failure points

Why is it that handovers are such a common source of failure? One reason is that it’s a point at which key contextual information can be difficult to transfer. It’s interesting, for instance, how heavily used the “Notes” field of many CRM systems is, but that’s hardly a robust process.

Another is that the team making the handover may have a poor or incomplete understanding of what their colleagues need to know. In one service blueprint workshop I facilitated for a client it emerged that Team A was spending hours reformatting data to transfer to Team B, who spent hours reformatting it into the format they needed (quite similar to the original). The looks on their faces as the scale of wasted effort dawned on them were quite memorable.

Then there are the times when customers are simply forgotten about. Team A has done its job, but somehow the baton is dropped completely and Team B never knows that it has a job to start. This can happen with shared mailboxes, when emails mysteriously fail to arrive (email really isn’t robust enough to do the job we expect it to do), or when someone is unexpectedly off sick.

Diagnosing problems

These are just a few of the more common problems, so how do we set about rooting them out of our processes? The starting point, as we’ve seen, is to use customer journey mapping to understand where things are going wrong from a customer point of view.

Then we need to join that view with an internal understanding of what actually happens. The service blueprint, as I’ve discussed before, is my favourite tool for this.

But the magic isn’t in the tool. If you simply document what is supposed to happen, then a service blueprint presents the same danger as a process map—the handoffs will be hidden.

That’s why it’s so important for everyone to be involved at the same time. It’s by talking the journey through, starting from the customer’s point of view, that you reveal these tricky handovers.

So the lesson is: never run your service design workshops one department at a time; always try to get everyone in the room together. That gives you the best chance of smoothing out the handovers, creating the best possible customer journey.

A smooth handover may be more important than running the fastest possible leg.

Design experiences, not processes

I’m a big fan of the tools and mindset of service design thinking.

Design thinking is as an approach to developing products and services that help customers get things done as easily as possible.

It’s great to see it thrive, as more and more organisations are using tools such as user stories, customer journey maps, and service blueprints to bring their experiences under control.

Can you sense a “but” coming? There are two.

Whose viewpoint?

I think there is often a tendency to rush too quickly to the sexy design tools, like journey maps. It’s quite fun to sit in a room with your colleagues and start slapping multicoloured sticky notes on the wall, but it’s of limited value unless you make sure that the customer viewpoint is properly represented.

Good design requires empathy, and that rests on research, so start by immersing yourself in the world of the customer. Only when you’re loaded up with insight should you break out the sticky notes.

“What people say and what people do provide clues for what people want to do and how people want to be.”

Jon Kolko, ‘Well Designed’

Experience is not process

A related problem is that organisations are prone to regurgitating their process maps in service design sessions. One of the reasons that I like to use a service blueprint for internal workshops is that it allows participants to capture a high level view of the process while making it clear that the process itself is invisible to customers.

The real customer experience is what happens inside customers’ heads.

It’s not what you do, or even what they do, but how they feel that counts. What we’re looking for is not to replicate your process maps, but to understand the system that creates customer experiences (both within your organisation and context in the customer’s life), including all of the (often tiny) details that make a difference to how the experience makes customers feel.

“Hidden in the details of real life is the structure of the day and how activities play out within it, why we do what we do, who we do it with, how we feel about ourselves when we are doing it, the culture we are operating in, and more.”

Karen Holtzblatt & Hugh Beyer, ‘Contextual Design’

 

Why ending well is so important

Our memories and perceptions of experience are much less concrete and rational than we like to imagine.

If you don’t accept that, go away and read Kahneman or Ariely, and then we’ll talk.

One particular mental bias that should be at the forefront of our minds when planning customer experiences is the “peak-end rule“.

Simply put, this rule states that we judge an experience^* based on how we feel at its most extreme point and at the end. There are subtleties around the length of the experience, and how long-lasting the effects are, which you can read about in the Wikipedia article.

What I want to focus on is the importance of ending customer journeys well (and the end may well be more important than the peak). Whether it’s the big-picture of a customer lifetime, the detail of individual interactions, or the many journeys of all sizes in between, we often let the customer experience peter out instead of ending with a bang.

This is madness.

In many cases the single most powerful change you could make to seize control of the customer experience would be to ensure that you finish strongly. Schedule a call to make sure the customer got what they needed. Send a thank-you note. Go out of your way to make their transition to a new supplier seamless.

The peak-end rule means that you’ll leave the customer with a powerful positive memory, and that’s bound to pay for itself.

 

---

* Trying to get psychologists to define what exactly we mean by “an experience” is fun, but the word does seem to correlate with a consistent mental concept shared by all of us.

User stories & customer journey mapping

A big mistake that many organisations make when they try to map the customer journey is that they stick too close to their own perspective.

The result may be a customer view of their process map, but it’s not a true customer journey map.

Why not? The tell-tale problems are:

• Too much detail
• Ignoring context in customer’s life
• Focused on products, processes & touchpoints
• Starting too late in the journey
• Finishing too early in the journey

How can we overcome this tendency to let the inside-out view dominate? The best way is to use qualitative research and allow customers to lead the creation of the journey map.

User stories are a really useful tool to make sure you approach the journey with the right mindset. They’re normally written in the form

As a__________ I want to__________in order to__________.

Doing this will allow you to stretch your view of the journey, so that you start when the customer became aware of their need, not when they first got in touch with you. This more accurately reflects the customer experience, and opens up opportunities for innovation.

It also puts the customer’s goal (not your product) front and centre. This helps you to make sure that the experience you design is addressing the right problem, and opens you up to the possibility of solving it in new ways.

“People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.”

—Theodore Levitt