Service Automation Framework: Part III

Welcome to the third blog about Service Automation Framework. In the previous blog you read about ‘a the history of Automation'. This blog is about Section 1 - Welcome to the world of Service Automation - H3: Servie Automation Framework.

3.1 INTRODUCTION

In order to really understand the value of Service Automation, it is necessary to discuss some fundamental terms and definitions so that everybody who intends to work with this framework has a similar understanding of the topics under discussion. Way too often team projects fail because of misperceptions about fundamental terms or a complete misunderstanding of language. Since we live in a global world, we therefore think it wise to start with some essential definitions so that everybody literally starts on the same page.

In our endeavor to set some common ground rules, we have aimed to keep the language simple, relevant and intuitive in order to ensure that Service Automation is not just another framework for tech people, who think and talk in technology terms. The concepts of Service Automation are intended for everyone who regularly deals with ‘service’ and has the feeling that the service experience of his or her organization can be improved. That means it is intended for you.

3.2 SERVICE AUTOMATION STRATEGY

This book is titled the Service Automation Framework® (SAF) because it provides the design elements and processes to systematically optimize user experience by delivering automated services. The SAF starts by studying the user experience of user groups to understand the requirements for different user actions and subsequently designs a service solution that satisfies these requirements through user interfaces. The design of user-centered services by itself is nothing new, and has been around since Donald A. Norman invented the term in 1986.6 What is different, however, is that (smart and mobile) technologies over the last ten years have completely transformed our expectations and changed our perceptions about quality services. In less than a decade, we have grown accustomed to the experience that all the information in the world is available with the ‘swipe’ of one finger. Technology has changed our Service Perception, which has a direct impact on the way we experience (and ultimately value) services.

Figure 3.1 Psychology and technology have altered our Service Perception and User Experience

The model depicted in figure 3.1 shows how the user experience of a service is determined. Whether a user experiences a service as ‘valuable’ is predominantly determined by the extent to which the service is able to meet or exceed the Service Perception. Service consumers (i.e. the people who use services) have preconceived notions of what a service is, even if they have not experienced that service previously. In other words, users frame a ‘mental picture’ of a potential service experience regardless of whether it has been defined by commercials, previous experiences or any other source of information. This reference perception shapes how we judge the overall service experience. If you book a flight with a budget airline, for example, your initial Service Perception might be that this airline will have long queues at the check-in counter. When you arrive at the airport and you are able to check-in without waiting, you will probably perceive this as a positive experience, since the service provider exceeded your initial Service Perception. How service providers can use the Service Perception to their advantage is a topic that we will further discuss in chapter 9 (Serendipity Management).

The way people perceive services has always predominantly been shaped by both internal psychology factors and our consumer behavior. Our thoughts and viewpoints determine our preferences and perceptions, and provide us with the impulses that determine whether or not we appreciate or ‘like’ a certain service. Most other service approaches are based on this user-centric model that correctly accounts for human drivers and preferences. Because of the advancements and adoption of new technologies (think about cloud, mobile and apps), we do however envision that a second dimension should be added to the way a Service Perception is shaped. Technology has enabled us to always be connected and mobile devices have become an integral part of our lives. As a result, these technologies now form an additional dimension that shapes our Service Perception. Similar to the ease and variety of products that we can now access and order through technology, we currently hold the same level of expectation for the services we use. In the same example of the budget airline check-in procedure, users now expect that they can check-in through an online platform.

Unfortunately, the majority of service providers have not kept their service offering aligned with the speed of technological advancements. Many existing businesses and organizations have lost ground to competitors in the last decade, because they did not anticipate quickly enough the impact of digital technology, and have not adjusted their service offering to meet the new Service Perceptions of users. The Service Automation Framework aims to demonstrate how organizations can devise new services (or change existing service portfolios) based on the changed notion of how an overall user experience is formed, as illustrated in figure 3.1. It is therefore applicable to both new organizations (i.e. startups) as well as existing service conglomerates.

The Service Automation Framework is therefore not just a process framework or reference guide. It is a business model to realize the digital strategy of organizations large or small, profit or non-profit alike. A strategy is primarily intended to shape the position and perspective of organizations and take the necessary steps to realize them. By adopting a strategy of Service Automation, organizations can prepare for a new generation to come.

3.3 BUSINESS DRIVERS FOR SERVICE AUTOMATION

