If you've read our article about customer journey maps, you should already have a pretty good understanding of what to think about when creating a new product or service. But if it left you thinking "this is great and all, but how does this translate into actual, practical, implementable steps for my team to take?", maybe what you want is a service blueprint. In this article, we'll cover what it is, what it contains, and what it's good for.
How do I know I need a service blueprint?
You've conducted your user research. Customer interviews, maybe even a co-creation workshop or two.
It probably looked something like this.
Out of what you learned, you've created user personas. You've named them, thought about what they look like, assigned them a little avatar. You've spent so long thinking and talking about them, you feel like you know them.
You've put yourself in your customers' shoes, imagined their life and the part your product might play in it.
Maybe you've even made a customer journey map – hopefully with Narrandum, but if you just used a journey map template you found online, that's a great start.
We can't let all this great work go to waste. It's time to turn your research and knowledge into the foundation of the service you will build. To make a single, comprehensive artifact for everyone to refer to. Every team member, every stakeholder. No matter whether they're a product owner, coder, designer or other expert, this will be their guiding star, showing them not only what needs to be done, but even more importantly, why.
It's time to make a service blueprint.
What does a service blueprint look like?
At its simplest, a service blueprint is a great big table.
Like this one.
The columns of this table represent the different stages of the customer journey. Exactly what those stages are is up to you. Typically, they will cover every key moment of the customer experience, starting from when the customer first becomes aware of your product or service, through choosing it, using it, and ultimately moving on from it.
Each row of the table is a distinct layer of your service. Starting at the top with the most abstract information, to the most concrete and specific at the bottom. Each layer is derived from the one above it, and built on the one below it. By looking down a column, we can see, step by step, what it takes to get from the inside of the user's head, to the code we write or the things we manufacture.
What information does it contain?
One of the nice things about a service blueprint is that it can be as high-level or low-level as you like, and you can add detail to it as your project develops. You don't have to complete it all at once. In fact, we suggest that you don't. Just use it to capture what you know as soon as you can, and build on it, layer by layer, as you learn more. It's also more than OK to go back and change it as new information comes to light.
So maybe at first all you have is the outcomes of your user interviews. But even this is enough to get started. You can map out the customer journey step by step, and for each stage you can record the user's thoughts, wishes, needs, and goals. Now you have the first layer of your service blueprint, and you're underway.
Remember previously when we mentioned that each layer is derived from the one above it? Now's the time to see how that works. For each stage, look at the users' thoughts that you've captured, and think about what those thoughts might cause the user to do. Voila, you have a layer of user actions. Repeat this process with the actions, and you'll have a layer of events - things which happen as a result of the user's actions.
And so on we go, down the chart. These actions and events are where we might come into contact with the user. We can start thinking about touchpoints and communication channels through which we can find each other. These could be physical or digital, human or artificial, depending on what the user needs and expects.
Now we're getting somewhere. We're at the point where the user ends and the service begins, and this is where we can start to get into the specifics. Look and feel, tone of voice - all of these can start to take shape now. And these, in turn, will inform the shape of the tasks and processes which underpin them, and ultimately the technology stack we choose to implement them.
The magic question
You can probably see that the blueprint moves steadily from the inside of the customer's head to the zeroes and ones of software and hardware. The way that we figure this out is by asking a single question, over and over again:
"How do we provide that?"
Let's take a look at an example scenario.
The customer is feeling confused. They're not sure what to buy. They need to compare different options so that they can choose the one they need. To do this, they are most likely at home, on their laptop, switching between browser tabs. They are looking for clear, easy-to-understand information that will give them the reassurance they need to purchase with confidence.
The best way to give the customer what they need, in the way that they need it, would be a website. This site should have a clean design, and use language which is open, transparent and straightforward. We will provide clear calls-to-action so that the user can easily see how to proceed when they're ready, but we won't make them feel pressured.
Just having these criteria in mind can help us decide on all kinds of specifics. Perhaps a comparison table is the right approach. Or we could even allow the customer to choose different items to compare. The type of information to be presented in this table can even determine the fonts, colours and layouts we use. These and many other considerations will guide us towards the right technology choices when the time comes to build and deploy.
Everything in its right place, and a right place for everything
The most important advantage of using a service blueprint is that every decision we make, every thing we create, can be explained and justified by referring to the chart. And it all comes from starting with what's in the customer's head and following it through.
But there's much more to it than just that. Each team member can pay attention to as much or as little of it as they need. Perhaps you're a designer, who isn't so concerned about the nuts and bolts of the database that underpins the project. Or maybe you're the person developing that database, and the customer's innermost thoughts are nice to know, but not terribly relevant to you day-to-day. That's fine, you can ignore the parts of the chart that don't concern you. But simply by arranging all this information in one place, everybody understands the part they play, and every decision can be explained and justified.
A good service blueprint will be an asset everyone on your team will appreciate. To create one takes a bit of effort, but it will repay that investment many times over. It will help you to stay informed, motivated and unified, and the result will be better services your customers will love.