First we should explain the Service Automation Framework (SAF). The SAF is a set of best practices for the automated delivery of services. The Service Automation Framework is maintained and updated by the Service Automation Framework Alliance, an independent body of knowledge for the advancement of service automation.

The framework is used to describe different processes, tasks, procedures, and checklists that aren’t organisation-specific, so they can be applied by any organisation wishing to achieve service automation. Having a framework allows a business to establish a foundation from which hit can plan, implement and measure their objectives.

As mentioned before, Service Automation Blueprinting is one of the seven techniques of the Service Automation Framework. Think of a blueprint for a building to be constructed. The blueprint gives information about the building’s foundation, structure, materials, design and overall plan. This information helps the construction workers and engineers plan the construction from start to finish and have an end-goal in mind. Likewise, the SAF blueprint gives organisations a visualisation of how to automate a service.

The SAF 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). In the figure below, we can have a look at a blank version of the Service Automation Blueprint.

The different layers of the 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 behaviours of Users. Although certain behaviours 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 enables interactions between the two parties. As such, it is the medium through which a service provider interacts 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. 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 realise a suitable Technology Interface. An organisation 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 characterised by their sequential activities that can be visualised 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 organisational 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 organisation, we have listed them as a separate and final layer.

Service Automation Blueprinting challenges organisations 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.