Modern technology has revolutionized the way services are delivered. Services such as booking vacations were once done only through travel agents via personal contact. Today, users who want to book a vacation can do so through a variety of different channels and different interfaces. Needless to say, companies that embraced the possibilities of facilitating online bookings at an early stage have now become the new market leaders.

Service Automation is therefore not so much an internal reference model through which organizations can organize their service delivery, but a business model that enables an organization to gain competitive advantage in the future. Organizations that establish automated services that are better, more efficient and more focused on user experience have the potential to become tomorrow’s leading companies. Both digital disruptors (think AirBnB, Spotify and Uber) as well as existing service conglomerates (think IBM, Genpact or Accenture) have proven that it is possible to outperform other competitors by focusing on the delivery of automated services. As with any strategic question, the motive of change is primarily driven by increased earning capacity. Service Automation has five key business drivers that enable organizations to outperform their competition:

  1. Service Automation facilitates a scalable business model by which companies can enter new markets more easily and attract new customers;
  2. Service Automation assists companies in making data-driven decisions based on earlier interactions with users and customers. More accurate information provides companies with a competitive advantage;
  3. Service Automation is user centric. Services are always designed with the objective of providing an optimal user experience;
  4. The aim of Service Automation is to automate unnecessary manual labor, providing a more cost-efficient service delivery organization;
  5. And last but not least, by breaking down services into easy-to-understand steps, Service Automation provides a framework for consistently exceeding user expectations. By adopting the concept of Serendipity Management, organizations can transform customers into fans.

The emergence of technology-enabled automated services together with the five key business drivers makes a sound business case for many organizations. Yet the dynamics of trends in modern service technology contrast with the speed through which organizations focus on delivering automated services. Maybe the potential of automation technology is not fully understood in boardrooms yet, or perhaps automation is currently stuck too much in the IT domain. Service Automation, however, is a topic that is quickly climbing up executive agendas, since it is a model designed to increase market share in today’s ‘experience economy.’8 In the following sub-sections we will further explore how design elements and processes contribute to the SAF’s five key business drivers.

3.4 THE DEFINITION OF SERVICE

Service organizations can only deliver services by integrating a number of service assets and capabilities. Much like products, which are composed of hundreds or thousands of elements, services similarly consist of hundreds or thousands of service components. Unlike a product, however, service components are not physical entities, but rather the combinations of personnel, technology, systems and partners that must be appropriately designed and integrated to deliver value to users.

Before we dive further into the concepts of Service Automation, it is important to understand what the term ‘service’ actually means. What are the defining criteria that determine whether a service has been delivered to a user? Is the postcard you receive by mail considered a product or a service? Would a vacation qualify as a service or is this more an experience? And would you think free games on your smartphone qualify as services or are they better classified as software products? When you think deeply about these examples, you will find that the answer is not even that easy.

The definition of what a service really is and what its defining characteristics are has been the topic of long debate. Depending on the specific purpose of services in a predetermined domain, a variety of different service definitions exist. For simplicity, we have chosen to adopt the definition used in Service Management, because this definition has been adopted by the majority of large organizations such as Microsoft, ING, IBM, NASA, the British Government and even The Walt Disney Company (who know a thing or two about services).9 According to this definition a service is:

“A means of delivering value to users by combining organizational resources and capabilities (personnel, technology, systems and partners) to facilitate desired outcomes without the ownership of specific costs and risks.”

