The advantage of a service blueprint over a standard process map is that it makes the invisible visible. While a flowchart might tell us that a request goes from intake to review to action to close, it won’t tell us about the customer’s experience or what happens in the background between each of those steps. In this sense, the customer journey and backstage work are crucial for a beginner to understand what needs to happen next, who is doing the work, what the customer sees or experiences, and what activity is required in the background to keep the service going.
Most often, this first layer reflects the customer journey; for example, searching for information, submitting a request, waiting, receiving a service, or confirming that the service is received. These are customer actions and touchpoints, writing down customer touchpoints helps us review customer experience and expectations. We can see, for example, that the process takes a long time to move between two touchpoints, which may be fine internally but look like a forgotten customer request to them.
The next two layers show the distinction between frontstage and backstage activity. Frontstage activity is visible to the customer, such as sending an email confirmation, making a phone call, making an update, or completing a handover. Backstage activity is the stuff in the background, such as accessing information or documents, assigning ownership, getting in touch with another department, gathering the resources, or approving an exception. It may not make a lot of difference in the flowchart, but in the blueprint, we can see what activity the customer will perceive versus what activity is just part of the internal process.
As a beginner, start with just one service rather than trying to map every service or every process in the entire organization. It is best to choose something you know is repeatable (like processing a booking change or handling a damaged item report, for example). Write the customer actions along the top of the page. Under each action, write down the staff actions that are visible from the customer perspective, then the behind the scenes activity required for the staff to provide that customer-facing service. Finally, note down the systems and documents, forms or lists, etc., that are relevant for this particular customer service (such as a customer request form, customer booking system, a customer request log, a handover checklist). And just keep it simple enough that you can spend a few minutes going over the first draft to identify potential process issues.
The interesting findings will often sit in between the layers. The customer may be sent a confirmation of receipt right away but we may realize there is no action taken backstage to ensure the request is assigned an owner, or a staff member may promise an update, when internally there is no reminder of when the staff member will provide the customer with an update. Similarly, two people from two different departments may do the right thing, but the process from handing it to the person in the next department may be unclear. These kinds of breakdowns are hard to spot when we’re only focusing on what actions we know or think should take place but not the connection between the staff actions customers see versus the invisible processes in the background.
There is also a tendency to overload the blueprint with every possible failure, policy and system process, which makes the map complicated and difficult to review. The process owner should first focus on the typical flow and service level. Identify one or two possible failure processes like missing information, delayed approvals, and ownership of action. We can always add more processes to the service process blueprint, once we have an overall view of the typical and atypical processes. The goal should not be a pretty map of the organization, but rather identifying where a process fails, leaving a customer in limbo when they should have a service level agreement.
Finally, a customer service map should inform a conversation about a customer service issue or opportunity. For example, what is the most frequent process failure point in relation to the customer? Where do we switch from customer actions to staff actions? Where might there be a customer-facing promise to provide an update, but the back stage work doesn’t have a clear owner? Pick one area where the process appears weak and try to identify one change we could make (add a customer confirmation step, assign ownership of the action earlier, make an appointment to provide the status to the customer, etc). The service blueprint only makes sense if it enables us to identify one line on a customer service map to identify one action we should take to improve the customer service process.
