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.
Customer Experience Eye 