Although this is a very simple definition, we think it is a very powerful one, since it clearly states four criteria by which you can easily determine whether something should be considered a service or not. From this point onwards in this publication, we will consider something a service if all four criteria are met:

  1. Delivering value: a service must deliver value in the eye of the recipient. Although the perception of value is highly subjective per individual, it is an essential part of service consumption. If there is no perception of value by a user, something cannot be labeled as a service. Think about the example of postal services. When you receive a card or newspaper subscription by mail, do you consider that of value? If the answer is yes, you make use of a service. If the answer is no (for instance with junk mail), receiving mail is not considered a service.
  2. Facilitating outcomes: a second key characteristic of a service is that it facilitates an outcome, frequently by following a predefined number of activities. A dry- cleaning service facilitates a desired outcome (i.e. clean clothes) by executing a number of steps: picking-up your clothes, washing, dry-cleaning and subsequently delivering them back to your doorstep. They facilitate a process from beginning to end. In the following sub-sections we will explore in detail how successful service organizations master their processes to facilitate desired outcomes for users.
  3. Without ownership of costs: the aspect of ownership of costs might well be the most defining and distinctive characteristic of services, yet it is frequently overlooked. When consuming a service, a user will never become a part ‘owner’ of any of the service assets necessary to deliver that service. When you use a streaming service (for example Spotify or Netflix), you will not become a partial owner of any of the music or movie rights. Similarly, if you book a hotel room anywhere in the world (from hostel to five-star resort), you will never become a partial owner of the hotel bed (which in this case is one of the service assets). Think about any purchase you made recently and ask yourself the question: did I physically start owning any assets after this transaction? If the answer is ‘no,’ it is very likely that you bought a service.
  4. Without the ownership of risk: the final characteristic of a service strongly correlates with the third characteristic, but has an additional dimension – liability. Generally speaking (and it is worth noting that using a service does not equate to not taking risk), service providers are both accountable and liable for the risks and consequences of delivering their services. In other words, service providers have responsibility for their total service assets and users only have the responsibility to use these services appropriately. In the popular example of online services, for instance, the service provider is responsible for the appropriate measures taken against security risks.

We believe the four dimensions discussed in this sub-section are suitable to describe any service. In order to fully benefit from the Service Automation Framework and this book, it is highly advisable to first fully understand the services delivered by an organization. We hope the criteria above provide you with relevant guidance to better understand your service model.

3.5 THE SERVICE CONCEPT

The Service Concept outlines how a service provider can realize the value and desired outcomes of its services. The service concept can best be described as the way in which an organization would like to have its services perceived by its stakeholders. It describes the non-tangible aspects of service delivery and is an integral part of the value proposition of service providers. Whereas with tangible objects the final product is mostly the sum of its parts, this is certainly not the case with services. Various studies have shown that users tend to see a service as a ‘whole experience.’ For example, a day at Disneyland’s Magic Kingdom is more likely to be defined by its visitors as a magical experience rather than six rides and a burger in a clean park. The service concept facilitates this holistic approach by providing a detailed description of what is to be done for the user (what needs and wishes are to be satisfied) and how this is to be achieved. As such, the service concept can be a major driver for the Service Design phase of (new) services.

The service concept consists of the holistic combination (i.e. all element should be considered equally) of four dimensions:

  1. Service operation: the way in which the service is delivered;
  2. User experience: the user’s direct experience of the service;
  3. Service outcome: the benefits and results of the service for the user;
  4. Value: the benefits the user perceives as inherent in the service, weighed against the cost of the service.

The four dimensions of the service concept form a key to defining how the stakeholders in an organization perceive the value of services, minimizing the gap between user expectations and the service delivery operation:

Figure 3.2 The four dimensions of the Service Concept

The service concept plays an important role in determining the Service Automation strategy for organizations, and the subsequent design and development activities. It is positioned as a high-level and overarching concept that gives input to the overall strategy of the service provider. In sub-section 3.9, we will discuss in further detail how the service concept fits in the bigger picture of automation.

One of the most distinctive characteristics of services is their process-oriented nature. Each service can be seen as a chain of activities that help a service to function effectively. For example, a package delivery service consists of a number of activities that need to be executed in a predetermined order. First, you need to register your package with the shipping company. Next you print the package label and attach this to the shipment item. Finally the courier will pick up the package and subsequently ensure that it is delivered at the designated address. Each of the activities mentioned is part of a larger (again holistic) process that constitutes the whole service. Because each activity contributes to a singular outcome of a service (in this example the shipment of the package from A to B) the service concept of any organization needs to take into account that its potential to deliver value is only as good as its weakest link. If any of the activities in the sequence fail, the user will have a very poor user experience because the desired outcome of the service is not achieved.

Almost every service provider delivers not one, but a variety of different services, which can all be considered as separate processes of value creation. Service organizations do, however, only have one service concept, which functions as an overarching directive to all other services. It is the glue that binds the individual services of an organization together, aiming them towards the common objectives of the service concept. As such, the service concept aligns an organization’s service offering towards a common direction by setting overall goals and objectives that apply for the complete collection of services. This is especially so in larger organizations, which offer a variety of different services, where establishing a uniform service concept greatly helps in determining and setting priorities.

Figure 3.3 The Service Concept directs the design of multiple services

