Using Service Blueprinting to Bridge the Gap Between Strategy and Implementation

Many of us who have studied operations or service design are familiar with the service blueprint framework as a tool to identify actions of each stakeholder and the processes to support them for a service or business. Variations are also expressed out in the world, which take consideration of measurement, time, emotion, and other players. One of the great things about using this framework besides being both descriptive and prescriptive is that it's also incredibly flexible. Because of this flexibility, I regularly use it to design new offerings we're developing or describe a current offering and areas of improvement or measurement.

One of the newer uses for this framework is to bridge the gap between strategy and implementation. This sometimes feels like a chasm—you have a great idea and have fleshed out the value, players, and activities—but need to figure out how to start piloting and prototyping it. Service blueprint to the rescue! And here's how.

These are the main components of a service blueprint:

“Line of Visibility” Service Blueprint Components. Bitner, Ostrom, and Morgan (2008).
“Line of Visibility” Service Blueprint Components. Bitner, Ostrom, and Morgan (2008).

Here is an example of a portion of a service blueprint, adjusted for the details we wanted to portray:

If you're preparing for digital development, you will be creating a backlog of user stories that look something like this:

Tying the two together, you can assign the backlog elements to each supporting process of the service blueprint to make sure that each action is supported by what you need to build:

You'll have created the backlog based on what you want the service or offering to do—which may include features that are not necessary for an MVP or pilot. By matching it to the service blueprint, you'll not only be able to make sure you have your bases covered, but you'll also prevent yourself from creating features that are superfluous at this stage of development.

Clients and working teams alike love having this type of traceability from concept through implementation, because it provides a common map to work from and helps direct the development of the pilot. It accounts for what's happening in a user experience and provides the key details of making that experience happen. It helps ensure nothing falls through the cracks, and tells you who needs to be involved in each step—and you can even assign metrics to certain components to test as you develop the pilot.

Hands down, this is one of the most versatile tools I've used and is my go-to in concept refinement and pilot development that helps create transparency and alignment with clients and teams.