It is a powerful tool that provides a high-level view of the user experience and a detailed view of what is happening in the background, including staff actions and processes.

Following a user journey, it maps all points of interaction with a service and the actions, tools and processes happening in the background that are directly connected to the user’s action.

When to build a service blueprint

Not all projects need a service blueprint and due to its complexity, it is wise for teams to reflect if there is value in building one.

Service blueprints should be built when the team needs to:

• Simplify a complex service, resource and process through visualising it

Service blueprints give an organisation a comprehensive understanding of its service and the underlying actions and processes that make it possible. These actions might be visible and invisible to the user.

• Draft the outlines of a new service

Before you build a new service, it is worth spending time creating a service blueprint to capture the front stage user experience and the backstage activities the organisation needs to deliver to create the new service.

• Improve an existing service

Understand how service improvements can impact the existing service by understanding relationships between all actors and aligning them with frontstage and backstage processes.

• Get buy-in from stakeholders

Having the service overview in the blueprint is important, because it can help teams communicate the project to decision-makers higher up in the organisation before they start building or changing the service.

• Understand the scope of the work by zooming out

It also gives stakeholders a zoomed-out view of all the components of your service and an understanding of all its parts before starting to improve parts of the service. This makes it easier for the stakeholders to understand the scope of the work and make decisions.

• Understand service interdependencies

Service blueprints help stakeholders understand how a small change can have an impact in other parts of the service and maps all the connections between the different actions and systems.

Key elements of a service blueprint

Service user actions/steps

The service user's actions/steps in a service blueprint represent the steps a user takes when interacting with a service.

e.g. service user books an appointment, service user goes to consultations

Frontstage actions

The actions that happen in the frontstage are those that occur directly in front of the service user. These actions can be with a human, when a staff member interacts with a service user or technology-based when the service user interacts with self-serving technology.

Backstage actions

Backstage actions are actions that are invisible to the service user. They happen invisibly to the user's eyes but are crucial in supporting the actions that the service user sees and interacts with. These background actions can be performed by a backstage employee or member of staff (e.g. a doctor reviewing patients information before an appointment), or by a user-facing employee who does something that is visible to the service user (e.g. a receptionist who the user interacts with)

Processes

Processes are the internal actions and interactions that support the employees delivering the service.

How to structure a service blueprint

In a service blueprint, key elements (see section above) are organised into lines that separate them:

• Line of interaction shows all the interaction between a service user and a service
• Line of visibility separates the actions that are visible to the service user and those that are not visible.

How to build a service blueprint

1. List all the actors involved in the service process
2. List all the steps/actions required to deliver the service
3. Place the line of visibility to highlight the actions the costumer can see above the line; and the actions the customer can’t see below the line of visibility.

If you want to add more complexity to a service blueprint:

1. List all the channels a customer interacts with
2. List all the systems/technology an employee interacts with
3. Add in time factor to highlight the estimated time to complete a step/action
4. List any policies/regulations that have an impact on how the service is delivered
5. List in any success metrics that can provide context to the blueprint
6. Add user pain-points or challenges to the map

Remember that the more elements you add to a service blueprint the more complex and difficult to will be to read and understood across the organisation.