The primary goal of the Service Concept is to determine the desired service outcomes and value of a service provider, which is subsequently incorporated into the design of the organization’s various services. A firm that delivers accountancy services, for example, might have a service concept that concentrates on national delivery (service operation) of various accounting services (value) that comply with all relevant rules and regulations (service outcomes) and that primarily focuses on online delivery (user experience). Although this is an extremely abbreviated example of a service concept, it can set the direction for all services of the accountancy firm. Each of the organization’s accountancy services, which are all individual processes, can be related and designed based on the service concept. Ultimately, the service concept might form the foundation upon which organizations can start managing their service portfolio, which is the collection of various services a service provider offers.

3.6 THE DEFINITION OF SERVICE AUTOMATION

Now that we have discussed the essential characteristics of services and the different domains of the service concept, we would like to introduce you to the concept of Service Automation. The term ‘Service Automation’ has been used before in other publications, but almost exclusively in the context of IT in relation to technical interfaces. In the Service Automation Framework, the scope of the term ‘Service Automation’ is extended to encompass the larger organization, including service design, technology, processes and organizational structure. The full scope of the definition will further be explained in subsequent chapters, but to start with the end in mind, our definition of ‘Service Automation’ is:

“Service Automation is the practice of an industry that enables their autonomous users to procure, manage and adjust services through self-service technology and concepts in order to systematically exceed user expectations.”

First of all, it is important to note that we deliberately chose to label Service Automation as a practice, which is a way to work on a daily basis. As such, it is intended for managers and practitioners, who can both benefit from the practice by adopting it in their daily work. An industry practice is an approach that many companies already use in their day-to-day operation (without calling it a practice) and which is intended to continually improve over time. As the word implies, a practice is aimed at ‘practical use’ (something that you’ll have to do) in order to become successful. Examples of other practices are for instance project management or hospitality management.

The second key deduction from the definition is that Service Automation is a model that delivers value to an organization’s users by the use of self-service technology and concepts. This means that there is (maybe not entirely surprisingly) always a technology component involved. In the practice of Service Automation there needs to be an interface between a user and a service provider through which the service can be procured, managed, adjusted or delivered. In today’s world, the interface will most frequently be a web portal or mobile app.

Please note that the delivery of services through self-service technology and concepts does not automatically mean that the service itself needs to be digital, a mistake frequently made. The most famous example (for a company that has only existed since 2009) is Uber, which delivers an online service to get you from location A to location B through the thousands of cabs and cars in their network. Although Uber’s service delivery model is completely based on Service Automation, the actual service is still very much analog. A driver still needs to take you to your location with a car on wheels, requiring physical service assets such as time, personnel, technology and (preferably) driving skills.

The last element of the Service Automation definition is possibly the most important. The whole practice of Service Automation is based on the philosophy that an organization’s users are autonomous and are able to request the services they need. Although this sounds relatively straightforward, it is frequently the most difficult step for organizations, since it requires a different mind-set and culture for the entire organization. Traditionally, organizations were formed on an hierarchical structure through which management devised the products and services that needed to be pushed to their users from their ivory towers. The Service Automation Framework is based on exactly the opposite approach, and is rooted on the premise of user autonomy. With the omnipresence of technology and information every single day, users have become autonomous in their decisions in terms of which services they would like to use and they have grown accustomed to arranging these services by themselves (i.e. self-service). The new role of service providers, on the other hand, is to facilitate their users by making their service portfolios easy to access and easy to use. By providing user-centered services that meet or exceed user expectations, the service provider ensures it delivers services that provide desired outcomes and actual value. Successful Service Automation therefore starts with the realization that in today’s technology-enabled world, services should be delivered that fit the requirements of autonomous users (i.e. a service pull), instead of the other way around. After all, since you are probably also a service consumer, don’t you prefer to choose for yourself which services fit your actual needs?

Figure 3.4 Service Automation is based on the autonomous ‘Service Pull’ of a user

Following the definitions and premises of Service Automation, the user is positioned centrally in the Service Automation Framework. But before we discuss the details of the individual elements of the framework, let us explain all elements of the complete model first. Sections 2 and 3 of this book will subsequently address each of the topics in further detail.

3.7 THE SERVICE AUTOMATION FRAMEWORK

The anatomy of a service – the heart

