The Service Automation Blueprint

The Service Automation Blueprint is one of the seven techniques of the Service Automation Framework. It most frequently used as a tool in order to visualise how a service is delivered by a service provider. In order to automate a service, it is necessary to exactly understand how a service ‘flows’ through an organisation, and where the interactions and interfaces with the Users are.

Drawing a Service Automation Blueprint is one of the first steps towards service automation. In this post, we will therefore briefly explain the key layers and elements of the blueprint. We hope that after reading this post, you can start to draw the first blue prints by yourself.

The layers of the Service Automation Blueprint

The Service Automation Blueprint consists of seven main design elements, each with a specific focus and key characteristics. Each of the design elements is equally important in terms of determining the overall user experience (UX). A ‘blank’ Service Automation Blueprint is depicted in the figure below:

The five layers of the Service Automation Blueprint can be defined in the following way:

• Demographics. Demographics characterise a User Group in terms of factual information that can be attributed to the whole group. Common demographic characteristics are age, geographical location, gender and income category.

• Psychographics. Psychographic (as opposed by demographics) deal with preferences and perceptions of Users and are therefore less tangible (for example ease-of-use). Psychographics have a major influence on defining the User Experience of a Service, as explained in this article.

• User Actions. User Actions are best described as all of the steps that Users take as part of the service delivery process, based on their preferences. The User Actions are typically listed in chronological order on the first row of the Service Automation Blueprint, and represent actual physical behaviors of Users. Although certain behaviors can be triggered (for instance by a ‘call to action’ through an advertisement), User Actions are mostly outside the span of control of a service provider. Examples of User Actions are visiting a website, signing up for a newsletter or downloading an app to a smartphone. In the Service Automation Framework, it is assumed that a user has complete autonomy over his own User Actions (which frequently involve a decision), basing them on previous experiences, quality and ease of use. Defining the appropriate and desired User Actions is central to the creation of the Service Automation Blueprint.

• Physical Evidence. Physical evidence is a Service Provider action that has value for users and establishes a level of trust between a user and a service provider. In earlier blueprint research, they have been labeled ‘moments of truth,’ which we think is the best possible description of Physical Evidence. Physical Evidence is tangible for a User (although the evidence itself might be digital) and provides reassurance about a specific service. As such, Physical Evidence greatly influences the overall quality perception of users. Examples of Physical Evidence are email confirmations, invoices, receipts, invitations, certifications, loyalty cards, etc. In summary, it is all of the information that is transferred to a user whilst he or she is using that service.

• Technology Interface. The Technology Interface is the layer between users and service providers that facilitates interactions. As such, it is the medium through which a service provider interacts (i.e. facilitates service encounters) with its users. The technology interface is one of the most important design elements of the Service Automation Framework, since it is at this layer that the benefits of Service Automation can eventually be achieved. Generally speaking, the Technology Interface is a bi-directional information stream, which processes User Actions on the ’front-end’ and initiates processes at the ’backend’. Various forms of self-service portals or applications, which facilitate these bi-directional streams, can be used to realize a suitable Technology Interface. An organization can have multiple Technology Interfaces (for instance both a support portal and a Facebook company page), but following the principles of consistency, the aim is to have a certain level of coherence in this layer.

• Support Processes. Support Processes are the (automated) sequential steps that service providers take in order to process User Actions. In practice, Support Processes carry out a number of activities in order to achieve a desired outcome for a user. A common supporting process, for example, is a password reset. Based on the request from a user (i.e. a User Action) this supporting process automatically adjusts a password in a database so that a user can have access to a software application. Support Processes are characterized by their sequential activities that can be visualized by means of flowcharts through sequences of activities and decision moments.

• Company Functions. The final layer in the Service Automation Blueprint, Company Functions are the organizational departments that exist in any company, encompassing knowledge or areas of expertise. Their aim is to conduct a specific task in line with the goals and scope of the larger enterprise. Traditional Company Functions are Marketing, Sales, IT, Facilities, etc. Frequently, they are important stakeholders that have specific requirements for the service that needs to be defined. Because Company Functions are not always in line with the support processes of the organization, we have listed them as a separate and final layer.

