Commercial Cartography – Vol. VI: Service Blueprints

     Most manufactured goods are produced and distributed to the marketplace where consumers are then sought.  Services, in contrast, are not “produced” until there is a “consumer.”  Simultaneous production and consumption is a hallmark of service; no inventory can be accumulated to compensate for fluctuating demand.
     Instead, demand must be managed via predictable performance and efficiency.  A service blueprint documents how a service is delivered, delineating customer actions and corresponding provider activity.  Its pictorial format facilitates searches for improvements in current service delivery and identification of potential complementary offerings.  A service blueprint can also be created proactively to optimize a delivery system before a service is made available to customers.

     Various definitions of “service” are available in the service management literature.  In lieu of a formal definition, we will focus on key characteristics of services that differentiate them from products:

• Service delivery is a process.
• A system is used to deliver a service.
• Service delivery requires coordination of a customer (“consumer”) and a provider (“producer”).
• A service can be repeated, but cannot be reused.

 
The Value of Blueprinting
     Understanding what makes a service unique is critical to effective management.  A blueprint makes a significant contribution to this effort; use of the term has important connotations.  Blueprints are more commonly associated with manufactured products, where each is identical to the next.  While services can be highly variable in content or outcome, customers’ experience with a provider need not be.  A consistent customer experience is what a service blueprint documents.
     A well-developed service blueprint can serve several purposes, including:

• rapid identification of the cause of a service failure, such as a skipped step,
• rapid identification of appropriate recovery processes following a service failure,
• recognition of mismatches between service delivery and customer expectations or desires,
• identification of redundancies or potential efficiency improvements,
• identification of potential service enhancements,
• development of complementary service offerings,
• evaluation of potential market segmentation, and
• training new employees.

 
Preparing to Blueprint
     Before attempting to create a blueprint, some “guardrails” are needed.  The first step is to define the scope of the service to be blueprinted.  The scope definition can include the location, type of service, market segment, number of parties involved, group size, and so on.  Record any aspect of the service in which a deviation changes the requirements of the delivery system.  Clearly defining the scope informs a determination of the number of blueprints needed to fully document a service business.
The status of the process to be documented must be known to develop the appropriate type of blueprint.  A “current state map” documents an existing service delivery system, including its flaws and “dead ends” where no defined process exists; recent performance data should be incorporated in the blueprint.  It is critical that a current state map be thorough and accurate, lest the value of the effort be squandered.
     A “future state map” documents a service delivery system as envisioned after proposed modifications have been implemented.  The blueprint shows how a service would be delivered with redundancies removed, dead ends remedied, efficiencies improved, enhancements included, and other improvements made.
     A “service development blueprint” proposes a service delivery system to be established.  It provides opportunities to simulate the system and optimize predicted delivery performance before customers subject it to the ultimate test.
     Two previous installments of “The Third Degree” are recommended for review in conjunction with this discussion:

• “Commercial Cartography – Vol. II:  Flowcharts” (9Oct2019) and
• “Use Process Maps to Guide Product and Service Development” (23May2018).

The first is applicable to all types of service blueprints; the similarities between service blueprints and process flowcharts will become apparent.  Reference the second to assist development of an initial service definition or refinement of an existing delivery system.
     Membership of a development team may be obvious in, say, a two-person startup.  Larger organizations, however, may have to consider resource tradeoffs to form a team.  In any case, all members of the blueprinting team should be clearly identified to secure their participation.
     The final preparatory decisions to be made relate to the method by which a blueprint will be physically created.  Initial development of a blueprint should take place on a scale large enough for the entire team to engage with it simultaneously; sufficient scale can be achieved using a large table or wall.  It should be easily reconfigurable, or editable, for rapid incorporation of new ideas.  This is typically accomplished using a whiteboard or “sticky notes.”
     When the content of a blueprint has been “finalized,” a “clean copy” can be created, either on paper or in software.  A refined version is useful for formal presentations; however, it is often unnecessary.  If the blueprint is viewed exclusively by the development team – i.e. it remains an internal document – a presentation-quality version may add little value.  An important exception is the use of the blueprint for training purposes; documents that are easy to understand accelerate learning.
 
Creating a Blueprint
     On the large-format medium where the blueprint will take shape, establish the basic layout needed to organize information.  All that is required to do this is to place the labels along the left side and draw the dividing lines described below.  An example of a blank service blueprint is shown in Exhibit 1.  Some changes in terminology from that shown in Exhibit 1 are recommended; from top to bottom, identify the following rows and boundaries:

• Tangible Evidence – artifacts that are used to deliver the service, prompt an action, or demonstrate completion of a step in the delivery process.  A less-literal term than “physical evidence” is appropriate for many modern services.
• Customer Action – actions taken by a customer to initiate and proceed through a service delivery process.
• Line of Customer Interaction – visually separates customer actions from provider actions.
• Onstage Action – provider actions that a customer “sees” or is aware are taking place.  “Contact Employee” has been dropped from this label because it may be misleading as the nature of services continue to evolve.
• Line of Visibility – visual representation of the separation between “front office” and “back office” activity.
• Backstage Action – provider actions that are hidden from the customer’s “view,” but are necessary for service delivery.  Tasks may be completed by the onstage actor or another; “contact employee” has again been dropped from the label.
• Line of Internal Interaction – visually separates activity directly related to a specific service delivery and the general-use tools, managerial procedures, and support staff.
• Support Processes – information technology-based processes, other organizational-level tools, support staff and management activity.

     The need for flexible terms increases as services evolve to include more technology and remote delivery features.  Their value is more evident when analyzing modern service delivery systems than in the context of traditional face-to-face services.
 
     To begin populating the diagram, generate a list of all actions taken by a customer throughout the service experience.  Enter these in the Customer Action row, chronologically from left to right, in the sequence that they occur.  The timeline created need not be to scale, but the actions should be spaced sufficiently to allow the team to build the blueprint around them, making changes and additions as necessary without the need to start over.
     For each customer action, identify the Onstage Action that it triggers or that it was triggered by.  An action by either customer or provider cam prompt a response by the other; identify all onstage actions with either causal relationship.  Corresponding actions are typically aligned in a column as a spatial representation of their relationship.
     The direction of an arrow connecting the two actions represents the causal relationship.  The arrow originates at the prompting action and terminates at the responsive action.  It is possible for this relationship to be bidirectional (depicted by a double-headed arrow).  That is, either party’s action can prompt the corresponding action from the other, like a handshake or a negotiation.  Pairs of corresponding customer and onstage provider actions are often called “touch points” of the service.  Metaphorical use of this term is in order; it represents an interaction between customer and provider, but physical contact, or even colocation, may not be required.  Some services require physical contact (e.g. haircut, massage), but an increasing number can be completed remotely.
     Continue building the blueprint by adding onstage actions that are not paired directly with a customer action.  For example, a single customer action may prompt a series of onstage actions, each of which needs to be included on the blueprint.  This is one reason why the initial spacing of customer actions is important.
     Next, add backstage actions – those activities “hidden from view” of the customer – and connecting arrows indicating their prompts and actions that are, in turn, prompted by them.  Backstage actions can be connected to onstage or customer actions or to support processes, which are to be added next.
     Support processes may include information technology, third-party-provided services, coordination or facilitation processes (e.g. scheduling, work planning), or other “hidden” processes that improve service delivery.  Support processes can be associated with onstage or backstage actions.
     At this point, operation of the service delivery system is well-defined.  To complete the blueprint, populate the first row with tangible evidence employed throughout the service delivery.  The position of each corresponds to the action that prompted its use or creation.  That is, its position in the row indicates the timing of the use or creation of an artifact during service delivery.
 
     Additional information can be included on a service blueprint if the development team deems it useful.  The duration of each activity is one of the most common suggestions.  Considering the variability of services, an average or range of anticipated completion times may be more appropriate.  Citing a fixed duration may be misleading or demotivating.
     “Fail points” are also common additions to service blueprints.  These may be superfluous, however.  Realistically, a delivery system could fail at any point; visually indicating this fact may be unhelpful.  Flagging high-risk or frequent failures, where special attention is required, may be worthwhile, but must be done sparingly to remain effective.
     Color-coding may also be used to differentiate between actors or other logical compartmentalization of the delivery system.  Emotional states, performance metrics, and relevant regulations have also been suggested for inclusion.
     Only the basic components of service blueprints were included in the initial presentation to avoid distraction or overload.  Each development team must decide what elements to include based on the value each adds to the effort.  It is strongly recommended that a basic blueprint be created first and that other elements be added very selectively.  As elements and information are added, the blueprint may become more difficult to read; it may also encroach on other types of “maps” or diagrams that the organization may use.  Providing references or links to other sources of information can be an effective alternative.   Caveat creator!
 
     The steps of creating a service blueprint have been described sequentially for simplicity of presentation.  In reality, once a sequence of customer actions has been identified, the remainder of the blueprint will, in most cases, be generated much more organically.  Team members’ individual attention will be drawn to different aspects of the delivery system at different times, allowing the blueprint to take shape much more rapidly than is possible when the entire team works on each aspect collectively.  Changes are made and reviewed on an ongoing basis, allowing team members to engage with the blueprint more naturally than a strict process structure allows.
     Purely sequential development is likely to require several iterations before a plausible blueprint results.  Organic development can be as effective, if not more so, than a number of iterations and can be completed in much less time.  Therefore, the efficient service blueprinting effort may be one that is launched and finalized as a team, with a period of free-form activity between, as depicted in Exhibit 2.  For this to be true, however, the team members must be comfortable with this approach.  Significant experience with service blueprinting may be needed to achieve a sufficient level of comfort for the team to utilize the organic development approach effectively.

