1 Traditional concepts in service design and service quality
The services sector was initially considered as a tertiary and residual economic category after agriculture and manufacturing. Many classification systems for services contained long lists of categories in which one person provides a service to another. As a by-product of this approach, we use “people-oriented” words like “experience,” “performance,” “empathy,” and “dramaturgy” to describe service interactions.
1.1 Service quality
For person to person services, a central idea is that the quality of the service is determined in the service encounter at the “moment of truth” when the service is delivered or “co-produced.”
-
“In most services, quality occurs during service delivery, usually in an interaction between the customer and contact personnel of the service firm” (Zeithaml et al. 1998).
-
“Service encounters are critical moments of truth in which customers often develop indelible impressions of a firm… From the customer’s point of view, these encounters ARE the service” (Bitner et al. 2000)
Anzeige
This framework makes service quality highly subjective because it is measured from the perspective of each service consumer. Service quality is typically defined as the difference between the level or nature of service that the customer expected and the level or nature that the customer perceives (Zeithaml et al. 1998).
1.2 Service intensity
A subjective perspective on service quality implies that many of the key design decisions relate to the intensity of the service, which is conventionally defined in terms of the number of actions initiated by the service provider (“the bundle of services”, Friesner and Rosenman 2005) or the duration of the service encounter (Teboul 2006). Implicit in this definition of intensity is the assumption that the service consumer recognizes and values when a service provider increases it. Intensity strongly influences how usable, enjoyable, and responsive the service appears to the service consumer.
Intensity is not the only factor that influences service quality, so it is a somewhat coarse measure of service designs (e.g., “sincerity,” “attentiveness” and other “communicative aspects” can also matter, Sparks 1994; de Ruyter and Wetzels 2000). But the intensity metric can usefully be employed to make relative assessments of the set of services offered by some service provider like a hotel: Budget hotels provide a lower level of service intensity than luxury ones because they offer fewer services, and each of the services is likely to be of lower intensity than the comparable service offered by luxury hotels.
1.3 Service variability
Most consumers of person-to-person services expect some flexibility or customization because limited choices can give a service a transactional and “take it or leave it” character that customers perceive as a low quality experience. Therefore, an important concept in service design is to “empower” the service provider/employee to adapt the service or provide additional services to solve problems or handle unexpected events (Lashley 1995), or just so that the customer can “have it his way” (Frei 2006). This view treats variability in service delivery as inevitable and perhaps even desirable.
Anzeige
1.4 Service encounters that illustrate these traditional concepts
We can illustrate these concepts with two versions of the “checking into a hotel” experience:
In Scenario #1, which might take place at a budget hotel chain, the front desk clerk at the hotel does not recognize a returning customer, shows little empathy toward him, and delivers a low-intensity experience with no variability that the customer probably perceives as low quality. In contrast, in Scenario #2, which might take place at a luxury hotel, the front desk clerk creates a much richer and customized service experience that demonstrates knowledge about and concern for the customer. The customer probably perceives this as a high-quality service experience.
Examples like these with hotel check-in suggest that the design dimension of service intensity has a simple monotonic relationship to service quality—namely, that more intense services (like extensively personalized ones) are of higher quality.
2 Problems with the traditional concepts raised by automated services
These two contrasting hotel check-in scenarios seem to validate the traditional notions of how intensity, variability, and a focus on the service encounter contribute to quality in person-to-person services. But this traditional view does not fit well when person-to-person services are replaced or complemented by automated services. This is easy to see in three more examples of the “checking into a hotel” experience.
Scenario #3 might have taken place in the same luxury hotel as scenario #2. The service intensity is the same or greater as that in scenario #2, and the hotel reception employee is empowered and acting in a highly empathetic and responsive manner to make the customer’s experience a good one. But the customer will perceive the quality of the service encounter to be poor, much lower than even that in scenario #1.
Scenario #4 is as a “self-service” check-in application where the former encounter with the hotel reception employee has been replaced with an automated system or kiosk. The service intensity, if measured in terms of the number of service provider actions and information exchanges, is nearly identical to that of scenario #1. But most customers would rate the quality of the service encounter in scenario #4 to be significantly higher than that in scenario #1 because they expect less of a machine than of a person.
Scenario #5 has little more nominal intensity than scenarios #1 and #4, but “Welcome back” and the preferred room 321 demonstrates that that hotel recognizes a repeat customer and his preferences, which would cause the customer to rate this as a good encounter.
2.1 More intensity is not necessarily better
The successful deployment of self-service applications like the automated check-in service in scenario #4, bank ATMs, and millions of web sites demonstrate that people sometimes do not want to deal with a person to obtain a service, or they desire service at times and in locations when it would not be economical for a person to provide it. But in most self-service applications, intensity according to the traditional measures of the number of interactions or duration is lower than for person-to-person services. The notion that intensity per se determines quality is too simplistic, and we need to revise its definition so that it applies to self-service applications.
Likewise, the apparently low level of service intensity in scenario #5 is not a concern to the customer, and he might even have preferred the low-key manner with which the reception employee recognized him to that in scenario #1, where the employee revealed personal information and preferences in a way that others might have overheard them.
2.2 Predictable service outcomes are preferred to variable ones of higher quality
If intensity alone determined quality, no rational person would prefer self-service. But, if the perceived quality of service reflects the extent to which the service encounter meets expectations, then some customers must prefer the predictable experience in a self-service encounter. This preference may indicate that while there is potential for a higher quality of service in a person-to-person encounter, the higher variability and potential for a low quality one is purposefully avoided.
This somewhat counterintuitive result calls into question the traditional view that variability in the delivery of service is inevitable and desirable. Instead, we are reminded of Levitt’s classic statement about the industrialization of services that “discretion (on the part of service employees) is the enemy of order, standardization and quality” (Levitt 1972) and of similar principles embodied in “Six Sigma” quality programs (Juran and Godfrey 1998). Furthermore, studies suggest that deviations from expected quality in a service encounter have asymmetric effects on customer perceptions (Smith et al. 1999). A bad experience negatively affects longer-term quality measures like intention to return and likelihood of communicating positively about the service. Customers might need as many as 12 positive experiences to compensate for the effects of one bad experience, and they might not be willing to give the firm the 12 chances.
2.3 Multichannel services change the calculation of service quality
Self-service applications like the automated hotel check-in in scenario #4 often complement or supplement rather than replace a person-to-person service. These “multichannel” services have both person-to-person contact and self-service or “virtual” channels (Sousa and Voss 2006).
Recent studies on quality for multichannel services confirm that customer expectations for the virtual channel are often different than for the person-to-person (or “physical”) channel (Falk et al. 2007). Furthermore, customers are influenced by the extent of integration and consistency between the two channels. These factors are becoming even more important because functions are increasingly being copied, reallocated, or adapted between the virtual and physical channels; consider how books can be “browsed” in an online bookstore and how physical bookstores now commonly enable their customers to search online catalogs.
3 The “front stage” and “back stage”
We’ve now noted some inconsistencies about fundamental concepts in service design like quality, intensity, and variability. We can begin to reconcile them if we introduce a distinction between the “front stage” and “back stage” of service delivery.
A focus on the service encounter implies a sharp distinction between the interactions between the customer and provider that are part of the service encounter and other activities that precede it to make it possible. The former comprise the “front stage” and the latter the “back stage,” which are separated by the “line of visibility,” so-called because, by definition, any activities or services that are invisible to the customer are behind the line (Teboul 2006).
This framework makes a key decision in service design the placement of the line of visibility in the chain of activities that process the materials or information needed in the service encounter. The classic illustration of this idea is in the design of restaurants; fast food outlets, gourmet restaurants, and “entertainment” establishment like Benihana where meals are prepared at the customer’s table can be contrasted in terms of the line of visibility that separates food preparation and delivery. Indeed, Benihana advertises that it provides not just food but “an experience at every table,” highlighting the theme that it has moved back the line of visibility to enlarge the front stage as much as possible.
3.1 The front and back stages of hotel check-in
When we first looked at the five scenarios of checking into a hotel, we did so with a focus on the service encounter taking place in the front stage. If we revisit each scenario with the front/back stage distinction in mind, we can see that the customer experience is substantially determined by back stage activities and information, or the lack of them.
3.1.1 Scenario #1
After the customer provides his last name, we can infer that the reception employee looks up the customer’s name in a back stage reservation system or on a check-in list extracted from it that indicates the room assigned to the customer.
3.1.2 Scenario #2
At first glance, we might have attributed this intense and highly customized check-in experience to the excellent memory of an empowered employee who wants to please the customer. But it is unlikely that this particular employee was on duty when the customer checked in months before, when the customer praised room 321, or asked about baseball tickets. Instead, the reception employee is more likely retrieving institutional knowledge about customer room and entertainment preferences. At hotels that pride themselves for high quality service, employees are trained and incentivized to record and retrieve this kind of information so that they can enhance customer experience in front stage encounters (Kolesar et al. 1998). But the information is managed in back stage applications, and if it is not there, the front stage employee is less empowered.
3.1.3 Scenario #3
Here is it obvious that despite the intense efforts of the reception employee in the front stage, the negative quality of this service encounter is clearly being caused by the failure of a back stage process. The customer had perceived his self-service hotel reservation experience to be successful—when his interaction was in the online booking service’s front stage—but the reservation was not successfully transmitted from their back stage to the hotel’s back stage. In addition, even though the customer will experience additional service intensity during his wait in the lounge, this intensity increment is undesirable and would have been unnecessary if the reservation systems of the partner hotels were integrated into the check-in front stage.
3.1.4 Scenario #4
Some aspects of the customer’s quality perception in the check-in experience are based on front stage characteristics like the usability, esthetics, or responsiveness of the check-in application. But as we see in comparing scenarios #1 to #3, without an effective back stage reservation system quality would be poor. And perhaps the assignment of room 321, the customer’s preferred room, is a result of effective use of the back stage knowledge management system we inferred in scenario #2.
3.1.5 Scenario #5
There is little front stage experience here, but the customer knows from his previous stays at this hotel that when he walks into his favorite room 321, many details will be customized using his preferences and service history stored in a hotel system-wide database. If tickets for tomorrow’s baseball game are waiting in the room, they will be a pleasant confirmation that the hotel values his customer loyalty by keeping track of his previous service requests so that he does not have to repeat them. The hotel’s reliance on its back stage information systems to enable an exceptional customer experience is exemplified by the Ritz-Carlton Hotel Company’s credo that its experience “fulfills even the unexpressed wishes and needs of our guests” (Ritz-Carlton 2008). For example, the Ritz-Carlton customer information system records which fruits a guest eats from a “welcoming” fruit basket so that future baskets contain only preferred fruits (Wreden 2005).
3.2 Refining our notions of intensity and variability
The front stage/back stage distinction helps to resolve some of the apparent inconsistency in the concepts of service intensity and variability. Intensity is not an intrinsic property of how some type of service is provided. Instead, we should treat it as a design parameter whose value reflects decisions about whether some component activity in a service value chain should be exposed in the front stage or hidden in the back stage. Self-service and full service experiences are endpoints on a design continuum (Mills and Moberg 1982) and as each of us knows from our own experience with hotel check-in and restaurants, a person might prefer low intensity self-service sometimes and high intensity full service at other times (Frei 2006; Meuter et al. 2000).
Likewise, the front stage/back stage distinction reconciles the conflicting views about the desirability or inevitability of variability in service delivery. Variability in the front stage often arises when an empowered employee improvises or innovates to satisfy a customer making an unexpected request or complaint. For example, a hotel reception employee might offer a free upgrade to a higher quality room than the customer reserved. This kind of opportunistic variability that improves a service experience is usually desirable as long as any relevant information about the unplanned variability is communicated efficiently to the back stage. Otherwise, the benefit of improved service experience for the upgraded customer could be negated by a worse service experience for another customer who gets downgraded at check-in because the room class he reserved is no longer available.
In contrast, outcome variability caused by a failure in the back stage—like the missing room reservation in scenario #3—is always undesirable. When it propagates into the front stage there is often little even the most empowered employee can do to remedy it.
Finally, there is often an inverse correlation between the potential for intensity and variability in the front stage and the extent to which variability is eliminated in the back stage through standardization or process controls. This tradeoff is embodied in our restaurant example. Moving food preparation activities to the back stage results in production efficiencies and economies of scale in fast food restaurants, but simplifies or constrains what can be offered in the front stage services.
4 The challenge of bridging the front and back stages
Revisiting the five hotel check-in scenarios with the complementary perspectives of the front and back stages in mind gave us insights that we missed with the narrower approach of focusing on the front stage encounter. This suggests that service designers should adopt a more comprehensive approach that considers the relationships and tradeoffs between the front and back stages from the outset. But this is easier said than done, because we have observed that service designers tend to adopt either a front stage or back stage mindset.
4.1 The front stage mindset
Service designers with a “front stage mindset” strive to create service experiences that people find enjoyable, unique, and responsive to their needs and preferences. Front stage designers use techniques and tools from the disciplines of human–computer interaction, anthropology, and sociology such as ethnographic research and the user-centered design approach to specify the desired experience for the service customer. They capture and communicate their service designs using modeling artifacts that include personas (Cooper 1999), scenarios, service blueprints (Bitner et al. 2008), and interactive prototypes.
4.2 The back stage mindset
Service designers with a “back stage mindset” follow different goals and techniques. They strive for efficiency, robustness, scalability, and standardization. Even though some back stage activities are carried out by people, and others carried out by automated processes or applications, the back stage mindset tends to treat people as abstract actors.
So instead of modeling the preferences and interactions of people, back stage designers identify and analyze information requirements, information flows and dependencies, and feedback loops. They use concepts and techniques from information architecture, document engineering, data and process modeling, industrial engineering, and software development. Their typical artifacts include use cases, process models, class diagrams, XML schemas, queuing and simulation models, and working software.
4.3 Conflicts and a lack of collaboration
If our characterizations of the front and back stage mindsets seem somewhat caricatured, this is done on purpose to make the contrasts stand out. But front and back stage designers usually look at service design from vastly different perspectives. There is often little collaboration and communication between front and back stage designers in service design projects—sometimes for organizational reasons, sometimes for ideological ones, and sometimes simply because it is hard to work effectively with someone who thinks so differently even when you try. The results are predictable:
Front stage designers might say:
-
“Those software developers build systems that constrain our ability to deliver the services the customer wants”
-
“Sure, standards are good… but people have different capabilities and preferences and they need different user interfaces”
Back stage designers might say:
-
“Those interaction designers always propose services that the back end can’t support”
-
“They should just study the service interfaces to the ERP system… can’t they all read XML schemas?”
-
“If every experience has to be different, how can our implementation be robust and scaleable?”
We do not believe that these tensions and conflicts between front stage and back stage designers are intrinsic or fundamental. But to avoid them, we need a more comprehensive and end-to-end conception of services that treats the entire network of services that comprise the back and front stages as complementary parts of a “service system.” We need more common vocabulary so they can appreciate each others’ concerns and constraints, and we need new design themes or principles that encourage them to view problems from the same or complementary perspectives rather than from antagonistic or competing ones.
5 The front and back stages as components of service systems
Spohrer, Maglio and other IBM researchers in service science defines a service system as “a value-coproduction configuration of people, technology, other internal and external service systems, and shared information (such as language, processes, metrics, prices, policies, and laws)” (Spohrer et al. 2007). This new concept in service design has roots in classic work by Levitt (1972) and Mills and Moberg (1982) to apply manufacturing system concepts to services and by Heskett et al. (1994) that analyzes the mechanisms and interdependences in what they call the service profit chain.
The service system concept underlies the essential claim of this paper that a service outcome is never the result of a single encounter between a service provider and service consumer. Instead, it emerges from the service system of back and front stage services that establish the context and satisfy the preconditions for the final service encounter to take place. There may be a “moment of truth” in which the quality of the service experience becomes apparent to the service consumer, but that quality was enabled or constrained to a greater or lesser extent by the entire service system.
We might describe the hotel check-in experience in a coarse way as a service system consisting of several interrelated sub-systems: hotel employee-to-customer, customer self-service in the hotel, employee-to-hotel systems, customer self-service to third party services (like Expedia), and hotel systems to third party services. This end-to-end view shows that the quality of the experience for the customer is enabled or constrained at many points, including many in the back stage that are invisible to the customer. Indeed, some of them are even invisible to the hotel employees.
Service systems can be described in terms of their qualitative properties like connectivity and intensity as we’ve done with our hotel check-in example, or more rigorously and quantitatively using mathematical models or simulations.
5.1 Quality in service systems
The idea that service quality is a property of a service system rather than of a service encounter is especially easy to see in self-service Internet commerce. A service designer with a front stage mindset might work diligently to improve the customer’s online ordering experience, but the customer’s quality of service is only in a very small part determined there. The complexity and deferred nature of physical fulfillment when goods are ordered online provide many ways for the service to fail (the goods might be out of stock, they might fail to arrive when promised, they might arrive damaged, and so on). The customer’s perception of the service quality will mostly depend on the fulfillment outcome, and measures of the quality of service during the online service encounter are insufficient or even irrelevant.
Because a service system takes an end-to-end view rather than focusing on the last service encounter, the concept of quality in service systems turns out to be similar to that embodied in the “quality movement” and statistical process control for industrial processes (Juran and Godfrey 1998). Their central idea is that quality cannot be “tested in” by inspecting the final products. Instead, quality is achieved through process control—measuring and removing the variability of every process needed to create the products.
The analogy to service systems is straightforward. The quality of a service experience can not be guaranteed by the actions of the front stage employees. It is essential to train and evaluate the employees—back stage activities—to prepare them to be effective in the service encounter by eliminating unplanned variability in their actions. It is also essential that the front stage employees understand the rest of the service system so they can make appropriate decisions and align their efforts to make the best use of every other part of the service system.
5.2 Service encounters as information exchanges
A key tenet in the service system perspective is that it emphasizes what is common to person-to-person services, self-service, and services where the provider and consumer are both automated processes rather than focusing on their differences. Each of these types of service encounters requires a service provider and a service consumer, and each provider has an interface through which the service consumer interacts to request or co-produce the service. This level of abstraction highlights the information requirements, inputs and outputs for the service and the choreography with which the provider and consumer exchange information to initiate and deliver the service.
Treating services abstractly also makes it much easier to consider alternative service system designs. These might involve moving some services from the front stage to the back stage (or vice versa), replacing or augmenting a person-to-person service with self-service, or eliminating it completely through automation, substituting one service provider for another (e.g., through outsourcing) to improve quality or reduce cost, and so on.
5.3 Service intensity {and, or, vs} information
The concept of a service system and the abstract way in which it treats service encounters as information exchanges requires a corollary generalization in the concept of service intensity. In Sect. 1.2, we described service intensity in person-to-person service encounters for physical channels in terms of what the (human) service provider does. In Sect. 2.1, acknowledging that there was no human provider in self-service or virtual channels, we suggested that intensity had to be measured differently. The service system perspective now makes it clear that intensity might better be measured in terms of the amount of information exchanged or exploited in a service encounter.
-
If a human service provider asks a customer for information, how does the intensity compare when the customer provides the same information by filling out a self-service form?
-
If the customer is asked for information during a series of service encounters, how does this compare in intensity to asking for all the information in a single longer encounter?
-
Instead of asking the customer for information, suppose a service provider uses information it already has (from previous encounters or from other sources) to make it unnecessary to collect information from the customer?
Our current notions of service intensity are inadequate for answering these questions because we do not have good metrics for the cognitive and emotional demands imposed by different interaction designs, especially as those demands accrue over time and when interactions with a person are compared with automated self-service ones. Some guidance should come from emerging design philosophies that emphasize “lean consumption” (Womack and Jones 2005) and “consumability” (Kessler and Sweitzer 2008), which seek to eliminate all customer interactions and encounters that add no value. In any case, there is clearly a complementary and compensatory relationship between “encounter intensity” and “efficient use of information” that needs to be better understood.
6 Preliminary steps toward a methodology for service system design
Methods for designing traditional person-to-person services are well established and taught in numerous business schools in service marketing and operations courses (using popular texts like Davis and Heineke 2003 and Fitzsimmons and Fitzsimmons 2006). But since much of the service economy’s fastest growth is taking place in Internet-based self-service and Web-based computer-to-computer services, many have called for a new discipline of services design that extends the existing design methods to these new domains. This new discipline has been called Service Engineering (Bullinger et al. 2003), Service Science, Management and Engineering (SSME) (Maglio et al. 2006), and Service Systems Engineering (Tien and Berg 2003).
Our approach to developing methods for designing services directly follows from our analysis in this paper of the complementary roles of the front stage and back stage in a service system. Our overall goal is to create a unified design method so that front and back stage designers can appreciate each others’ concerns and constraints and then collaboratively address them. Our new methodology draws primarily from document engineering (Glushko and McGrath 2005) and user-centered design (Nielsen 1994; Ominsky et al. 2002) with some consideration for the new product development process, principles of service-oriented architecture (Pulier and Taylor 2006) and recent service design literature that takes a multi-channel service system perspective (e.g., Patricio et al. 2008).
Our initial approach was to take methodologies that focus on front stage or back stage design and interleave their respective design activities into a merged methodology. But this did not work because the methodologies start from very different design contexts. Consider that much user interface and experience design starts from a blank slate to encourage creativity in prototyping, while much back end design has an integration or interoperability focus where legacy models and technology constrain important design choices. These contrasts simply cannot be averaged away or compensated for by a combined methodology.
So instead of merging existing approaches, we have been seeking new design themes or principles that encourage front and back stage designers to view problems from the same or complementary perspectives rather than from antagonistic or competing ones. Our hope is that a more synthetic methodology will be able to span from end-to-end of service systems and be robust enough to accommodate person-to-person, self-service, and computer-to-computer components. And rather than espousing a normative “do this, then this, and then this” methodology, our approach will embrace different design contexts and explicitly deal with how to adapt design activities to them. For example, many of the traditional techniques for user interface design and usability testing that work for desktop software applications with long release cycles have had to become more lightweight and flexible to fit the “release early and often” philosophy for hosted software-as-a-service applications (Lindholm 2007) and “agile” software development methods (Beyer et al. 2004).
We cannot present the complete methodology in this short paper, but we will briefly sketch the core ideas, especially those that most explicitly concern the interactions and tradeoffs between front and back stage design. More detail can be found in the syllabus and lecture notes for an “Information System and Service Design” course taught for the first time in the Fall semester 2008 at the University of California, Berkeley (Glushko 2008).
6.1 Merge the mindsets with multidisciplinary design teams
The design of person-to-person services was traditionally carried out in the marketing or customer service units of firms by designers with front stage perspectives. Now that technology and information systems have become essential foundations for many services, information systems personnel are often members of service design teams. We think it is essential to create multidisciplinary design teams that explicitly include designers with front and back stage biases but who are motivated to teach and learn from each other. That is because many of the most important design issues in service systems involve tradeoffs or potential conflicts between front stage and back stage goals, as we described in Sect. 4.3. This mandate to “design from both sides of the screen” (Isaacs and Walendowski 2001) is easy to express but challenging to do well, and we note that product managers are often essential arbitrators between front and back stage advocates.
A multidisciplinary design team can identify and close the gaps of understanding in both the front-stage’s model of the back stage and the back stage’s model of the consumer experience. This will eliminate or substantially reduce their conflicts and misconceptions.
A multidisciplinary design team will perform more complete analyses and make better decisions about service intensity and where to set the line of visibility between the front and back stages. It will also be better able to determine the mixture of person-to-person and self-service components in the service system. Collaborative decision making is especially important because service designers are only beginning to understand the intensity/quality tradeoffs in the transformation of services from physical to virtual channels (Sousa and Voss 2006). Different customer types have different preferences and presumably different tradeoff functions (Frei 2006).
Designers with a back stage mindset might have a bias to reduce the variation in service delivery by replacing person-to-person services with self-service wherever it is technically possible. Front stage designers will remind them that customers do not always prefer self-service, and that it may be necessary to maintain multichannel alternatives in the service system. And rather than letting designs reflect the outcome of a debate between front and back stage proposals, some firms have introduced a new role of “customer experience manager” to ensure that the often narrow perspectives of front and back stage designers are broadened and harmonized for the benefit of the customer (Meyer and Schwager 2007).
6.2 Create information flow and process models that connect the front and back stages
The related themes that service quality is a emergent property of an entire service system (Sect. 5.1) and that service encounters can be viewed as information exchanges (Sect. 5.2) come together to suggest an important design activity of creating models that connect the front and back stages.
This idea is presented in an elegant and practical way in a paper titled “Staple Yourself to an Order” (Shapiro et al. 1992):
“…every customer’s experience is determined by a company’s order management cycle (OMC): the ten steps, from planning to post sales service, that define a company’s business system. The order management cycle offers managers the opportunity to look at their company through a customer’s eyes, to see and experience transactions the way a customer does.”“The moment of truth occurs at every step of the OMC, and every employee in the company who affects the OMC is the equivalent of a frontline worker.”
Creating a model of the how information flows between the steps in a service system is essential in preventing problems in the “cracks” between the organizations carrying them out. Employees in different business units within the firm might otherwise have different priorities and perspectives about what is important to the customer, and an end-to-end model that they all share can ensure that they act in the customer’s interests.
A related benefit of information flow models that track the actual or virtual movement and transformation of “business artifacts” is that they highlight the evidence that most directly demonstrates how the business operates (Nigam and Caswell 2003). For example, the key business artifact for FedEX is the “air bill,” and the entire business focuses on the processes that manage air bills from creation to completion. During its lifetime the air bill appears in both front and back stage contexts but its end-to-end flow transcends that distinction.
Queuing theory provides a framework for describing service systems where people wait to be served (e.g., by bank tellers, telephone call centers, repairmen, etc.) in which the parameters of these models—arrival rates, waiting time, number of service providers, etc.—explicitly represent the quality of the “customer service” experience using both back stage and front stage aspects (Gans et al. 2003). The formal rigor of queuing models has created a rich body of knowledge about different queue structures and who-gets-served-when disciplines that enable designers to maintain a desired quality of service in the service system.
6.3 Create user models of appropriate detail using both front and back stage content
Front-end designers, back-end developers, marketing, customer service, and many other participants in a service system employ some set of qualitative or quantitative techniques to model the customer or user of the service. Each of these models of the user serves to shape the design and delivery of the activities or artifacts created by each participant. Unfortunately, each of these models has some limitations of its own. Even worse, collectively the models can be inconsistent and incompatible.
For example, user interface and user experience designers often conduct interviews and then create one or more “personas,” fictional characters that represent typical customers or user groups for a product or service (Cooper 1999). Personas are defined with rich detail: names, personalities, portraits, families, hobbies and other attributes, and most importantly, they have explicit goals, as illustrated by this example, a persona named “Kathleen” developed by designers of rear-seat entertainment systems (Brechin 2002):
Kathleen is 33 year old and lives in Seattle. She’s a stay-at-home mom with two children: Katie, 7, and Andrew, 4. She drives the kids to school (usually carpooling with 2–3 other kids) in her Volvo wagon. Kathleen is thinking about buying the Sony rear-seat entertainment system she saw last weekend at Best Buy to keep the children occupied on the upcoming trip to see family in Canada.…
Personas ensure agreement about who the customer or user is when designers refer to them to discuss design ideas or decisions, and their concreteness encourages designers to focus on typical rather than edge cases. However, some critics of personas argue that the amount of detail in a set of personas makes them less representative and comprehensive than a set of customer segments defined more abstractly (Chapman et al. 2008). In addition, to the extent that persona details are based on a designer’s intuition or filled in using cultural stereotypes rather than on hard data gleaned from surveys or interviews, it is not clear why personas would lead to better design decisions.
In contrast, the use of “hard data” about people characterizes the approach by marketing or customer support organizations to segment a customer base into different groups using demographic (geography, age, gender, income, education, and occupation) and psychographic variables (personality, lifestyle, values and attitudes). For example, market survey research about rear-seat entertainment systems might yield information like this:
…most respondents believed it was a “lifestyle” purchase for parents trying to entertain or distract their kids while driving. Most felt that the system was appropriate for children between the ages of 4–15 years, as children needed to be old enough to use headsets as well as some form of remote control (Brechin 2002).
Data-driven user models created from research on customer choices and preferences about actual or possible products and services can shape design decisions about features and their priorities (Verma et al. 2008). But this begs the question of how potential design features are identified. And precisely because these sorts of data-driven models are designed to predict buying patterns and user behaviors within the “bins” defined by the attributes of the user and offering models, they can be brittle if the design context changes because they lack the overarching intent or goals that are intrinsic to personas.
A third kind of user model is typically created by back stage designers when they define the desired functionality of a service or system. These models specify “use cases” in which “actors” invoke and respond to functions or services (Cockburn 2000). The model of the “actor” in use cases is intentionally a minimal one, often represented by a “stick figure” human in design diagrams whose only attributes might be functional or organizational roles. For example, the use cases for a rear-seat entertainment system might include:
Driver/parent: Turn on system; turn off system; set system controls; adjust volumeBack seat passenger/child: Change volume; change channel
This level of detail contrasts sharply with the much richer user models in personas and customer segments, but is intentional because it enables the back stage designer to treat human and computational actors in similar ways and even view them as substitutes for each other. For example, it might not matter if a “translation” service is carried out by a human or a machine translator, and the minimal model of the actors involved encourages the hiding of the implementation. On the other hand, these minimal user models are completely incapable of accounting for different capabilities and preferences between types of users and informing design decisions meant to accommodate them.
The various strengths and weaknesses of these approaches to creating models of the user makes it clear why all of them are employed in the design of service systems. But they should not be used in isolation from each other; we propose to interconnect these different user models so that data gathered from different design perspectives is shared by all of them. For example, personas should be based where possible on the hard data explicitly collected by marketing or the implicit data collected in web search logs or transaction histories. Similarly, qualitative insights about user intentions that are discovered in interviews or ethnographic observation and embodied in personas can suggest attributes or choices to be tested by marketing. These efforts should encourage the development of a library of user model or “persona patterns” that can be implemented in objects or business rules. Representing user models in computable formats will enable and incent back end designers to employ more robust “actors” when it is necessary.
6.4 Implement “model-based user interfaces”
Creating information and process models is a significant investment in capturing context-specific (or application-specific) requirements in a technology-neutral and robust way. It comes naturally to back stage designers to explicitly use models represented as UML class or sequence diagrams, database schemas, or XML schemas as specifications for generating code or configuring an application (e.g., Carlson 2001; Bean 2003; Daum 2003).
In contrast, methods used by front stage designers to design and implement user interfaces are dominated by iterative and heuristic techniques. To many back stage designers, these non-deterministic methods seem inefficient and unnecessary. Many “back stagers” have attempted to apply model-based implementation techniques to user interfaces, especially for information-intensive transactional applications where the essence of the user’s task is to provide information that conforms to a model of an order or other standard business document type (Garvey and French 2003).
Model-based implementation is not appropriate for all user interfaces, but seems especially promising in some design contexts. One is the typical “forms and workflow” situation in which paper documents that carry out some organizational or commercial process are handled by numerous people or applications. When these processes are automated (and usually re-designed during this transition), it is common to use application frameworks that automatically handle the basic create-read-update-delete operations that are intrinsic to them. These operations are fundamental in data manipulation languages, database systems, and in browser-based technologies like XForms (Dubinko 2003) and Ruby on Rails (Ediger 2008). The former generates user interface forms based on XML-based data models, while the latter translates a data model into an initial set of HTML forms and controllers (a “scaffold”) that can be extended by the developer or web designer to allow for more sophisticated design interaction than just enabled by forms alone.
A second design context in which model-based implementation of the front stage is very promising is for multichannel services that are offered across a range of contexts or devices. Model-based techniques would make it possible to generate a consistent set of self-service user interfaces for web browsers, cell phones, and voice systems with little of the “hand crafting” usually employed by front stage designers (Florins and Vanderdonckt 2004). An analogous design problem that can be addressed with model-based techniques is adapting content authored for one channel to another with different bandwidth, display size and resolution, etc. (Zhong 2007).
6.5 Exploit back stage and context information to improve the front stage experience
In Sect. 3.1, we explained how information about prior service encounters from the back stage of the hotel check-in service system was used to improve the immediate experience for a specific customer. In those examples, however, the information about the customer’s preferences and goals was explicitly recorded by hotel employees who learned it in face-to-face encounters with the customer.
In contrast, many consumer appliance and entertainment devices, self-service and other technology-driven applications are capable of completely automatic capture of customer interaction history and behavior. Manufacturers have long exploited this kind of information to design new and improved products, and service providers like airlines, hotel chains, and car rentals use it to offer enhanced services to their most loyal customers. In addition, data mining, business intelligence, and recommendation system techniques can extract behavior or preference patterns from transaction histories to tailor and improve services. For example, Wells Fargo’s ATMs display “My ATM Shortcuts” so that users can bypass function menus and invoke their most frequent transactions with a single selection.
Data-driven user models can be directly used in back stage service configurators or generators that propose products and services to customers in which there is an explicit mapping between attributes of the user model and the model of the offering (Tihonen et al. 2007). This “microsegmentation” of a customer base is most effective in information-intensive businesses like insurance and banking where extensive historical data is readily available to be analyzed, risks can be precisely quantified, and the offering (contract terms) can be precisely personalized (Taylor and Raden 2007).
In addition to using historical information collected about a specific customer or aggregated across a customer segment, it is increasingly possible for systems, especially those implemented on mobile devices like cell phones, to use contextual information about time, location, and the presence of other individuals to personalize a front stage experience (Naaman et al. 2004; Rao and Minakakis 2003). The limiting factor in the use of historical and contextual information may well be privacy concerns. Moed (2007) argues that it should be up to users themselves to determine which analyses and applications of their interaction histories are worthwhile enough to permit them.
6.6 Exploit design patterns that satisfy joint front and back stage goals
In Sect. 4, we pointed out that the goals and quality criteria for front and back stage designers are sometimes in conflict, which is why tradeoffs are often required. Fortunately, there is an important set of design patterns for service systems whose purpose is to satisfy apparently incompatible front stage and back stage goals.
Many techniques for managing demand are designed to influence or shift customer requests for service from periods when the service provider’s capacity is exceeded to periods of underutilized capacity. This allows the provider to maintain a satisfactory quality of service without the cost of additional capacity. Price discounts for off-peak periods and bundling a combination of services at a reduced rate are familiar examples of demand management techniques.
7 Summary
A service outcome is almost never the result of a single encounter between a service provider and service consumer. Instead, it emerges from the service system of back and front stage services that establish the context and satisfy the preconditions for the final service encounter to take place. There may be a “moment of truth” in which the quality of the service experience becomes apparent to the service consumer, but that quality was enabled or constrained to a greater or lesser extent by the entire service system.
The design conflicts and tradeoffs between front and back designers are lessened by a service system perspective. Front stage service providers need capabilities for capturing information about front stage preferences, contexts, and events. This and other back stage information can then be exploited by the front stage to enhance the service experience.
Open Access
This article is distributed under the terms of the Creative Commons Attribution Noncommercial License which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
Open AccessThis is an open access article distributed under the terms of the Creative Commons Attribution Noncommercial License (https://creativecommons.org/licenses/by-nc/2.0), which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.