Service Automation Blueprinting in Practice

Now that you are familiar with the key concepts of the Service Automation Blueprint, you can start to draw your own. In order to make this as easy as possible, we have composed a free A0 version of the Service Automation Blueprint that you can download to get started:

The best way to fill out the Service Automation Blueprint Poster is in a collaborative group discussion (the infamous pizza-sessions) in which teams discuss the ‘ultimate user experience’ of a service in a step-by-step approach

1. Determine the User Group and service for which the Service Automation Blueprint will be composed. List this information at the top of the Blueprint so that every workshop participant has a clear understanding of the service under discussion. Start a short discussion on the definition of the service and the User Group, so that everyone has the same interpretation and definition of the topic;
2. Start on the left side of the Blueprint and determine the demographics of the User Group. What is the average age category of the users? Where do they typically live? Try to keep the most important demographics in mind, and finally select a maximum of seven to list on the Blueprint.
3. On the right side of the Blueprint, discuss the five psychographic criteria and how they might impact the overall User Experience. Discuss how each criterion (information availability and content, ease of use, privacy and security, graphic style, or fulfilment and reliability) impacts the UX and determine and outline which two or three criteria are most important. Post the top two/three psychographic criteria on the Blueprint with a short explanation on why these have a significant impact to the overall UX;
4. Next, brainstorm the User Actions that customers take as part of the service delivery process and list them in chronological order at the top of the Blueprint. Don’t limit yourself to the User Actions people currently take, but also brainstorm what the ideal User Actions for the organization would or could be. If this requires additional User Actions (for instance a registration though a website), include these in the steps. For each User Action, make a separate post-it® note and place these on the Blueprint;
5. After all the User Actions are displayed on the Canvas, discuss which of the five psychographic criteria is most important for each User Action, following the approach contained in SAFT2. On each post-it® note you should check the box of the psychographic criteria that is most important for that specific User Action. This will provide you with an accurate understanding of user needs;
6. Now that the User Actions are listed on the Canvas with their corresponding needs, challenge the team to think about how ‘trust’ could be established for each User Action and what the corresponding Physical Evidence would be. Would an additional email (or maybe a text message) increase the level of trust of the users? Make separate post-it notes for each piece of Physical Evidence that would enhance the overall User Experience. Remember that it is not necessary to come up with Physical Evidence for each User Action: the most important principle is that Physical Evidence has an added value for the user.
7. Given the User Actions and Physical Evidence outlined on the Blueprint, determine next which Technology Interface the service is delivered through (or needs to be delivered in the future). Next, start drawing lines that represent the interactions between the first three layers. The Technology Interface (which is the subject of chapter 6) can be a single platform, but can also exist as various different technologies.
8. Support Processes are the sequential steps that service providers make in order to deal with requested User Actions (i.e. delivering a service). For the User Actions outlined in the first layer, determine what support processes are necessary to facilitate (automated) service delivery. Keep the Support Processes on a high level (they will be worked out in later SAF techniques), but ensure that you have covered all processes necessary to deliver an optimal User Experience.
9. As the final step in completing the Service Automation Blueprint, determine which Company Functions are represented in the organization of the service provider and how each Company Functions supports (part of) the Support Processes. Draw lines between the Support Processes and the Company Functions to illustrate which part of the organization is responsible for each Support Process.

The Service Automation Blueprint is now complete! The Blueprint should now give a comprehensive overview of how a specific service could be delivered automatically and what the (technological) requirements would be. Based on this overview, it is now possible to start optimizing parts of the Blueprint in order to enhance the User Experience and deliver long lasting value in a systematic and methodical way.

A completed Service Automation Blueprint might look something like this:

Service Automation Blueprinting challenges organizations to determine how their services are built and what elements are necessary to achieve Service Automation. The aim of this technique is to illustrate graphically how service providers deliver value to Users and what the key interactions and interfaces in their service delivery model are. Although canvasses and blueprints remain abstract models, they can greatly help to simplify complex processes and focus the attention to the place where it should be: the overall User Experience.