Skill set: Service Blueprint
A service is only as consistent as the control you have over it. An this is where this Skill comes at hand. Service Blueprint is an incredibly broad technique able to give a wide and heuristic view of how your service works (or could work if done properly). Since services are around all products, this technique can and should be used in most development efforts. Knowing how each piece fits with others gives a necessary know-how to search for improvements, define metrics, and create better solutions.
Adding context
Before diving in the skill itself, it is good to mention that the Blueprint is a rather difficult technique for beginners. It requires knowledge on how each player acts during the service. So to create a useful map, Blueprints should always be based on other techniques such as Journey Map (this will be obvious in a while), Contextual Interview, and Shadowing.
Blueprint can be used mainly in two situations:
- Problem finding: to build a very honest scheme of how your organization currently does its service. How the users behave? How your staff/channels respond to it? What is going on behind the curtains that is helping (or not) the service? At the end you’ll have a good condensation of the real deal, with good intuition on where are the weak points and how to improve them.
- Solution detailing: to propose the dream service. After your ideas popped and where distilled, Service Blueprint gives a great overview of how it should be put to practice. How can I arrange the pieces to make my new service run? Which metrics of success will I use? Where can we improve even further? The finished map will present you with key roles for the service to run and be controlled by the managers. I particularly prefer this second option, but it is up to you. Nothing prevents you from doing two Blueprints and compare them, if you have time to do so.
As I said, Blueprint is a rather hard skill to learn, though it is worth it. Every service should have its Blueprint made and updated regularly. This technique is great to lead your service to the next step, to evolve. I don’t recommend using it if you are just making small improvements, if you are very limited in time, or if you are making test runs (MVPs) of new services. This last one is because the Blueprint may stiffen your service at the beginning, which is a very experimental period. In this situation, a simpler Journey Map may be more useful. Even so, as soon as the service gets a little stabilized, the Blueprint should be in the wall.
Mentioning walls (physical or virtual), the systematization provided by the Blueprint is one of its many virtues. Having a Service Blueprint in the development room or in a shared file is indispensable. The Blueprint construction is a collaborative effort among development team members, but can and should also include users, staff, and other stakeholders that may appear in the service. It usually takes around 1 hour do be properly done, but it can easily scale to 3 or 4 hours if the service is complex. This implementation prototype is great to understand how users interact and how your organization responds.
The Service Blueprint
To get started, the Blueprint should be printed big and attached to a wall. One that everyone can see. Maybe next to your Persona… The Service Blueprint is basically divided in four parts, and you can directly draw over the paper or use post-its (that give more flexibility). Your first priority should be building the user journey with its emotions. Then go to frontstage and backstage processes to make the user go from one action to the other. The last line of support can be done simultaneously or at the end. I recommend leaving the KPIs for last since it is good to have the complete overview before stablishing metrics. Don’t forget to photograph and/or digitalize it at the end :)
The User Journey: as the name says, here comes the sequence of activities a user does when somehow using your service. It can be as broad as you like, and I strongly recommend going beyond the sales processes into pre and after-sales. Having done a User Journey Map beforehand is really helpful here. This item should answer: how the user interacts with me? Which are his/her actions? What did he/she do before reaching me? What will she/he do after? A helpful addition to this part is plotting the happiness level at each stage of the interaction. Parts that are stressful should be solved quickly.
line of interaction — this point integrates user and organization activities
The Frontstage: these are the actions your organization/service staff/channels do to interact with the user. It can go both ways: respond to an user’s action, or actively provoke it. This part represents the communication between user and the organization, and each possible channel should be strategized to be efficient, passing along users contacts to the responsible team, and providing transparent information to the user. Important questions here are: how are we interacting with users? Where are the touchpoints? Which are our internal and external communication channels? How are we anticipating their needs and becoming available to them? How are our after-sales processes?
line of visibility — everything from this point onward is invisible to the user
The Backstage: Here is where the magic happens, where lights are adjusted and props prepared. When receiving an demand from the user, the backstage has to be well oiled to respond quickly and satisfactorily. This part should receive information from the frontstage, process it, and return solutions. So it is very important to know specific activities that must occur here, and I highly recommend doing a Shadowing to see how each role is being performed. How are our internal channels? Which actions must we take internally to provide our service? How we systematize our work? Other processes might be important here as well, such as control actions, marketing strategies, and a subsection for the KPIs.
line of externality — this point connects organization to needed external supports
The Support: an organization can hardly operate on its own. This part contains needed interactions with suppliers, support, outsourcings, … Basically anything that is vital for the value to be delivered but your organization does not provide on its own. This part can also include used software, to understand the links among them, the databases, and any other non-human systems. Important answers to be given are: what we can’t do ourselves and how are we outsourcing it? What are we dependable from but may be out of our control? Which are our active partners and providers?
Well… that took some time and effort. But I guarantee: it is worth if. At the end you’ll have a great overview of your own little machine, it’s strengths, it’s weak-links, and how one little tweak here can have a great impact there. There are several other templates and examples that you can use, and I particularly recommend reading for you who intends to go a little deeper to access https://www.nngroup.com/articles/service-blueprints-definition/ or get the book “This is Service Design Thinking” from Marc Stickdorn, Jakob Schneider and the co-authors.