Service Blueprint Examples
     Reviewing examples of completed service blueprints is a good way to become familiar with the layout and comfortable with the creation process.  The examples below show some variation in content, terminology, and complexity.  The examples are not comprehensive, but are sufficient to demonstrate the technique’s flexibility.  New practitioners can use them for inspiration as they develop their own blueprinting “style.”
     A generic service blueprint is shown in Exhibit 3.  The generic blueprint does not identify a specific service; instead, it depicts actions and interactions that are common to many types of services.  However, it may serve as a useful guide; translating the generic descriptions into ones specific to the service of interest can kick-start the development process.

     The generic blueprint of Exhibit 3 includes a Line of Implementation between support processes and management action (rows are unlabeled, but this reflects their content).  This line was excluded from the preceding discussion for two key reasons:

• Few authors include this line in their presentations or example formats.
• Managerial actions are support processes; separating them adds little value to most service blueprints.

If the blueprint created is sufficiently complex to warrant separation of managerial actions from other support processes, the development team is free to do so.  Ultimately, the format that the team is most comfortable with is the best one.
 
     A blueprint for an overnight hotel stay is shown in Exhibit 4.  While it may be more aesthetically pleasing to some readers, the colors provide no additional information.  As the color only differentiates between rows, it is superfluous; thus, it remains a basic blueprint.  Aesthetic improvements are valid and acceptable, of course, but there should be no confusion about their purpose.

     The Blueprint for Engineering Services presented in Exhibit 5 uses the terminology recommended in Creating a Blueprint and introduces the use of “fail point” notations.  Only a small selection of fail points are identified as such to prevent it from becoming a meaningless designation.  The highest-risk points of failure – those that could derail a service, irreparably damage the customer-provider relationship, or invalidate an entire delivery system – are identified to ensure awareness of their criticality.

     Identifying fail points is only effective if those responsible for successful execution understand the implications.  For identification of a fail point to be helpful, the team must understand and communicate the following:

• the consequences of failure at this point of the service delivery,
• how to execute the required action correctly,
• how to respond to a developing situation, i.e. an impending service failure,
• how to recognize the occurrence of a service failure, and
• how to recover from a service failure.

Readers should take note that fail points can exist at any point in the service delivery, including customer action.  A breakdown can be caused by customer or provider, onstage or backstage, or a support process can fail.  All aspects of the service delivery system must be considered to develop effective countermeasures.
           
     A service blueprint can also be expanded to include multiple interacting parties, such as when a broker or other intermediary facilitates a transaction between two independent parties.  An example of this type of expanded blueprint is shown in Exhibit 6.  The top of the diagram depicts one interaction, while the bottom of the diagram mirrors the top to show interactions with the second party.  Support processes are central in the diagram; they are used in the interactions between the intermediary and both parties, linking them at various stages of service delivery.

     The examples provided have not been identified by type (current, future, or development); taken out of context, it is unknown.  Their value as inspirational guides, however, is unaffected by this.  Each blueprint is unique; a development team need not be concerned with the motivation behind an example blueprint, whether it was created with data or imagination.
 
Final Thoughts
     Use of service blueprints can help providers achieve efficiencies and consistent delivery performance that contribute to profitability and customer satisfaction.  To develop an effective service blueprint, follow this very brief summary:

• Define the scope of service.
• Choose blueprint type – current state, future state, or development.
• Select team members.
• Choose method and acquire materials.
• Generate list of customer actions as a team.
• Develop blueprint organically.
• Review and finalize blueprint as a team.

Other key points to remember:

• Use rows to differentiate “actors.”
• Use columns to establish “timeline” or temporal relativity.
• Use arrows to show causal relationships.
• Add information, beyond basic components, sparingly.
• Link to detailed information (PFD, instructions, etc.) to keep blueprint simple.

     As experience is gained with service blueprints, the creation process, content, and perhaps the format will evolve.  Revisions will be necessary as technology and other aspects of service delivery changes and advances.  An imperfect blueprint is not a failure, it is a learning and growth opportunity.  As a blueprint is developed and revisited, new ideas emerge; customer and provider alike benefit from the experience.
 
     For additional guidance or assistance with service blueprinting or other Operations challenges, feel free to leave a comment, contact JayWink Solutions, or schedule an appointment.
 
For a directory of “Commercial Cartography” volumes on “The Third Degree,” see Vol. I:  An Introduction to Business Mapping (25Sep2019).
 
References
[Link] “Designing Services That Deliver.”  G. Lynn Shostack.  Harvard Business Review, January, 1984.
[Link] “Service Blueprinting:  A Practical Technique for Service Innovation.”  Mary Jo Bitner, Amy L. Ostrom, and Felicia N. Morgan.  California Management Review, Spring 2008.
[Link] Mapping Experiences.  James Kalbach.  O’Reilly Media, 2016.
[Link] Winning the Service Game.  Benjamin Schneider and David E. Bowen.  Harvard Business School Press, 1995.
[Link] Service Management, 8ed.  James A. Fitzsimmons, Mona J. Fitzsimmons, and Sanjeev K. Bordoloi.  McGraw-Hill/Irwin, 2014.
[Link] “Service Blueprints: Definition.”  Sarah Gibbons.  Nielson Norman Group, August 27, 2017.
[Link] “The 5 Steps to Service Blueprinting.”  Sarah Gibbons.  Nielson Norman Group, February 4, 2018.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com