The moment has finally come to introduce the Service Automation Framework, which covers six distinctive building blocks through which you can start using the concepts of Service Automation. Although there is a logical sequence in the order of the building blocks, each one is equally important in achieving the overall benefits and value of Service Automation.

The Service Automation Framework starts with the three concentric circles, which together form the foundational building blocks for delivering valuable services to users. In a similar way to how a human body is structured by its anatomy, a service can be structured by the first three building blocks of the Service Automation Framework. As depicted in figure 3.5, the inner circles consist of the following elements:

  1. User: the building block that defines the key characteristics of the groups of people a service provider aims to serve;
  2. Service Design: the business function that designs and defines the service offering of a service provider. It is the concretizations of the service concepts into an actual design, including the relevant support structures and digital interfaces;
  3. Technology: the building block that defines the setup and usability of the digital interfaces, connecting service providers with their users.
Figure 3.5 The Service Automation Framework

The first three building blocks are at the core of any service provider’s business model. Successful service organizations deliver their predefined services (service design) to customers (users) using some assets or tools (technology). If you are working in any service-oriented organization, this should be a very familiar concept. Yet, it is sometimes surprising to see how little time organizations take to critically evaluate how their services are composed. By analyzing the composition of an organization’s service offering, a variety of insights can be gained. To illustrate the importance of the first three foundational building blocks, think about how the following ‘brick- and-mortar’ companies benefit from knowing exactly the anatomy of their services:

  • The Walt Disney Company, one of the leading ‘experience’ companies in the world, figured out that it had defined different ‘user profiles’ at a very early stage. Disney mainly targets children and their families; it uses the multi-segment targeting strategy, which is when a firm chooses to serve two or more well-defined market segments. Disney intrigues people of all ages; whether it is a child, teen, or parent. The company knows precisely what the characteristics of their users are and adjusts its services to this segment.
  • American Airlines, the world’s largest airline, is active in a market characterized by fierce competition and many big players. Although the primary objective of the company is to transport you safely from A to B, the company has mastered how to provide additional services to its clients. Its frequent flyer program offers many additional services, which have been carefully designed as a customer loyalty incentive. Each service (from lounge access to taking extra luggage) has been designed with meticulous precision, leaving no doubt what you can expect when buying or consuming such a service.
  • The BMW Group, a luxury car manufacturer that sells around two million cars each year, services thousands of cars per month for repair and maintenance. This immense operation would not be possible if BMW did not have technology with distinct information between the types of repairs and the necessary spare-parts and tools to quickly and adequately repair a specific model from a specific year. The company’s technology is crucial for the delivery of its services. Without it, the company’s service operation would stop immediately.

The examples above are purposefully chosen as ‘non-tech’ companies in order to illustrate that ‘service anatomy’ is relevant for each type of service provider, digital or not. A clear understanding of users, service design and technology form the basics before any company can benefit from Service Automation, since it provides an answer to three fundamental questions:

  1. Users: whom exactly are you delivering your service to?
  2. Service Design: what services exactly are you delivering or selling?
  3. Technology: which tools exactly do you need to deliver the service?

In the next section (Section 2: The Deep Dive), we will further explore the technique of the Service Automation Blueprint and provide additional guidance on how the combination of Users, Service Design and Technology can help organizations to express their service offering.

The automation of a service – the brain

After the first three defining aspects of a service (equally important, but applicable to all services in the world), we can now introduce the ‘automation’ elements – the methods and processes that make the service fit for automated delivery. This is where platforms, technology and the bits and bytes come into play. In order to start delivering automated services, automation technology is logically required. Luckily, the majority of organizations will not have to start ‘from scratch,’ since the reality is that most service providers have already automated some parts of their service delivery (for example a simple request form on a website). Even the most analog service providers these days have some processes (partially) automated.

The first three elements of the Service Automation Framework all deal with the core of services, which is why we have chosen to label these building blocks as the ‘heart’ of Service Automation. Similarly, the other three elements of the Service Automation Framework make the model ‘smart,’ which means that they provide the methods and processes that enable the service to interact with users without human intervention. Consequently, these three building blocks can be considered the ‘brains’ of Service Automation:

  • Automated Deployment: the processes that enable a user to start using a service based on his or her own action;
  • Service Delivery Automation: the processes that enable a user to change or resolve any aspect of the service based on his or her own action;
  • Serendipity Management: the processes that facilitate a planned and continuous approach in order to constantly exceed the expectations of users.

