What is a Service Blueprint and how does it serve us?
What makes it different than a Journey Map and why would we use one over the other?
Let’s start at the beginning by considering both. Both Service Blueprints and Journey Maps look at a service or experience holistically in order to capture the path of the user. Both begin with research and lay out a path that outline the phases we uncover during research.
The difference between the two is that the Service Blueprint also captures what happens behind the scenes — the touchpoints that a user may not have direct access to but is nonetheless affected by. For example, let’s consider the way a customer service group operates within an organization. A person seeking support services from this organization, doesn’t have any control over the processes or procedures that are in place, but the way the customer service group functions does have a direct impact on that person. These are essentially the services that are invisible to a person but have a concrete impact on their experience.
As a result, we can safely say that a Service Blueprint looks at the operational processes of an organization parallel to the user’s path. These processes may be covered in a Journey Map as they contextually relate to the user’s actions but the service blueprint dives deeper and it’s possible more service blueprints could spawn out of a larger one if there is a need to really look at processes from a microscopic level.
Looking at the operational processes allows us to see where the user’s path and the organization’s processes overlap. From this perspective, we can figure out where things are working and which elements of the process require refinement. For example, if a user phones into a call center and is unable to get the answers they need, we can attempt to figure out why.
Did the customer support person not know the answer to the question? Is there a protocol or process for documenting questions the support team can’t answer with a plan to outreach and close the loop for the caller? The service blueprint allows us to uncover the ways the organization’s processes are supporting the user and how they can improve.
How can the service blueprint help us come to a resolution for the user? By asking more questions. Is the question the caller asking something that hasn’t been asked before? If that’s the case, do we need to note this in our process and educate the staff? These questions allow us to uncover moments of needs for the user that can then be met with moments of opportunities for the organization.
As a result, a Service Blueprint serves as a jumping off point to consider where processes can be improved and which systems need improving. For example, in a given customer experience, as mentioned above, it means meeting users’ needs by recognizing training and educational materials need to evolve to serve those needs.
If we’re talking about a product, it can mean taking the moments of needs or opportunities and turning those into use cases that can turn into user flows, that can then turn into screens we can test and eventually implement.
This is how the Service Blueprint serves us. It is a tool that consolidates information that is contextually relevant to an experience — from a user and operational perspective — that we can then review and analyze. It lays out at a path and through that layered path, we are able to come to some conclusions based on our research, while still pursuing the validity of others.
