How Product Managers use the Service Blueprint to map out infrastructure services
Connecting the Customer Journey to Infrastructure Services
Erica Salinas is a guest writer for Product Maestro’s blog. If you enjoyed this topic, subscribe to our blog and join 600+ leaders who receive bi-weekly tips on Storytelling and Product Leadership.
Product Managers and Researchers love maps. Empathy maps, customer journey maps, experience maps… I’m here to introduce you to the lesser known and severely underappreciated: Service Blueprint.
For those of you unfamiliar with this format, it tends to often be used to capture customer-employee interactions and employee-system interactions. However, here I’d like to share with you why the Service Blueprint is especially apt for those of us providing network/infrastructure services or providing services as part of a larger partner ecosystem. I’ll start with a brief tour of a sample Service Blueprint that I flagrantly stole off the internet. Let us begin…
What is a Service Blueprint?
A Service Blueprint is a diagram from the organization’s perspective that visualizes the relationships between customer actions, touchpoints, supporting processes, and underlying business processes as they tie into a specific customer journey.
The service blueprint is complementary to a customer journey map. In the digital service realm, it’s particularly awesome at mapping complex scenarios spanning multiple internal and external partners and systems.
Anatomy of a Service Blueprint
So what does one look like? Here is an example that I like because it is for a website, which means it does not have employee touchpoints like many examples do. Below I’ll walk through the key components and some optional ones.
Lanes
Physical Evidence: What the customer is interacting with to perform their actions. Examples include a website or a mobile app.
Customer Actions: Actions the customer takes. Essentially the customer journey. Examples include adding an item to their shopping cart or making a payment.
Frontstage Interaction: Actions that occur directly in view of the customer. Examples include a payment confirmation or a shipping notification.
Backstage Interaction: Steps and activities that occur behind the scenes to support frontstage happenings. Examples include payment handling or shipping label creation.
Support Processes: Internal steps and interactions that support the organization in delivering the service. Examples include maintaining a CRM system or collecting network data analytics.
In the case of a network or infrastructure provider, frontstage interactions is where partners often provide key functionality. Understanding their desired functionality helps us optimize functionality to support partner success and provide consulting services while they’re building it. Backstage interactions is where we will most often be represented. These boxes are what will turn into future engineering features and grow to contain user stories.
Lines
Line of Interaction: Depicts the direct interactions between the customer and the underlying ecosystem.
Line of Visibility: Separates all service activities that are visible to the customer from those that are not visible.
Line of Internal Interaction: Separates processes that directly support interaction with customers from those that do not.
Optional Elements
Emotion: Represents where employees are happy or frustrated.
Pains / Gains: Identifies areas of inefficiency and efficiency to allow for correcting of process issues or sharing of best practices.
Metrics: As-is or success metrics that are associated with each step along the customer journey
Metrics is my favorite optional element. Since that is lacking in the example above, here is another example showing time as a metric.
Why a Service Blueprint?
So why should we, infrastructure or network providers, leverage this particular artifact? Well, let me count the ways:
- As a network, it can often be difficult to see how the functionality we are building is tied directly to the customer journey. However, it is in understanding where we fit in and provide value to the larger ecosystem that will ensure we are prioritizing and developing the right things. The service blueprint provides a comprehensive understanding of our service ecosystem, what processes are ours to support, and how those directly tie to a successful customer journey.
- Given that we have a clear picture of our service ecosystem, we can also see the required functionality and integration points across the totality of the customer journey for both internal and external partners. This allows us to ensure success and consistency throughout the entire value chain.
- As we continue to evolve our network, we will be both building new functionality and modifying existing functionality to support new business use cases. The service blueprint allows us to identify what can be leveraged, what can be refactored, what can be modularized, and what must be built new. Having this visibility substantially reduces the likelihood that there will be gaps in the final implementation.
- Given that we can identify the different types of functionality as detailed in #3, we are also able to identify opportunities for optimization and eliminate redundancy. Meaning, we can prevent ourselves from always building new functionality for each new use case and we can keep our code clean.
- Finally, should we run into an issue with a current service offering, having a service map allows us to trace a customer issue down to its root cause process. With a map of clear dependencies and interfaces between partners, we are able to discover weaknesses that need resolution.
I know you are all now wondering where Service Blueprint has been your whole life. Thus, for those wanting a deeper look, I’m also including resources to learn more below. I would love to hear stories from those of you that have already leveraged a service blueprint. And if you haven’t, try it and let me know how it goes.
Erica Salinas is a guest writer for Product Maestro’s blog. If you enjoyed this article, subscribe to our blog and join 600+ other leaders who receive bi-weekly tips on Storytelling and Product Leadership.