Although all three above elements strongly interact with each other in order to deliver quality services, there is a clear distinction between the three that is easy to remember. Automated Deployment is the building block that has everything to do with the first or initial setup of a user who wants to start using a specific service. Think about the first time you registered with Facebook or Twitter and remember the steps you needed to follow. Even for the simplest of services, it is necessary to set-up an account or to leave some information such as your name. You can compare the aspects of Automated Deployment with the checking-in procedure of a hotel. All the steps you take before you can actually start using the service are part of Automated Deployment. In the example of checking-in to a hotel, these activities might include registration at the check-in desk, filling out your credit card forms, or the bellboy who shows you your room (assuming you are staying in a nice place).

Service Delivery Automation is the building block that encompasses all the elements of a service whilst using a service. It is different from the previous building block (Automated Deployment) in the sense that a service in this stage is ‘in progress.’ The primary focus of this building block is to simulate likely scenarios that can happen while a service is being consumed. Most frequently, support scenarios will have to do with finding information or fulfilling service requests. Coming back to the scenario of the hotel visit, Service Delivery Automation deals with all of the elements a hotel can encounter after a person has checked-in. A hotel guest might want to know where the best restaurants nearby are (an information request), or they might want to have additional towels in their room (a service request). The hotel management frequently knows that these kinds of requests (or scenarios) are likely to occur and has prepared a variety of solutions on how to deal with these questions. That is why (in most hotels) you can get a map at the front desk and there are additional towels stored on each floor. All elements that deal with supporting users – while they are using a service – belong to the domain of Service Delivery Automation.

Finally, Serendipity Management is the practice of constantly exceeding user expectations in a structured and planned manner. This building block is the primary business case for starting with Service Automation in any organization, because service providers that manage to exceed user expectations will outperform their competitors. These organizations transform their users into loyal fans. While this may sound a bit vague at the moment, let’s think about the hotel service example one more time. How would you feel if you found a personalized goodnight poem on your pillow every night? What would you think when at checkout you receive an additional 5 percent discount? Or what if your car had been washed when it came out of the hotel parking? All are elements which you do not expect when booking a hotel night, but think about them… Would they be very hard to realize for any company on a structured basis? Frequently, it is a matter of designing a process just once. Serendipity Management deals with all aspect of structurally meeting and exceeding user expectations. Very few organizations in the world have mastered this skill, but the organizations that do manage to achieve this proficiency turn out to have loyal users for life.

3.8 DESIGN ELEMENTS AND PROCESSES

Summarizing the previous two sub-sections, there is a clear and deliberate distinction between the first cluster of building blocks (‘the heart’) and the second cluster (‘the brains’). As a defining characteristic, remember that the first building blocks (Users, Service Design and Technology) are generic to any service, whereas the last three building blocks (Automated Deployment, Service Delivery Automation and Serendipity Management) are specific to the automation of these services.

Similar to the composition of the Service Automation Framework, this book is further structured in accordance with the two different domains of Service Automation. In the next sub-section, we will initially discuss the ‘heart’ of Service Automation, which primarily consist of design elements. After we have discussed the design and set-up of different services, we will then focus on the ‘brains’ of Service Automation, which is subdivided into a number of processes:

  • Design elements are the tools and models that can be used to generate and describe viable services. All design elements when combined form a Service Automation Blueprint;
  • Processes are the sequences of steps used to deliver, support and improve services over time. All processes have a clear beginning (a trigger) and a predefined result (outcome).

As you probably noticed from the definitions, design elements are used to adequately build services, whereas processes are used to deliver, support and improve services. Both domains have very different dynamics and support different business objectives. With design elements it is important to take the time to make the design ‘right-first-time.’ Processes, however, are set up to improve over time based on the input and experiences of users.

Take for example Amazon.com, a platform that delivers millions of products across the entire globe. As you can imagine, the success of their business is largely dependent on the adequate design of their online platform and corresponding services. The main design of their systems and services will therefore not be updated frequently, since it is their core value proposition. The processes that support Amazon’s service delivery, however, can be more easily adjusted, based on the input of users. Following an analysis of their support processes, for example, it might be possible that some of their products are damaged easily during shipment, which is a trigger for a re-evaluation of the packaging process. A different packaging process will not change the core services of Amazon (i.e. the Service Automation Blueprint), but is an adjustment to improve the overall level of service. In chapters 4 to 9, we will cover design elements and processes in more depth. In summary, the key distinction between the two main dimensions of the Service Automation Framework are listed in table 3.1:

