Imagine as an employee that you need to use several applications to complete a single task, or that it takes 6 systems and 3 different department authorizations to provide one customer with your product or service. Many clients we work with are surprised to discover that a single task a customer or employee completes as part of routine business with them often spans multiple systems and resources like this—causing confusion, delay, and unnecessary work.

‍

Download our Customer Service Blueprint

Uncovering this knowledge is the first step in improving these areas of friction, ultimately saving time and resources. But how do you clarify a single shared understanding of how a service is provided? And more so, how do you know how complex tasks or jobs are, or who to involve in improving them and mapping a path forward? You turn to your user experience team.

Experience researchers utilize multiple mapping methods to build comprehensive insights into user’s experiences—whether they are internal or external to an organization. Customer Journey Maps, which we’ve covered before, are one of the most popular methods which outline a customer’s actions with a particular product or service, while Service Blueprints visualize the internal systems, processes, and employee interactions that support those customer interactions. Mapping both leads to really interesting results.. 

We often see these mapping exercises develop a shared understanding of how services work within an organization and generate an urgency to break down silos. They can uncover previously overlooked or hidden weaknesses in the organization and unlock new opportunities in the market. In this article, we walk through how to use Service Blueprints. 

For a refresher on Customer Journey Maps, please see our previous article.

Why use service blueprints?

Service blueprints are ideal for organizations seeking to understand complex systems, services, or processes of user interaction. Service blueprints are particularly useful for service-related offerings that involve multiple touchpoints, (triggers, communication, exchanges) multiple mediums, (digital, physical, interpersonal) or diverse teams and collaboration.

Service blueprints look at both the customer experience and the employee experience in order to define an effective service design strategy for the process, service, or organization.

What are service blueprints?

Service blueprints visualize user touchpoints as they relate to the organization. They focus on the service provider (e.g. salesperson, customer service representative, digital system, process), documenting areas of customer interactions rather than details. 

The visualization represents:

where touchpoints occur within the organization in relation to a user’s journey

who is internally responsible for the touchpoint (e.g. salesperson, customer service representative)

physically where it occurs (physical or digital location)

and how it occurs (process, methods, mediums, or channels of interaction)

Identifying all aspects of user interactions allows for the optimization of the organizational processes and improvement of the customer experience. Knowing where, when, and how interactions occur is the first step to creating a strategic approach to an omnichannel experience.

To ensure logical understanding, service blueprints are typically organized in a consistent way to separate customer actions, frontstage actions, backstage actions, and supporting actions.

“Actions” are not always overt, human-initiated efforts; these can be automated triggers or system actions. Arrows are used to indicate the flow of actions mapped across the blueprint and show dependencies/triggers. The key is modeling where and how the variety of actions occur/are triggered and accounting for them. In order to effectively map actions, one must understand the different regions of the blueprint.

• Customer actions: The first swim-lane of the service blueprint. These actions outline what your user is doing throughout the interaction. If you have a customer journey map these actions should align closely with those phases. 
• Between customer actions and frontstage actions is the line of interaction. Actions that cross this line represent where direct interactions occur between user and organization.
• Frontstage actions: How your company interacts with your user, these can be reactions to user actions or organization generated actions. These interactions can take multiple forms including human-to-human (sales pitch, service offering, etc.) human-to-computer, (chatbot, online service request, etc.) or a combination of the two.
• Between the frontstage actions and backstage actions is the line of visibility. The line of visibility pertains to the user, actions occurring above the line are visible to the user while actions below the line are not.
• Backstage actions: What is occurring within your organization out of view of the customer to support frontstage actions. These actions can be performed by the same contributors and systems as frontstage actions, the difference is they occur behind the scenes. 
• The line of internal interaction separates backstage actions from the support process. This line represents where direct customer support ends. This can mean employees or services which have no direct interaction with customers arrive to support the service. 
• Support processes: The final swim-lane of the service blueprint. Support processes are the foundation of the service and include any interaction which supports employees and systems in delivering the service. 

A real-world example of how we used service blueprints?

While working with a leading cloud provider, our team was tasked with assisting in the development of a tool to assist in the lengthy sales cycle for their international customers. 

In order to effectively grasp the entirety of the process, who was involved, what systems are used, etc. we utilized service blueprints to help the team clarify and visualize all touchpoints. We collaborated with technical and business stakeholders through interviews and workshops to ensure each stage was illuminated. Our team then took all of this information and developed a visual representation of the process—a service blueprint. This exercise allowed the entire team to see how each stage connected to the next, where responsibility lies for each stage, and where efforts were being maximized or opportunities for optimization existed. 

Beyond process optimization, the service blueprint also acts as an overarching view of where and how interactions occur at each step in the process. Our service blueprints became extremely valuable to the team as GDPR regulation went into effect. They allowed us to see the big picture of where, when, and how customer information flowed through the process in order to ensure compliance. 

Creating service blueprints serves many purposes for us.

Discover strengths. The ability to view all interactions allows the organization to assess where the process is most efficient and gives the customer the best possible experience. 

Uncover weaknesses. Similarly, once all interactions can be viewed at once inefficiencies become more identifiable. 

Identify opportunities. Once both strengths and weaknesses in the current model have been identified the organization can begin to optimize the process by drawing on the strengths and repairing the weaknesses. 

Minimize risks. Looking at the entire service design allows the organization to better identify risk areas. Risks can include security vulnerability, poor user experience, organizational flaws, etc.

Bridge efforts & break down silos. Without looking at the entire process one can know where issues exist but may not be able to identify why. Service blueprints allow silos to b uncovered and identify where bridges can be built to better connect touchpoints.

Best Practices for creating Service Blueprints

• Limit scope. Setting hard boundaries on the process which your team is investigating is an important first step. A rule of thumb is to create one service blueprint for each core service. Of course, throughout your research, you may uncover more to the process, but it is also easy for an ever-expanding process to emerge when one isn’t diligent with focus. If your team uncovers a new process document it for future investigation, each process deserves a full assessment which can only be ensured through stable boundaries. 
• First-hand research. The creation of a service blueprint should be taken on as a new and thoughtful endeavor. They should not be based on old or unconfirmed accounts of the process. Service blueprints should be based on primary research. This means speaking directly to contributors, observing parts of the process, participating in the process, accessing work logs, and so on. 
• Avoid bias. It is easy for a team to talk to only one or two parts of the process and assume they have it all covered. It is also easy to listen to the most vocal part of the process more. In order to ensure your process is thorough and accurate one should make sure to investigate each part of the process individually to validate assumptions. One piece of the process may very easily only see half of the work the other side and vice versa. The purpose of a service blueprint is to uncover these gaps in information, to allow all sides to be fully understood, and to eliminate skewed perceptions of the process. 
• Iterate and validate. Once you feel you have achieved a thoughtful complete service blueprint share it with your organization. Validate your findings by distributing the blueprint to your research sources, aka the boots on the ground. Ensure your accuracy by gathering feedback and keeping the blueprint up to date and accurate. If systems or processes are changed update the service blueprint to ensure a consistently accurate artifact. 

‍