To Journey Map or not to Journey Map? Now that is the question.
But it was only one question of many during our October CX Webinar Q&A session.
User Journey Maps or Service Blueprints? Which is better for linking customers and employees with the processes and technology used to deliver a product or service?
Our presenters had plenty to say on this topic. And our audience had plenty of questions to ask.
Here’s a brief overview of the answers you can find in this recap.
- What is the difference between Journey Maps and Service Blueprints?
- What is the Three Ring Approach?
- How can a service blueprint draw out perceived pain points that are in a journey map, but not real or realised?
- Should you create future state journey maps?
- What does it mean to Validate a Journey Map?
- When should you use a service blueprint map?
- Is it better to create a customer journey map featuring multiple customer personas or a map for each persona?
- Watch the Full Video
What is the difference between Journey Maps and Service Blueprints?
When we talk of the basics of journey maps what we’re looking at are the interactions that a customer experiences as they use a product or service.
Which is fantastic if you want to be able to map out that experience. You want to be able to look at that empathy perspective, and we want to be able to map their pain points as they experience them.
But one thing that we have become aware of, particularly during COVID, is that there are a lot of things that happen in the background before a customer even experiences that issue that may be leading to it.
And that’s one of the reasons why we start talking about service blueprints.
Because what service blueprints can do differently is they really help connect the people, being the customer and the employees with the process and the technology used to deliver that service.
It’s that simple.
What is the Three Ring Approach?
When talking about the interactions between a customer and an organisation, I use a three ring approach and service blueprints can represent this really well.
The outer ring is the customers, they’re the people who are using your product and service.
The next ring is essentially the front of house. The front stage perspective. Now that can be the sales team. that can be the customer service team. Or even the website that they use to interact with your organisation.
But we also have that backstage perspective as well, that inner circle. And that’s what drives a lot of the mid-circle actions.
The customer rarely sees it. or even aware of its existence.
It’s around how those systems are used, and how data is inputted or extracted.
And what we want to be able to see is when those pain points, occurred from the customer’s perspective, and what steps in the process could have led to it occurring.
And that’s essentially what service blueprints are.
How can a service blueprint draw out perceived pain points that are in a journey map, but not real or realised?
One of the best ways of drawing out perceived pain points is by identifying the root cause and the steps in the process.
If I use this example for when we go through the customer journey, we only identified six core pain points across the entire journey from the customer’s perspective. And these are things that the customer perceived as pain point.
When we got into the service blueprint side, we got into the element of the blockers and delays that were causing some of those pain points for the customer.
So, in this journey, one of the hidden pain points was the customer being able to book an appointment.
While it wasn’t a major pain point for the customer or one that they complained about, it was one that we identified when we went back and spoke to customers, particularly prospects who didn’t convert.
We started identifying these pain points and asking ourselves is this a pain point? Is this something we need to be conscious of? Or is it something that might not necessarily be the problem?
Ironically, our client was using a sophisticated voice of the customer system, and they never picked up on this pain point until we started going through this process.
We identified parts in the process that we thought might be pain points or causing a pain point and that could have been a lead contributor to converting sales in the first place.
Similarly, however, we need to be conscious of what we can control. Customers might perceive something to be a pain point, They can be steps in the process that can’t be avoided and just ‘the nature of the beast.
In this journey, a lot of customers complained about the time required to get feedback or updates on the process.
We were able to go down and identify what the cause of that pain point was. We assessed it, and found that there was nothing we can do about it. Because this is something done by a third party organisation (a government agency) and there was no way to speed it up.
However, while we knew we couldn’t improve the time taken, we could at least do a better job of communicating the possible delays and managing the expectations of the customers.
Should you create future state journey maps?
I love that question. Peter, we always try to map in the current state.
When you’re collecting information, we don’t want to develop a service blueprint through workshops to what they think is an opportunity for improvement.
A service blueprint is a guide towards a future state map.
When we develop a service blueprint of the current state, we uncover at the pain points. We then sit down with the client and look at opportunities for improvement.
That can be something that might happen in the next 12, 18 or 24 months, or they’re immediate, something we can act on now.
Once we have the opportunities for improvement, we can alleviate that pain point. Then we can recreate a future state service blueprint on what that process might look like.
But I do stress the importance of never trying to do a future state service blueprint without mapping the current state first.
It becomes hypothetical, and you haven’t really identified the causes that are in the current process.
It’s like jumping into solution mode instead of finding the root cause.
What does it mean to validate a Journey Map?
So validating the map for us means going back and asking the client and the members and the people doing this work.
We’re very conscious that we’re new to the process and we’re not experts in the client’s business or service yet.
We come in, we sit down, we create the workshops, and we ask the questions.
Sometimes when we collect the information, people kind of give us X and Z, but they forget about Y (why or how they got from X to Z).
When we go back, we get them to run through the maps again and make sure they’ve actually given us all the steps in the process. It takes a little bit more time, but it makes a more accurate process.
When should you use a service blueprint map?
It’s one of the biggest and most regularly asked questions when we are talking to
clients. Journey Maps or Service blueprints? And for us, it’s really simple.
If you’re looking to map out the perspective and the journey of the customer to show how they interact with your business, use a journey map.
They are a great way for people to see how customers perceive and use your product and service.
However; if you want to get into identifying problems and pain points, that’s where we always suggest service blueprints.
You do have the option of using things like process maps as an alternative. Process maps are fantastic. I spend most of my career making process maps and documenting things out in detail.
But one thing that we always found was that it’s very difficult to get buy-in from people who don’t understand what process maps are or how to read them properly.
Service blueprints give you that leg up. And one of the things we’re always very conscious of is being able to give people that extra tool to be able to utilise them
in your organisation, identify pain points and get stakeholders on board. Which is probably one of the biggest benefits.
Service blueprints are a combination between journey maps and process maps. They’ve got the best parts of both.
You have the customer at the centre, and at the same time, you’re highlighting the employees and systems that are creating the interaction.
So I think it’s a great tool.
For us, if you want to be able to identify pain points and identify opportunities for improvement, Service Blueprints are probably the best way to go.
Is it better to create a customer journey map featuring multiple customer personas or a map for each persona?
I think there are different trains of thought depending on who you’re talking to about personas and service groupings.
When you look at a persona in a journey map, it gives you some indication of how somebody is going to use a product or service.
But when we’re overlaying with the process, you almost have to do one for each persona or just take the persona out of it and go with the standard process.
Nine times out of ten times, when you look at internal services and internal delivery, the way people deliver the service or the product is not going to differentiate depending on who the persona is.
They will use it differently 100%. They’ll interact differently. But how you create it, and how you deliver it generally doesn’t change.
Usually, maps will tell you how people are using a product or service. But when it comes to the internal steps in the process and overlaying them, I take personas out of it.
Still have questions? Ask our consultants directly