DimensionThe heartThe brains
ObjectiveDesignDelivery, support and improve
Domain focusDesign elementsProcesses
Building blocksUsersService DesignTechnologyAutomated DeploymentService Delivery AutomationSerendipity Management
PeopleCreativeControlling
Table 3.1 The ‘heart’ and ‘brains’ of service automation

A second defining difference between the heart and brains of Service Automation is that they frequently involve different people within the organization. Innovative (service) design typically requires creativity and a mindset that is focused on the process of creation. Process design and implementation, on the other hand, requires a more detailed and precise attitude, aimed at continual improvement of the organization.

3.9 SERVICE AUTOMATION IMPLEMENTATION

In this chapter, we have started to introduce a variety of new terms and theories in order to describe some elementary concepts about Service Automation. We discussed the topics of automation strategy, the service concept, service definitions and the Service Automation Framework amongst others. In order to make Service Automation work in new or existing organizations, these concepts need to be combined to accomplish an overall and integral implementation approach, as depicted in figure 3.6.

Figure 3.6 The Service Automation Implementation Approach

The Service Automation Implementation Approach is an overarching and high- level model for organizations that want to embed Service Automation into their strategy and daily execution. The approach provides guidance on how the various topics can be placed in ‘the bigger picture’ of service organizations. Starting at the top of the model, the Service Concept provides guidance for organizations by determining the four dimensions (service operation, user experience, service outcomes and value) that position the service provider in the market. It defines, in terms of service, who a service provider aspires to be and how a service provider wants to be perceived by its major stakeholders.

Because the service concept sets the direction for all services in an organization, it provides a key input into the overall Service Automation Strategy by delivering a long-term perspective. As discussed previously, a Service Automation Strategy defines how organizations can prepare for an altering Service Perception towards the future. In order to prepare for that future, individual services can be designed and implemented, using the model of the Service Automation Framework as depicted in figure 3.5.

The Service Automation Framework provides guidance for each service from the design phase towards the final implementation of the supporting processes. The SAF follows a step-by-step approach to automate the service offering of an organization through six distinct building blocks. Using a variety of techniques, such as the Service Automation Blueprint, services are designed to optimize the overall User Experience of service consumers. The User Experience is a performance indicator that can subsequently be measured in order to determine overall opportunities for further improvement to either individual services (feedback to the SAF) or the organization’s overall strategy (feedback to the Service Concept).

The Service Automation Implementation Approach serves as an overall model to guide organizations both small and large towards the use of automated services. Whether you are an existing service conglomerate that provides thousands of services each year or just a small regional company that provides only a handful of services, the model applies equally to all organizations. In order to make the implementation approach even more tangible, we have constructed a number of Service Automation Framework Techniques (SAFTs) that serve as the common theme throughout the rest of this book. These SAFTs break down the implementation approach in further detail and provide practical advice on the steps to take in order to implement Service Automation in your organization.

Figure 3.7 The seven Service Automation Framework Techniques (SAFTs)

3.10 ORGANIZING FOR SERVICE AUTOMATION

Now that we have reached the end of the introductory pages, we hope you understand that Service Automation is a concept and model that, when executed correctly, can change the strategic direction of an organization. The task of implementing Service Automation is therefore not an exercise that should be left to the IT department. The design and implementation of Service Automation is a team exercise that requires involvement and participation of people from across the entire organization. It is a joint effort that exceeds organizational functions and structures.

One of the critical success factors for the adoption of Service Automation is to assemble the right team with an adequate mix of skills and capabilities. People that have daily functions in more design-oriented roles (i.e. the heart) frequently contribute in terms of creativity and the generation of new ideas. People in more process-oriented roles (i.e. the brains), on the other hand, tend to contribute to the overall feasibility and realization of Service Automation. Diversity works. Composing a team that adequately represents both disciplines helps to identify new service concepts or devise different user experiences. In order to assemble a Service Automation team to start implementation, we have outlined some common job roles in figure 3.8 below which are in line with the Service Automation Implementation Approach.

Figure 3.8 Common job roles for Service Automation Implementation

Service Automation Foundation
Jan-Willem Middelburg
Service Automation Foundation Courseware E-Package

Please wait...

X
Added to your cart