Involving users in the development of a modeling language for customer journeys

Abstract

Although numerous methods for handling the technical aspects of developing domain-specific modeling languages (DSMLs) have been formalized, user needs and usability aspects are often addressed late in the development process and in an ad hoc manner. To this concern, this paper presents the development of the customer journey modeling language (CJML), a DSML for modeling service processes from the end-user’s perspective. Because CJML targets a wide and heterogeneous group of users, its usability can be challenging to plan and assess. This paper describes how an industry-relevant DSML was systematically improved by using a variety of user-centered design techniques in close collaboration with the target group, whose feedback was used to refine and evolve the syntax and semantics of CJML. We also suggest how a service-providing organization may benefit from adopting CJML as a unifying language for documentation purposes, compliance analysis, and service innovation. Finally, we distill what we learned into general lessons and methodological guidelines.

1 Introduction

Domain-specific languages (DSLs) are languages tailored to a specific application domain [1]. The main purpose of DSLs is to bridge the gap between the Problem Domain (crucial concepts, domain knowledge, techniques, and paradigms) and the Solution Domain (technical space, middleware, platforms, and programming languages) [2]. Their advantage over general-purpose languages is that they can offer substantial gains in expressiveness and ease of use in their domains of application [1]. DSLs for modeling, i.e., domain-specific modeling languages (DSMLs), promise to offer easy communication by using well-known and accepted domain objects with appropriate notation and precision that allow for further processing of the domain models to generate code, data models, and so on [3, 4]. Even though DSMLs are concerned with specific domains, they can address a wide audience, with some users being domain experts and others being stakeholders who do not necessarily have a technical background [5]. More specifically, in the case of services, DSMLs reach specific domains, such as health, governmental, and business services. However, the users modeling these services (e.g., health specialists, governmental employees, and marketing strategists) can form a heterogeneous target group with various technical and knowledge backgrounds. Therefore, given that the user group is diverse in practice, the design of a usable DSML is a challenging task [6, 7].

Usability is an essential feature of a DSL or a DSML, since increased usability can have an important impact on the productivity of the language’s users [2]. As such, designing DSMLs may benefit from techniques used in the Human–Computer Interaction (HCI) field, which has a long tradition of using knowledge of users’ needs and behaviors to support the design and development of a system, product, or service to ultimately achieve high usability. Along those lines, user-centered design (UCD) is a standardized approach in which the needs of those using the system are given extensive attention [8]. Here, usability is defined as the extent to which a product or service can be used by specific users to achieve specific goals in a specific context of use with effectiveness, efficiency, and satisfaction. This implies that before seeking a meaningful measure of usability, one must identify who the users are, what they want to do, and in what context the product will be used [9, 10]. Previous research on DSMLs [4, 11,12,13] has suggested that it would be beneficial to promote more active participation by the target users in the development process of DSMLs, so as to achieve a higher level of usability for the final product, thus facilitating the language’s inclusive and unobstructed use.

The current paper describes the development of a DSML that targets a broad and heterogeneous user group—customer journey modeling language (CJML)—and the lessons learned from that process. CJML can be used for modeling and visualizing end-user journeys. CJML addresses the chain of detailed interactions between a human user and service provider, regardless of whether the human has the role of customer, user, patient, or citizen. The target group of the modeling language can be divided into two main categories: private and public service providers on the one hand and researchers and consultants on the other (Fig. 1). Typical target roles in a service-providing organization are business developers, service or product owners, service designers, and system architects. Their main function spans several phases of a service’s life cycle: design and development, operation and maintenance, quality and improvement, and research and innovation.

Fig. 1

The target group of CJML (inside the box) and the service providers’ end users (top) to which the term journey refers

Based on our work with CJML, we present the lessons learned from applying UCD principles and involving the target group in the development process. We hope that this may inspire researchers and practitioners in the DSML field and those who deal with broad target user groups to plan their design processes in a way that will lead to a high level of usability for their final DSML products.

1.1 Background

Service provisioning has increasingly expanded over the past few decades, and today, our society is dominated by services. To increase profits and competitive advantage, manufacturers have transformed their value propositions through servitization by adding services to products or presenting products as a part of a service offering [14]. More than 20 academic disciplines have investigated service systems from various angles [15], and service science has emerged as a novel transdiscipline that can help in advancing service innovation.

Recent technological advancements have transformed our society’s services into a system of systems, enabling networks of users and service providers to collaborate while creating new value [16]. The traditional service context, wherein a customer interacts with one service provider in isolation, has evolved into more complex constellations of companies and end users, where value is exchanged in a service delivery network [17], as shown in Fig. 2.

Fig. 2

The service landscape has changed from a dyadic relationship (left) to more complex constellations of companies and end users (middle and right)

Private and public service providers are under pressure to digitize their service offerings because of the substantial opportunities for efficiency gains and flexibility. However, digital services continue to frustrate and burden humans in the private and professional contexts [18, 19].

Traditional approaches for assessing service quality and customer satisfaction have focused on single momentary interactions. More recently, the awareness that this may mask the underlying issues experienced by customers or users over time has increased [20]. Accordingly, there is a need to consider the end-to-end process instead of single momentary interactions. It is argued that a profound assessment of services requires a paradigm shift away from single moments and toward customer journeys [21].

The design and operation of services involve heterogeneous groups of employees residing in different organizational silos, and often even external partners. The ability to deliver consistent service experiences requires a cross-functional approach and the structures and processes to transcend organizational boundaries. This becomes challenging as service providers increasingly outsource elements of their service delivery [17].

Service design aims to create quality services by engaging interdisciplinary teams and stakeholders of various backgrounds with a multitude of tools throughout the design process [22]. Customer journey mapping is one of the most frequently used methods within service design [23], and the term “customer journey” is generally used as a metaphor to examine a service system from the customer’s perspective. Traditionally, the end-user has had the role of the customer, because the interest in customer journeys emerged from the field of service marketing. As the journey concept has diffused into new non-commercial service contexts, practitioners and academics have expanded the role of the end-user to users, consumers, patients, and citizens.

Journey maps are diagrams or visualizations depicting the customer’s steps or touchpoints chronologically along a horizontal axis. The granularity and abstraction level of the steps considerably varies from distinct events (e.g., receiving an e-mail) to the phases of a life cycle (e.g., airport check-in). Although the horizontal axis always reflects time, the vertical axis is highly variable and may represent communication channels, emotions, opportunities, or a combination of these elements [24].

The customer journey construct certainly represents a human perspective throughout an end-to-end service process. Furthermore, it encompasses the less tangible construct of customer experience. The definition, interpretation, and scope of customer experience are highly debated among academics and practitioners, especially in terms of its measurability [25]. Customer experience is considered a multidimensional construct focusing on cognitive, emotional, and behavioral responses [26]. Furthermore, human experience has a situation-specific nature and is an inherently subjective entity that varies over time; here, it depends on the user’s internal state and the context [27]. Thus, emotions are both an input and an output of an experience, and behavioral psychology research emphasizes numerous factors that influence an experience over time: sequence effects, duration effects, shaping attributions, and perceived control [28].

1.2 Purpose and research questions

Customer journey has become a prominent construct and a key strategic tool for service providers while uncovering problems in existing services, developing new services, and understanding complex behaviors and experiences [29]. While the journey literature has rapidly grown over the last decade, a common understanding of the basic journey’s constituents is lacking and the associated methods remain incoherent [24, 29, 30]. Consequently, a plethora of nonstandard descriptions and formats have evolved, [31] and the validity of methods beyond anecdotal evidence has been questioned [32]. Given the prevalence of customer journey methods among practitioners, companies, and academics, there has been surprisingly little focus on formalism, modeling, and theory building, as will be further elaborated in Sect. 7.

CJML is a process language that contrasts general-purpose modeling languages (GPMLs) such as Unified Modeling Language (UML) [33], and Business Process Model and Notation (BPMN) [34], which are built from a software- and business-centric perspective, respectively. CJML is inherently designed from the perspective of a human end-user, often referred to as the “outside-in” perspective. CJML is further compared with GPMLs in Sect. 7.3.

Hence, the main purpose of our work has been to design a DSML for modeling service processes from an end-user’s viewpoint while also ensuring that this DSML does not require a technical background. The main challenges are as follows:

• The heterogeneous target group and the wide spectrum of needs and potential purposes.

• The fragmented knowledge base surrounding the core constructs (customer journey and customer experience).

• The presumed lack of modeling experience in the target group.

CJML has been developed in close collaboration with industry partners through multiple research and innovation projects in the period of 2012–2020. In all, 11 public and private service providers, four research institutions, and two consultancies have been actively involved throughout the development process. Our main goal has been to develop a modeling language for customer journeys aiming at a heterogeneous target group, guided by UCD principles. The challenge has been to make the language simple enough to accommodate inexperienced modelers with varying domain knowledge while maintaining an expressive visual language that can capture the intended semantics of each target user’s domain. Case studies involving target users have been the main driver for the development of CJML, as discussed in detail in Sect. 2. In this paper, we present four case studies grounded in a specific industrial context and with accompanying research questions. In this setting, we address an overall research question (RQ) and four fine-grained research questions corresponding to each case study:

• Overall RQ: What lessons can be learned from the involvement of target users in the development of CJML?

• RQ1: How can we develop a precise vocabulary based on terms that are used in a broad sense by the target users?

• RQ2: How can we extend the syntax of CJML to accommodate planned journeys containing uncertainties?

• RQ3: How can we extend CJML to accommodate a more complex multi-actor service setting?

• RQ4: Can the target users produce accurate models using the journey network diagram?

Section 5 addresses the overall research question of the general lessons that we have derived from user involvement. More specifically, RQ1 seeks to identify the appropriate terms and evaluate if target users can apply the terminology correctly (Sect. 4.1). RQ2 seeks to explore whether a special notation for unpredictability in planned journeys is beneficial for the target users (Sect. 4.2). Grounded on shortcomings of the basic journey diagram, RQ3 seeks to explore the effectiveness of a new diagram type (Sect. 4.3). RQ4 is addressed by conducting a systematic evaluation with target users (Sect. 4.4).

Up to this point, CJML has been a modeling language for producing conceptual journey models. The metamodel presented here is used for documentation purposes only. The concrete syntax and the general use of CJML are available through specification documents, accompanied by basic diagramming tools like design templates and stencils. Work is in progress to formalize CJML, as further described in Sect. 8.

Table 1 Adherence to design-science research guidelines

1.3 Contribution

This paper is an extended version of a MODELS 2021 conference paper that was published in the practice and innovation track [35]. In summary, this article enhances its precursor in the following ways:

• The first major change concerns the description of CJML. Section 3 presents a comprehensive overview of the abstract syntax of CJML. The visual notation is also extensively described, presenting the two diagram types of CJML: customer journey diagram and journey network diagram. A running example of a service process is used to demonstrate how it translates into the main constructs of CJML.

• The second change is the addition of unpublished results from a systematic evaluation of the diagram type for journey networks (Sect. 4.4). With this addition, this paper describes four detailed studies of user involvement (Sect. 4).

• The third change is a discussion of limitations and threats to validity (Sect. 6).

• Finally, the fourth change is the addition of related work on the methods, frameworks and modeling efforts specifically targeting customer journeys, and comparison of CJML with other modeling languages (Sect. 7).

1.4 Overview

The next section describes the development approach and the UCD activities. Section 3 provides a detailed description of CJML, its terminology, and visual notations. Section 4 describes the four cases of user involvement and how this insight has informed the design and refinement of CJML. Section 5 discusses the lessons learned from user involvement. Section 6 discusses the limitations and weaknesses of CJML. Section 7 provides related work on the modeling of customer journeys. Finally, Sect. 8 concludes the paper and proposes the scope for future work.

2 Development approach and method

The main challenge in developing CJML has been the broad and heterogeneous target group and their corresponding wide spectrum of needs and purposes in the multifaceted practices of service innovation, operation, and management. Accordingly, a wide range of methods has been used to clarify the scope, identify user requirements, and evaluate and revise the language.

In general, there is little guidance available for the development of DSML [36]. Our main goal of developing a modeling language for customer journeys can be considered a design-science process. Design science is a problem-solving process grounded in the need for a formally represented artifact that is iteratively evaluated to demonstrate its usefulness [37]. In this section, we describe the development approach of CJML in light of the seven guiding principles of design-science research (DSR), see Table 1 for a summary. As described in Sect. 1.2, acknowledging the specific problem domain and the purposeful artifact (the need for formalism and CJML as the intended solution) constitutes the first guideline of Design Science Research (DSR).

UCD is the prevailing trend in the development of products, services, and systems. An ISO standard [8] provides guidelines to ensure that the needs, desires, and challenges of the users are considered. This standard emphasizes that the term “user” encompasses all stakeholders involved in the development, operation or support of the artifact. In general, UCD must be adapted to the specific context of use and the environment in which the system will be used. Thus, all relevant users and stakeholder groups must be identified. Iterative evaluation of the design solutions is an essential principle of UCD to ensure incremental improvements until the solution can be considered usable.

CJML has been released in a total of 11 versions that are based on minor and major revisions from 2012 until today. The initial designs of CJML were built on experiences from the past and current industry collaborations concerning service innovation and customer experiences. Literature studies have also supported the initial design of CJML. In keeping with the UCD principles, we conducted a survey [38], and an early requirement analysis through interviews with the target users and workshops with cross-functional teams [39]. Documentation and evaluation of an early version of CJML can be found in [40]. Further development was carried out in an iterative manner through repeated UCD activities.

Direct collaboration and frequent interactions with the target users from the service industry form the basis for identifying specific user requirements for the DSML and for providing nuances to use context. Case studies with the industry partners were the main driver of each development cycle. The case study methodology involves the examination of phenomena (service offerings) and experiences in their natural context using multiple data sources, and there is an emphasis on qualitative data and analysis [41]. Some cases were grounded in known problems and a need for improvement (journey redesign). Other cases were grounded in the need to identify and document a complex service process (journey discovery), which, in turn, uncovered unknown problems or user barriers (journey conformance). A few cases also involved the development of new service processes, with CJML as one of the innovation tools (service innovation). To plan the case study, we arranged workshops with the cross-functional teams involved in the service delivery process to set the scope of the analysis and plan the data collection process. In most cases, the researcher was responsible for data collection and analysis of service processes and customer journeys. In some cases, we also collected data from end users of the services in focus. Common for all the case studies was the problem-solving focus, the close collaboration between academics and practitioners, and the continuous development and evaluation of the DSML through action research [42].

In addition to the evaluations conducted as a part of the case studies, a comprehensive evaluation was conducted with external target users to test the general applicability of the various elements of CJML [43]. The goal was to assess the degree to which the new users of CJML found the conceptual basis comprehensible, whether they could model service processes with a fair level of precision, and to assess the usability and perceived usefulness of CJML in general. As a consequence, we adjusted the conceptual foundation of CJML (see Sect. 4.1). A second comprehensive evaluation was conducted to focus on more complex service constellations and the applicability of CJML in this respect (see Sect. 4.4).

The generic parts of CJML have been publicly available online throughout the development process in the form of specifications, guidelines, case study reports, and graphical stencils for making diagrams [44]. This has made it possible for us to receive continuous feedback from CJML users, which has proved valuable. The customer journey heatmap is one example of an idea developed in collaboration with CJML external users [45].

3 The customer journey modeling language

In this section, we describe the overall modeling approach and the requirements for CJML (Sect. 3.1). When presenting the abstract and concrete syntax of CJML, we introduce an example journey that will be used throughout the section. Section 3.2 presents the fundamental constructs and their interrelations. Finally, Sect. 3.3 presents the visual notations used in CJML.

3.1 Modeling approach and requirements

The fundamental goal of CJML is to enable a detailed and precise specification of a service delivery process from the perspective of the end-user. The airline company SAS was a pioneer in taking an outside-in perspective on their customers’ travel experiences. They researched the customers’ processes and associated “moments of truth” in a systematic manner. A rudimentary visual notation for the precursor of customer journeys can be found in [46] in the form of interconnected circles representing touchpoints. In general, customer journeys and experiences are conceptualized and visualized differently [24].

The Gap Model of service delivery [47] captures the perspectives of both the service provider and customers and has been influential in service research. It decomposes service delivery into sub-units, which indicate performance gaps in service quality. This model has no time dimension, and customers’ expectations form the basis of the model. User experience research has revealed that experiences are highly subjective; they depend on the context in which the service is encountered, and the experience may change over time [27]. Furthermore, the measurability of human experiences has been critically questioned, representing a challenging and controversial research area [48]. We argue that it is more instructive to base models on the instrumental, measurable attributes of a service process, rather than on customer experience or expectation.

Fig. 3

The simplified CJML metamodel indicating system granularity from service processes (most abstract) to touchpoints (CJML’s atom). The core concepts of CJML are highlighted and will be expanded in Figs. 4–6

A distinction between the planned, hypothetical state of a service and its executional state was introduced in a seminal article from the service management literature in 1982 [49]. The two states were originally referred to as the potential and kinetic states of a service, respectively, but received surprisingly little attention in the literature. A service experience should be analyzed on the level of individual experiences because deviations frequently occur during the execution of the service process [50]. To comply with this requirement, CJML distinguishes between the hypothetical, planned journey and the dynamic, actual journey that unfolds during the execution of a service. In response to the inherent challenge of introducing customer experience on a hypothetical level on behalf of the prospective customers, CJML considers customer experience only in the actual journeys and based on the customers’ self-reported feedback. Thus, the fundamental requirements of CJML can be summarized as follows:

• CJML shall distinguish the planned, hypothetical state of a service process from its executional state when an individual end-user is involved.

• CJML shall be based on the objective, observable properties of a service process to enhance its reliability.

• CJML shall conceptualize customer experiences in the executional state as an individual and time-varying attribute based on self-reported data.

3.2 CJML abstract syntax

In this section, we describe the core concepts of CJML and their interrelations. From here onwards, the term customer will be replaced with end-user since customers are a sub-category of an end-user based on CJML terminology (refer to Fig. 1). A running example of an online bookstore is used throughout this section to illustrate how a service process translates into the basic terminology of CJML.

3.2.1 Overview

The seminal research manifesto for service science describes the emergence of services as a field of study and the vast implications of the service economy, but also the conceptual confusion associated with the term service [15]. The term “services” (plural) is often used interchangeably with “service processes” [51], which simply refers to how a service is provided or delivered to the end-user. CJML has a process nature and is ultimately connected to service processes and the detailed chain of events of the service delivery network, as seen from the perspective of the end-user(s). Figure 3 shows a simplified metamodel of CJML and how the CJML concepts are associated with a service process following the UML Class Diagram notation.

The core concepts in CJML include the CustomerJourney, Touchpoint, and Actor. These concepts are highlighted in Fig. 3. The figure depicts the granularity of the system from the most abstract (i.e., ServiceProcess) to the lowest level (i.e., Touchpoint). Here, we focus on describing system granularity. In the next subsections, we will expand on the core concepts, which will be shown in Figs. 4–6.

For a given service process, such as e-commerce in the bookstore example, often, a group of closely related customer journeys associated with the same end-user goal exists. The JourneyGroup represents all possible paths that lead an end-user to achieve a goal (e.g., online shopping for books). Two factors are particularly relevant here. First, technological innovations have increased the number of alternative ways in which end users interact with service providers. Second, service providers are increasingly relying on outsourcing elements of the service delivery process [17]. The multi-channel nature of the digital service offerings and the fragmentation of the service delivery network may result in extensive journey groups. In a case study on a utility company, we identified more than six hundred unique customer journeys associated with onboarding new end users. A journey group with multiple journeys is better expressed using Decision, which merges the customer journeys and introduces multiple decision paths. In the bookstore example, various options for payment and delivery of books result in a journey group, which will be discussed further below.

Fig. 4

The metamodel expanding on the customer journey class

The CustomerJourney class has two specific subclasses that represent the two states of a journey: PlannedJourney (hypothetical) and ActualJourney (executive). An actual journey happening in the real world may not comply with the planned journey, which is expressed through the journey compliance attribute. A customer journey comprises a sequence of steps represented by the Touchpoint class, which is a subclass of the CustomerJourneyElement. A journey comprises a minimum of two touchpoints that are declared through the multiplicity element. In addition, a single journey can split branches to express events happening in parallel, expressed through the Concurrency class. Finally, the customer journey may consist of journey phases or stages, expressed through the JourneyPhase class if available. Customer journey elements and journey operators (i.e., concurrency and decision) may belong to a journey phase, if available.

The CustomerJourney class is associated with the Actors class. Actors are human and non-human entities involved in a journey. The journey has (at least) one main actor, which is an end-user and at least one service provider. As mentioned in Sect. 1.1, service delivery often relies on more complex constellations of actors. Nevertheless, only actors having direct interactions with the main actor form a part of the Actor class.

Finally, a touchpoint is a customer-facing step of the journey and the system’s “atom.” Touchpoints are expressed in the Touchpoint class, which has two specific subclasses representing communicative events (CommunicationPoint) and non-communicative events (Action).

In the following subsections, we elaborate on CustomerJourney, Actor, and Touchpoint classes. The full documentation of CJML can be found online [44]. The metamodel of CJML has been revised on several occasions. The version at the time of writing can be found online.¹ The user-centered activities informing some of these revisions are described in Sect. 4.1.

Fig. 5

The metamodel expanding on the actor class

3.2.2 Customer journey

A customer journey is defined as a sequence of touchpoints involved for an end-user to achieve a specific goal or desired outcome in the context of a service process. In the customer journey, the end-user and at least another service provider are modeled. Figure 4 shows the CustomerJourney class and its subclasses. The planned journey reflects how the service process is implemented by the service provider(s) regardless of whether it was deliberately designed or merely resulted from an ad hoc development process. In contrast, the actual journey is an “execution” of the planned journey because it unfolds for an individual end-user over time.

The journey attributes—journeyID, journeyTitle, journeyShortSummary, and journeyLongSummary—are self-explanatory and inherited by both planned and actual journeys. Actual journeys have a journeyStatus attribute, which can be ongoing, completed, or aborted. Actual journeys have an endUserExperience attribute, a phenomenon that is subjective and context-dependent and may change over time. Thus, CJML only acknowledges an end-user’s self-reported experience and their experience rating (endUserExperienceRating) using a 5-point Likert scale (larger = better experience). This attribute concerns the overall journey experience.

The JourneyOperator class contains exclusive OR (XOR) and AND operators, which are common features of general languages and they are also part of CJML. Using Concurrency, a customer journey can have concurrent branches (AND operator), which express journey elements that occur in parallel. In contrast, Decision introduces XOR logic paths used to split branches, allowing for different possible path choices for an end-user or a service provider. Using the XOR logic, an end-user or service provider may follow only one of the branches that are introduced by decision points. This feature is on the group level and may merge multiple single journeys into a clustered group. A Decision can have a condition attribute that textually describes the condition needed, and a decisionMaker may be explicitly defined, which can be either the end-user or the service provider.

Several studies show that customer journeys can be broken down into stages or phases (e.g., [52,53,54]), which helps service owners understand and improve their services. The proposed stages are mostly fixed, and end with a purchase being made. In the CJML case, phases do not necessarily end in purchasing since journeys are not limited to purchasing customers. Examples include employee onboarding journeys and citizen vaccination journeys. CJML’s JourneyPhase class does not have predefined values, and different phases can be customized through the phaseName and phaseDescription attributes. Customer Journey elements such as touchpoints and journey operators (concurrency and decision points) may belong to a journey phase instance if present.

If the planned journey exists, actual journeys may refer to it and check for compliance. This attribute is crucial for the service owners to understand the parts of their service that require improvements. From experience, actual journeys often do not comply with the planned journey and contain deviations [32]. Here, the deviation is considered at the journey level. Mainly, the JourneyCompliance attribute is used to check whether the touchpoints in an actual journey are completed as planned (contentCompliance) and in the correct order (sequenceCompliance).

Notably, a deviation from the planned journey is not inherently a negative experience for the customer. Journey compliance is a complex topic, as it encompasses both instrumental and experiential dimensions, as further elaborated in [32]. Separately modeling the real-world (actual) journey against the theoretical (planned) journey, a method known as Customer Journey Analysis [32], has proven to be effective in uncovering unfortunate experiences and improving the service quality.

In the bookstore example, there are two delivery options: home delivery or pick-up at the store. Thus, this example consists of two planned journeys that make up the journey group. An actual journey will only follow one of the two delivery options. The actual journey is initiated when the end-user places an order, and the journey status will be in progress until the package is delivered.

Fig. 6

The metamodel expanding on the touchpoint class

3.2.3 Actor

An actor is formalized as any person or entity (organization, company, etc.) involved in service delivery. An end-user (traditionally a customer) and at least a service provider are required in a customer journey. It is also possible to have other constellations of actors, such as multiple end users and service providers (see Fig. 2).

Figure 5 shows the Actor class and its subclasses, which share the attributes actorID, actorName, actorDescription, and isVirtual. The first three attributes are self-explanatory, while IsVirtual is a Boolean-type attribute that checks if the Actor has a virtual (e.g., a mobile app or another part of the service system) or human nature.

The Actor class has three subtypes: EndUser, ServiceProvider, and External classes. In a traditional context, the end-user is a customer. However, the journey concept is often used in non-commercial contexts, where the end-user may be a citizen or a patient. CJML extends the traditional customer setting and includes users, patients, citizens, and employees, which are endUserTypes. Multiple service providers may exist for a given service process. Each service providers may be described by the companyName and department attributes. Both the end-user and the service provider are directly involved in the service delivery process.

The External subclass represents actors who are not part of the service delivery process but may still influence the journey or affect the outcome (e.g., previous customers and word-of-mouth). External actors are typically beyond the control of the service provider, and their influence is challenging to model the planned journey a priori.

In the bookstore example, the customer and bookstore are the obvious actors. In addition, the logistics partner responsible for home delivery is an actor. An example of an external actor could be the customer’s friend who recommended choosing home delivery.

3.2.4 Touchpoint

A touchpoint is commonly known as a step in a customer journey [23]. Although the term is widely used, the semantic meaning, the abstraction level, and the granularity vary considerably in service literature. Three main categories of interpretations can be distinguished: (1) an event involving communication or interactions between two actors; (2) a relevant activity or perception involving the service system; and (3) the channel that mediates communication.

CJML adopts the term touchpoint for atomic steps of the customer journey and distinguishes between two types that, in principle, correspond to categories 1 and 2 above. The definitions are as follows:

• Communication point: An instance of communication or interaction between a customer and a service provider.

• Action: An event or activity conducted by a customer or a service provider as a part of a customer journey.

A communication point is characterized by the communication of a message between two actors in the context of the journey. Communication in CJML is defined through the Shannon-Weaver model of linear communication [55], in which an initiator (or sender) transmits a message to a receiver through a communication channel. This definition of communication is pertinent for technology-mediated communication but has clear limitations in human encounters involving conversation. The initiator and receiver of a message are of type Actor, and the message is carried by a communication channel. A channel is formally defined as the service provider’s means of communicating or interacting with its customers [56]. Typical examples include telephone, SMS, e-mail, letters, and chat.

Fig. 7

Customer journey diagram for an actual journey containing both expected and deviating touchpoints, as seen above and below the broken line, respectively

Communication in CJML encompasses interactions with the service system that leave a digital trace in an event log. Thus, a customer booking an appointment using a mobile app is considered a communication point because the order is received by the service provider. In contrast, a touchpoint that lacks communication directed toward an intended receiver is referred to as an action.

Figure 6 elaborates upon the Touchpoint class, its subclasses, and their composition. Touchpoint has attributes which includes touchpointID, compliance, uncertainty, and endUserExperience. The compliance checks if the touchpoint complies with the planned one; otherwise, it declares a type of deviation. Deviation values include an adhoc (unintended event), missing (touchpoint did not occur), or failing (touchpoint did not succeed), which are specified in the ComplianceValues. The uncertainty attribute provides the needed flexibility for the CJML users in modeling the planned journey. Handling uncertainty in customer journeys is helpful for planners as service becomes more complicated and the end-to-end journey information becomes harder to obtain. This use case will be described in detail in Sect. 4.2. Uncertainty values include the uncertain occurrence of the touchpoint (uncertainOccurence), its uncertain number of occurrences (uncertainNoOfOccurrence), an uncertain channel used (uncertainChannel), and an uncertain initiator of the touchpoint (uncertainInitiator). In addition, the comment attribute allows the planner to add comments or notes for a given touchpoint.

The end-user experience exists on both the journey and touchpoint levels. This allows for a more granular understanding of the experience for each step in the journey. Similar to the journey level, the touchpoint experience attributes are expressed in text (endUserExperience) and on a 5-point Likert scale (larger = better experience) through endUserExperienceRating. Experience is derived from end-user feedback; however, the task of collecting and systematizing end-user feedback over time is resource intensive [57].

Touchpoints are events in a process and thus have a temporal dimension. Generally, touchpoints have start (timeStarted) and end (timeCompleted) times. In addition, a communication point can have several timestamps, designating the time at which the message originated from the initiator (timeOriginated), the time at which it was available to the receiver (timeReceived), and the time at which it was consumed by the receiver (timeConsumed). For asynchronous channels, these timestamps are appropriate. For example, in the case of an e-mail, a message can be available in the receiver’s mail client long before it is read. Similarly, a letter can be delivered while the receiver is traveling. This may have consequences in terms of the delivery of the service. For actions and synchronous communication points, such as human encounters, it may be more convenient to state the start and end times. Note that the times are expressed in Datetime, which is not a primitive UML data type. Custom data types can be declared in UML but, for readability purposes, we do not show them in Fig. 6.

There are several differences between Action and CommunicationPoint classes, as shown in Fig. 6. While both touchpoints contain an Initiator, only the communication point contains a Receiver and a Channel and is associated with a Message. The initiator and receiver have labels and refer to an actor. Channels have predefined values, which can be telephone, SMS, internet, e-mail, etc. A complete list of the predefined channels can be found online [44]. The message content can be of various formats: it can be the whole text content (messageContent), and for simplicity, it can be reduced to its key, essential content (keyMessage).

Finally, the Touchpoint class is associated with Object and BackendSystem. Objects are physical or virtual items made available for the customer as a part of a journey, and backend systems are systems that process the touchpoint. For instance, an object can be physical (e.g., a brochure) or virtual (e.g., an e-mail attachment).

3.3 CJML visual notation

This section elaborates on the visual syntax of CJML and the two diagram types, namely the customer journey diagram and the journey network diagram. The two diagram types serve different purposes, as will be demonstrated through the bookstore example.

Fig. 8

Template for customer journey network diagram

3.3.1 Customer journey diagram

The journey diagram focuses on a single end-user’s journey, and it only displays the touchpoints that directly involve this actor. The diagram comprises interconnected touchpoints in chronological order of appearance. Communication points and actions are represented by circles and rectangles, respectively. All touchpoints are annotated with an ID and a short text label. Actions are represented as rounded squares annotated with text. For communication points, the actor portrayed may be an initiator or a receiver. To avoid this ambiguity, the initiator of the communication point is reflected by the color of the circle’s periphery. Traditionally, the orange color has been used to denote customer-initiated communication points. However, we recommend providing a contrast that can be perceived by colorblind people. When a specific actor initiates communication, the actor’s designated color will be used. The inner area of the circle is reserved for a symbol representing the communication channel. CJML offers a standard library of symbols representing various channels. The communication points in actual journeys are associated with a certain visually encoded compliance value, which can be planned or deviated. In case of a deviation, the touchpoint is put below the broken line. The deviation may be an ad hoc (unbroken circle boundary), missing (dotted boundary), or failing (crossed) deviation.

Figure 7 shows a principle sketch of a customer journey diagram. The skeleton shows an actual journey including deviations from the planned journey. For actual journeys, the actor in focus is represented by a symbol and name (or ID) on the leftmost side. The planned journey is depicted above the broken line, while deviations in the actual journey are shown below the broken line (D2.1 and D2.2). In the case of an actual journey that complies with the planned journey, only the leftmost actor symbol and name show visual differences between the actual and planned journey diagrams.

The end-user experience can be present optionally in the journey diagram. The textbox that describes the experience contains the textual experience, text rating, and an emoticon. The 5-pt Likert scale ranges from (1 $=$ very dissatisfied) to (5 $=$ very satisfied), with emoticons expressing the values. As discussed in the previous subsection, the experience exists at both the journey level and the touchpoint level. In the CJML visual notation, only the touchpoint level is illustrated.

Fig. 9

A journey group with a decision point, splitting into two possible paths. Each of these paths constitutes a planned journey

The journey phase (optional) is shown in the topmost portion of the diagram. A single phase covers the journey elements and journey operators (if present) that belong to itself. The notation shows a bracket pointing to the phase and phase name in textual format.

The customer journey diagram is useful for planned and actual journeys involving a few actors. With more than three actors, the coloring scheme tends to become very complicated. The journey diagram is especially beneficial when deviations need to be emphasized. It allows users to conveniently point out parts of the customer journeys that need attention and improvement.

3.3.2 Customer journey network diagram

The customer journey diagram is recommended when we focus on a single actor. However, it becomes impractical as the number of actors involved in a journey increases, as further elaborated in Sect. 4.3. To address this issue, the customer journey network diagram was developed to visualize multiple actors and their mutual touchpoints simultaneously.

Figure 8 shows the template for the journey network diagram. Here, each actor has a dedicated lane, inspired by the swimlanes in BPMN. The actor symbol is positioned at the left end of each lane and has the same notation for both planned and actual journeys. For each actor, the touchpoints are shown chronologically in their order of appearance on the horizontal axis. The action element appears similar to how it is depicted in the plain journey diagram. The main difference is the visual appearance of the communication point. In a journey network diagram, communication points appear as vertical pairs positioned in the swimlanes of the corresponding initiator and receiver. The communication pair is connected with a vertical arrow (message flow) running from the initiator to the receiver. Note that this arrow will be changed in the future to distinguish it from sequence flow. Furthermore, the symbol representing the communication channel is shown inside the touchpoint element to the left of the touchpoint label. Swimlanes reduce the need for color to distinguish the initiators of communication points. The touchpoint concerning the initiator appears filled (or dark), while the receiving touchpoint has no filling.

The journey phase can optionally be displayed as a running header, serving as an overview and abstraction of the contained touchpoints and operators. An extra swimlane can be introduced for two purposes: (1) for extra annotations or comments in the diagram, or (2) to express user experience data in the case of actual journeys.

The network diagram and the journey diagram use the same experience rating. However, the rating in the text format is not used. Here, the textual description and emoticons are used and separated in another swimlane.

Portraying deviations from the planned journey is another principal difference. Here, there is no line separating deviations from the planned journey. Thus, a deviating touchpoint is highlighted by a shadow on its back. It applies to both actions and communication points. Similar to the journey diagram, the network diagram shows a cross for failing touchpoints and broken lines for missing touchpoints.

Fig. 10

Planned and actual journey using the customer journey diagram

Fig. 11

Planned and actual journey using the journey network diagram

3.3.3 Online bookstore example

In this section, we use the bookstore example to illustrate the core concepts and visual notations used in CJML. As envisioned by the service provider, which, in this case, is the bookstore, the planned journey is as follows: First, the customer orders books online through the bookstore’s web application. The customer has two delivery options: home delivery or pick-up from the nearest store. After completing the order, the bookstore receives and forwards it to their financial partner. This step is not part of the customer’s journey. Then, the financial partner finalizes the order invoice and sends it to the customer via e-mail. Subsequently, the customer receives the invoice and pays the indicated amount. When the payment is received, the financial partner confirms the payment to the online store (again, this step is not visible to the customer). Finally, the customer receives the package according to the delivery choice. Most real-world examples are lengthy and complicated by nature. For example, there are more options for payment, there is often a specialized logistics partner involved, and the status messages keep the customer notified about the expected delivery date.

The journey group is shown in Fig. 9. It comprises two planned journeys that share the first three touchpoints. The last touchpoint depends on the customer’s chosen delivery method. The decision point adopts the regular flowchart notation using a diamond symbol, splitting the journey into two possible paths. The two planned journeys can be easily derived from the journey group as two separate diagrams and differ only at the last touchpoint. A journey group is particularly advantageous in cases in which the service delivery process contains multiple decision points, resulting in a large number of planned journeys.

One of CJML’s advantages is the portrayal of customer journeys at the level of individuals using customer journey analysis [32]. This empirically based method allows service providers to systematically identify deviations in their service offerings that may correlate with end-user dissatisfaction. The plain journey diagram is ideal for visualizing deviations in individual journeys. In contrast, the journey network diagram is more convenient for visualizing multi-actor journeys or service delivery networks. In the following sections, we will show the relationship between these diagram types using the bookstore example. We continue with one of the planned journeys from the journey group in Fig. 9.

The upper planned journey in Fig. 9 (home delivery option) is shown in both the journey diagram and the network diagram in the upper part of Figs. 10 and 11, respectively. The plain journey diagram contains only the touchpoints visible to the customer (T1–T4). In contrast, the network diagram includes two more touchpoints (i.e., T1.1 and T3.1) that include the communication points between the bookstore and the financial partner. Touchpoints T1.1 and T3.1 are numbered distinctly to prioritize the numbering of the journey diagram. The diagrams show the trade-off between the exclusive focus on one actor, i.e., the customer, and the completeness of the whole service delivery network. The choice of the diagram depends on the CJML user’s objective. It could be argued that the hand-overs between the service provider and its supply chain partner are not a part of a traditional journey map. However, in complex service constellations, the roles of the actors may be blurred, as for C2C eCommerce where two consumers benefit from the mutual interaction through a platform provider, see Sect. 4.4.

The actual customer journey for Tom, a fictitious character, is shown in Figs. 10 and 11 (bottom parts). In this example, Tom follows the first touchpoints of the planned journey until receiving the invoice (T2). However, after studying the invoice, Tom discovers a hidden delivery fee that he thought was already included in the price (shown as a deviation, D2.1). Next, Tom calls the financial partner to clarify the issue (D2.2) and realizes that he was not attentive when ordering the books. Here, we show an example of Tom’s experience at this particular touchpoint. Tom was dissatisfied (rating = 2 (dissatisfied)) and states, “I did not like the hidden fee.” This experience is shown in both the journey and network diagrams. Next, Tom proceeds to pay and receives his package a few days later.

The actual journey scenario contains two additional touchpoints; an action and a communication point not found in the planned journey. These deviations are classified as ad hoc touchpoints. In the plain journey diagram, the deviations are immediately visible below the broken line. In the network diagram, ad hoc touchpoints are marked by shadowing the touchpoints. Note that the network diagram contains touchpoint labels for both the initiating and receiving actors. The journey diagram, in contrast, is especially suited to reveal sequence errors. As a concluding remark, the visual notation of CJML has several additional features that can be found in the online documentation, e.g., timing of touchpoints, the grouping of touchpoints in phases, concurrency, and support for unordered touchpoint sequences [44].

4 User involvement

In the following sections, we present four examples of user involvement and how they have impacted the development of CJML.

4.1 Case 1: Refining the core concepts

The main challenge in developing the conceptual basis of CJML was to find the appropriate terms and concepts that the target group would be familiar with and, at the same time, to constrict the concepts through precise definitions and attributes (RQ1). In this section, we describe how the conceptual foundation of CJML was found to lead to usability problems and how, in response to users’ challenges the language was revised in an attempt to conform it to users’ ways of thinking.

4.1.1 Problem identification and evaluation procedure

The revised version of CJML described in Sect. 3.2 uses the term touchpoint for all types of process steps and further classifies them as either communication points or actions. However, the early versions of CJML adopted the term touchpoint as a synonym for communication points, in contrast with non-communicative action see Fig. 12. Over time, it became evident that some users found this use of terminology confusing. A comprehensive evaluation was therefore undertaken to address this issue.

Fig. 12

Simplified metamodel for the original and revised versions of the touchpoint concept

In all, 48 external target users participated in evaluating various aspects of CJML [43]. The evaluation was organized into three sessions and alternated between plenary presentations, individual exercises, and collaborative modeling sessions in small groups. First, the participants were introduced to CJML in a 15-minute plenary session. Two individual exercises immediately followed, the purpose of which was to check whether the definition of touchpoint was well understood by the participants. A reference guide with the core definitions and concrete syntax was available for the participants during the problem-solving part. The first exercise presented a scenario with a fictional persona, “Peter,” who decides to buy new furniture from a webstore. The task was to analyze the text and identify communicative events. The scenario consisted of 18 sentences, 7 of which contained communicative events. These touchpoints were identified by 46 out of the 48 participants, a large majority. An example of a sentence that was correctly identified by all the participants is as follows: “After four weeks, Peter received an SMS that the furniture was ready to be picked up at the warehouse.” However, some sentences with no communicative events were incorrectly identified as touchpoints. The following example (describing an action) was incorrectly identified as a communicative touchpoint by half of the participants: “The next day, Peter drives to the warehouse to collect the chairs.”

In the second exercise, the participants were asked to consider 17 statements and classify them as either touchpoints or actions. Again, the touchpoints were successfully identified by a large majority of the participants, with an average success rate of 96%. The participants were less successful in identifying actions, with an average success rate of 66%. To illustrate the spread in the classification of actions, consider the following examples: “Carrie is sitting in the kitchen, writing a shopping list before going to the grocery store.” This action had a success rate of 95%. However, the action “Carrie grabs a shopping cart on her way into the store” had a success rate of only 34%. It seemed that sentences describing an interaction with the service system (e.g., the shopping cart) had a low success rate.

The last two sessions focused on the concrete syntax—communicative events only—and the participants’ ability to model the planned and actual customer journeys. The results from these sessions revealed that the participants were able to model both planned and actual journeys with a high precision level [43].

4.1.2 Modifying the metamodel according to the user feedback

The observation that new target users assigned touchpoints (in the interpretation of communicative events) to non-communicative events made it evident that the conceptual basis of CJML was not in line with users’ understandings (RQ1) and needed to be revised. Touchpoint has become a buzzword in the service industry, and the users found it problematic to restrict its semantics to communicative events. Alternative remedies were found to improve usability: removing the term touchpoint from the terminology, replacing it with another term, or revising and extending the terminology. Because the term is an established expression in the target group, we decided to keep it as a general term for a journey step, instead developing a typology for the subclasses of touchpoints. With the revised terminology (see Fig. 12), the target group could continue to use the term touchpoint for a step in a journey, and further distinguish them as communication points or actions. The evaluation also revealed the need for improved guidelines on this matter.

4.2 Case 2: Handling uncertainty in service processes

eCommerce and consumer-to-consumer (C2C) sales have grown rapidly in recent years. For companies to deliver high-quality C2C services, they need insights into their customers’ end-to-end journeys. However, companies struggle to attain this knowledge [20]. A case study was conducted with an eMarket company that provides a digital C2C-platform. The purpose was to analyze the end-to-end service process and customer journeys to reveal potential areas for improvement and, in the end, facilitate increased uptake of the service. The results from the case study pointed toward a need for handling uncertainty in service processes (RQ2).

4.2.1 Problem identification and evaluation procedure

The service in question connects people wishing to get help with, for example, house cleaning and gardening, with people willing to do the job. The eMarket company provided several communication channels, such as chat and e-mail, but users could also communicate through channels outside the control of the company. We collaborated closely with the cross-functional team responsible for the development, operation, and support. In a series of workshops, we went through the team’s own documentation of the process steps and constructed draft models of the planned customer journeys.

In the handling of various types of uncertainty in customer journeys, new requirements for the visual notation were uncovered. Consequently, we define four types of uncertainty: 1) in the number of touchpoints due to reliance on ad hoc communication between the two end users, 2) in the choice of the communication channel; 3) in the occurrences in which a touchpoint may occur, but not necessarily; and 4) in the initiation of a touchpoint. The notation for uncertainty is shown in Fig. 13.

Fig. 13

Extending the notation to include uncertainty

The service owner’s documentation of the service processes was refined and validated through the systematic use of the methods “mystery shopping” and service safaris [23], where two researchers completed the various roles in the service process. Detailed process maps and customer journeys were then visualized with CJML and handed over to the eMarket company for discussion and evaluation. The mystery shopping contributed first-hand experience of the service and helped fill in gaps and touchpoints that were missing in the initial sketch.

The new notation to be used to express uncertainty was presented to the development team of the eMarket company, and their feedback was collected through meetings, workshops, and e-mail exchanges. The team found the extended notation easy to understand. The CJML diagrams enabled the team to detail the service processes, here given the uncertainties that are inherent in a C2C setting.

The documentation of the planned journeys revealed opportunities for improvement in the process. As a result, the team adjusted the service delivery process and eliminated unnecessary touchpoints. The eMarket company used the CJML diagrams as a basis for considering future changes and features that could add value; they particularly mentioned the usefulness of having an overview of what information is issued and when in their endeavor to optimize the service experience. One employee for the eMarket company stated, “A common language for identifying the various customer journeys in our company will streamline product development across the different departments.” The company also used the diagrams when communicating with external companies as part of the service delivery network. One employee explained this point as follows: “In meetings with [external company], we have used the planned journey to uncover where we should include the partner’s content and information, and what we should inform our customers about in the various stages.”

The case study also included an analysis of actual journeys and service experiences. Eight end users were recruited in the initial phase of their journeys, and reported their detailed experiences throughout their journeys. The actual journeys were reconstructed and compared against the corresponding planned journey. Both the method used (customer journey analysis) and the detailed results are described in [58]. On average, the actual journeys consisted of 23 touchpoints, and they all included deviations from the planned journey. Still, the end users were mostly satisfied and did not experience the deviations as problematic.

4.2.2 Extending the expressiveness of CJML

The eMarket case study revealed the need to extend the visual notation to handle various types of uncertainty in planned journeys (RQ2). Together with the eMarket team, we also explored further extensions that emerged from the analysis of the long (in terms of touchpoints) actual journeys. This resulted in the addition of a placeholder for repeated sequences and the introduction of journey phases (as shown on the top of the diagram in Fig. 14). These extensions were further evaluated with users in subsequent case studies.

The journey phase offers the possibility of abstraction in the DSML and was included as a direct consequence of user involvement. In general, many features in CJML emerged directly from the users, although we also rejected suggestions. To illustrate this, we invited users to evaluate the symbols representing the communication channels during the evaluation described in Sect. 4.1. The feedback from the users sometimes diverged or directly conflicted, hence failing to constitute a comprehensive evaluation of the entire set of symbols.

4.3 Case 3: Extension of CJML to support service delivery networks

The following case study describes how CJML was used to document and analyze a complex, multi-actor service process (RQ3) managed by an eHealth software company. The company was about to release a new generation of software tools for surgery planning. The eHealth company wished to evaluate the usefulness of CJML in the training of their consultants who were supporting its implementation in health institutions. Surgery planning typically involves several hospital departments, medical specialists, and administrative personnel. Critical information is exchanged electronically over time among the actors through the company’s systems. Information is also exchanged with the patient (through consultations, letters, and SMS) and the referring general practitioner.

4.3.1 Problem identification and evaluation procedure

The goal was to map the process of surgery planning, here reflecting the actors’ work processes, and evaluate the usefulness of the diagrams for training and knowledge sharing. For the evaluation, the company needed a comprehensive overview of the end-to-end process, as seen from various actors’ perspectives.

Two patient scenarios were developed iteratively in a series of workshops with software developers, consultants, and medical specialists: (1) an emergency case (cesarean operation) and (2) an elective case (hip replacement). The patient scenarios were described in textual format and then translated into CJML diagrams.

It soon became evident that the basic journey diagram was inadequate because it could only express single-user journeys. Consequently, there was a need to expand the visual notation with a new type of diagram that could express mutual interactions among several actors. We found the framework of service delivery networks [17] to be a suitable conceptual basis for the new diagram type, which was developed and evaluated in the context of the case study. Inspired by a UML activity diagram with swimlanes, we designed the journey network diagram where each actor’s journey appears within a horizontal swimlane. Time extends in the horizontal direction, and the journey phase can optionally be displayed as a running header serving as an abstraction of the contained touchpoints.

Figure 14 shows an excerpt from the referral phase in the elective patient scenario. Here, a general practitioner (GP) has referred the patient to an orthopedist, and a coordinator notifies the patient about the upcoming consultation before informing the GP. After a waiting period, the patient receives an SMS reminder the day before the consultation at the outpatient clinic. In contrast to the regular journey diagram, here both the initiator and the receiver of a communication point are immediately visible across the corresponding swimlanes.

Fig. 14

An excerpt of the surgery planning process shown as a journey network diagram

The CJML representations of the two patient cases were evaluated in a workshop with seven consultants, all of whom were clinically educated and employed by the eHealth company. First, they were introduced to the tools through a simplified example. Next, the consultants were given the task of making CJML representations of the emergency case based on the textual description of the scenario. The elective scenario was modeled in the same way. A printed version was mounted on the wall, and screenshots of the corresponding software modules were attached to the relevant communication points.

The target group found the diagrams easy to understand and highly useful in providing an overview of the process of surgery planning. “At a general level, it gives a good picture of who is doing what and how systems are used,” one consultant stated. Another consultant said, “I think the diagrams might be useful for all actors involved in the process. One often acts without seeing how others are affected, and this is particularly problematic.” Another stated, in reference to the complexity of the surgery planning process, “The visualization of the process was clear. Simplification of activity in different swimlanes brings nuances and demonstrates complexity. The various actors often focus on their own tasks and the diagrams usefully show the totality of all stakeholders, especially for understanding the patient’s experience.”

4.3.2 Improvement based on user feedback

The eHealth case study revealed that the swimlane diagram was a useful supplement, extending CJML to accommodate more complex multi-actor services (RQ3). The direct linkage between the communication points and the system screenshots was found to be important—even necessary—in navigating the complex process of surgery planning. The idea came from one of the medical specialists during the development of the scenarios prior to evaluation. This demonstrates the importance of including users in development.

4.4 Case 4: Evaluation of the journey network diagram type

The previous user involvement case (Sect. 4.3) demonstrated that the customer journey network (CJN) diagram was perceived as useful for modeling more complex service processes. Consequently, we decided to conduct a more systematic evaluation of this diagram type. The aim was to investigate whether target users manage to produce accurate models using CJN (RQ4). For this purpose, we recruited users (employees) from several eMarket companies. The participants were all directly involved in the design or improvement of the operative service delivery process. Below, we describe the evaluation procedure, potential usability issues, and feedback from the participants.

4.4.1 Evaluation procedure

A total of 18 users participated in the evaluation workshop. All users worked in service development and/or management in service-providing companies. The users had various levels of experience with CJML prior to the session: five users had never heard about CJML, six had heard about it, seven had some hands-on experience with CJML, and one had a lot of experience with it.

First, we arranged an introductory session in which we provided the users with an introduction to service processes and customer journeys in general, as well as a walk-through of the CJML modeling language and a training exercise to familiarize the participants with the relevant terminology. The introductory session was similar to the one used in the first formal evaluation described in Sect. 4.1, but contained an additional module about the CJN diagram. Next, we presented the users with three different scenarios and modeling exercises of increasing complexity. A paper-based toolkit was prepared for the modeling exercise with the diagram elements and touchpoints provided as ready-cut elements that could easily be moved and attached. The scenarios described fictive, actual journeys. These were derived from experimentation with similar, existing service processes using methods described in Haugstveit et al. [58]. Here, we present results from the first (easiest) exercise. The participants were given the following text scenario describing a C2C secondhand sales transaction through a digital platform.

Scenario: John wants to sell a lamp. He advertises using a digital C2C marketplace. Sara sees the ad and contacts John through the digital platform’s messaging system. She signals her interest by suggesting a time for pick-up, and she also provides her mobile phone number. John sends Sara an SMS to confirm the deal and to provide his address. Sara visits John the same evening, and they exchange the lamp and money. John makes sure to change the status of the ad to “sold” in the marketplace.

The participants were provided with swimlanes for the three actors: seller, buyer, and the digital platform. The communication points and actions were pre-made, and they had to identify and match the two components (Sender and Receiver) of each communication point and position them in the correct order. In total there were 11 pieces to arrange in the pre-made swimlanes—10 communication points and one action. The participants worked individually, and all the resulting models were photographed for further analysis.

A set of success criteria was defined for measuring the modeling performance of the participants:

• C1: Pairing the correct actors (initiator and receiver in a communication point).

• C2: Positioning them in the correct swimlanes.

• C3: Achieving the correct sequence of communication points.

• C4: Achieving the correct sequence of actions.

Table 2 Evaluation criteria and results

Figure 15 shows the correct diagram for the scenario above compared with one participant’s model. In all, 17 out of 18 users successfully paired the communication points. Everyone positioned the elements in the correct swimlane, and 16 out of 18 arranged the communication events and actions in the correct order (Table 2). The participant’s diagram shown in Fig. 15 contains an incorrect pairing of Initiator and Receiver for the first communication point. The incorrect pairing seemed to be caused by failure to differentiate between action and communication points. When users were unsuccessful at arranging the communication point, it appeared to be either an error with no logical explanation or related to the user’s understanding of what comes first (putting out the ad on the marketplace and then taking pictures of the item versus taking pictures of the item and then creating the ad).

Fig. 15

The correct solution to the modeling exercise (upper part) and one example of a model produced by a participant (lower part)

Preliminary analysis of exercise 2 also demonstrated that users were mostly successful in pairing and arranging communication points. What seemed to be most challenging was correctly identifying all communication points, as they were not predefined in the exercise. Consequently, several users missed some communication points or, alternatively, added extra communication points not described in the scenario.

After the modeling sessions, we collected feedback from the users through a questionnaire. Almost all (17 out of 18) reported the CJN diagram to be helpful and easy to use. The users were also asked in which situations the diagram would be valuable. One user pointed out that it is useful when you have to model journeys consisting of several actors, “to document systems and internal processes, and not only those that the customer actually sees (ID33).” Others stated that it can help facilitate shared understanding within a team: “We are creating a new system, so this can be useful to ensure that the whole team has a shared understanding regarding the customers’ needs (ID2).” In terms of challenges or other negative aspects of CJN, some stated that it was difficult to identify the start of the journey—should one include the action of picking up the phone to look for a marketplace to use, or start when the user creates the ad? “What are the boundaries of what should be taken into account and left out? (ID1).” Others noted that differentiating between action and communication points was challenging.

Some also provided suggestions for improvements, such as allowing for more information about each communication point, e.g., date and time of each touchpoint or the content of a communication event: “[...] It would have been valuable to showcase the type of information that is being exchanged in each communication event. This is something you should be mindful of when you design new services (ID3).” One user also noted that it would have been beneficial to have an additional swimlane for notes (e.g., other actors that might be included at a later point): “Add a line called ‘other actors’ [...]. This could then be used as a reminder to look into that specific process later on (ID8).”

4.4.2 Modifying the journey network diagram based on user feedback

In all, the evaluation demonstrated that the participants managed to produce fairly accurate models using CJN (RQ4), and found the CJN diagram valuable and user-friendly. However, some of the challenges that were identified during the first evaluation persisted (Sect. 4.1). First and foremost, the distinction between types of touchpoints (communication point versus action) was still problematic. Rather than a problem relating to the notation per se, this seems to be a problem inherent in the translation of the scenario into a journey. Second, the ability to identify the boundaries of a user journey varied among the participants. Consequently, some would introduce more communication points than others, causing variation in the results. Taking into consideration the short time ($\sim$15 min) used to introduce CJML to the participants, the results from the evaluation were found to be satisfactory. Nevertheless, these observations inspired us to substantially improve the introductory material and guidelines for distinguishing actions and communications points.

The CJN diagram was refined several times, incorporating feedback from the users. Two optional swimlanes have been added to (1) make space for textual annotations and explanations of steps, and (2) express user experience data when mapping actual journeys.

5 Lessons learned from user involvement

CJML has been developed in close collaboration with industry partners with the aim of making it an intuitive modeling language for a broad target group with presumably little or no modeling experience. Throughout development, we have received positive feedback on the usefulness of CJML as a lens for viewing service processes from the perspective of end users.

The first formal evaluation of CJML (Sect. 4.1) showed that 92% of the participants found CJML “easy” or “very easy” to use. When asked to comment on its perceived usefulness, 88% found it “useful” or “very useful” for their professional work. A detailed analysis of users’ modeling efforts revealed that they were able to model service delivery processes with a high level of precision [43]. After extending CJML to support service delivery networks a subsequent evaluation was performed, this time with a smaller sample (Sect. 4.4). Even for these more challenging modeling exercises, almost all participants (17 out of 18) found CJML easy to use and deemed it either “useful” or “very useful” for their professional work. This suggests that CJML can support a common understanding of a complex service process among users with different backgrounds, ranging from service designers and software engineers to business developers and managers.

Involving users in the development of CJML led us to a few valuable lessons that could be generalized and be of use for researchers and practitioners; these lessons are shown in Table 3. At the same time, we discuss these lessons and evaluate their correspondence with the requirement analysis of DSMLs, as conducted by Frank [36].

When the targeted user base is broad, L1 can be a very important first step that affects the way the DSML is developed and evaluated. By identifying all the users and stakeholders of a DSML, developers can approach these groups, become inspired by them, and include them in the development phase, which would allow them to refine their designs. By identifying the targeted user groups and including users early in the process, there is a greater chance of achieving a high sense of familiarity with the concepts of a DSML and ensuring their representation at the end [7]. Identifying the stakeholders is necessary to kick-start the design phase with initial input coming from experience before introducing it to the users for further evaluation and feedback (L2). Moreover, it is crucial to document user needs early in the process in order to fulfill them as soon as possible [7, 11]. A requirement analysis that stems from close collaboration with users and refers to the related literature can lead to the establishment of better goals for the developed DSML (L3). These three lessons are connected to Frank’s [36] Requirement P1 that states the following: “The concepts of a modeling language should correspond to concepts prospective users are familiar with... The more users are familiar with the concepts of a DSML and their representation, the easier it will be for them to understand and use them properly.” Naturally, by identifying the targeted users and stakeholders, presenting some initial designs, and collecting early user requirements, the DSML developer can better understand the user and create a tailored modeling tool.

Table 3 Lessons learned for DSML development

When designing models and syntax for the new DSML (L4), related work in the field can provide the initial material that will be evaluated in the next stage (L5). In the CJML case and in the case of a DSML for services more generally, the aforementioned Gap Model of service delivery is a good example of a suitable model to start with. Frank’s [36] requirements for DSML development can also be a valuable guide here. Based on Frank’s work, a modeling language should provide domain-specific concepts with invariant semantics (P2), extension mechanisms for future use (P3), concepts that allow for the clear differentiation of the different levels of abstraction within a model (P4), and a clear mapping of its concepts (P5). A DSML developer can take these or similar requirements into account when addressing a language’s models and syntax. Subsequently, these choices can be empirically evaluated by the target users and refined by following an iterative UCD-based process between L3 and L5. This means that the results of the empirical evaluation of L5, if necessary, feed the requirement analysis of L3 in order to modify the model and/or syntax designs of L4 and so on.

Naturally, the lessons learned act as suggestions for practitioners approaching the development of a DSML from a UCD perspective. We believe that these lessons can be of value for DSML developers, especially when it comes to DSMLs that target a wide and heterogeneous audience (e.g., when modeling service processes), as they enable developers to structure their processes.

6 Limitations and threats to validity

CJML constitutes a systematic approach to customer journey methodology, an interdisciplinary subject area characterized by nonstandard formats and lack of formalism. The active involvement of users throughout the development of CJML has most likely contributed to the promising results and perceived usefulness. Nevertheless, we have identified several weaknesses in CJML that need further attention. In the next subsections, we present the limitations and threats to the validity of our work.

6.1 Limitations

The modeling of customer journeys presents certain general challenges and we have also identified a number of weaknesses of CJML from industry case studies and evaluations. The most frequently mentioned challenge relates to the abstraction and granularity of touchpoints. Digital touchpoints, such as an e-mail or an SMS, can be easily confined, but interaction with a web application that extends over time is an example of an inherent modeling problem. Human encounters, especially human conversation, are additional challenges. As a general rule, a change in the core attributes of a touchpoint (channel, actor, the direction of communication, etc.) is an indicator for delineation. However, more nuanced methods and guidelines are needed for a reliable approach to the delineation of touchpoints. From the evaluations of CJML, we are also aware that in some cases, users find it difficult to distinguish the two types of touchpoints: actions and communication points. A higher success rate is observed regarding the identification of communication points compared to the identification of actions. Work is in progress to provide better support and guidelines in this area.

Another limitation of CJML is its incomplete abstract syntax. The metamodel has up to now been used for documentation purposes only. Thus, CJML is a modeling language for the conceptual level. Furthermore, the metamodel is decoupled from the visual notation and does not inscribe the actor and channel symbols. This also means that some constraints are expressed only in the English language. The compliance of actual journeys to the planned journey is also processed manually. Currently, deviations are extracted manually through the guidelines introduced in Customer Journey Analysis [32]. However, with the advent of big data, manual checking becomes unfeasible. CJML has to adapt to the growing data requirements and will explore new ways to automatically detect deviations, both at the journey and touchpoint levels.

We are also aware of weaknesses in the visual notation of CJML. For example, we used the same arrow type in the journey and in the network diagram, even though their semantic meaning is fundamentally different. In the network diagram, these arrows signify message flows instead of sequence flows. Development to amend this inconsistency and regarding the improvement of the visual notation of CJML is in progress to fully comply with the principles of cognitively effective visual notations [59]. While the conceptual part of CJML has been tested and evaluated systematically and is approaching a certain level of maturity, a formal semantic description is missing. Additional work is needed to use CJML as a basis for automated capturing, monitoring, and managing customer journeys.

6.2 Threats to validity

Internal validity When evaluating the awareness of CJML’s core concepts, the participants were asked to classify pre-made statements as communication points or actions. Therefore, we cannot exclude the influence of the researcher’s personal judgment in the design of the exercises. To minimize the threat of subjectivity, the exercises were discussed extensively, both within the research team and with independent researchers. When analyzing the applicability of CJML for modeling journeys, the participants were provided with pre-made text scenarios. A threat to validity is that the scenarios might emphasize the touchpoints, as several attributes need to be specified, thereby simplifying the modeling task itself. We are currently exploring alternative approaches in which the definition of a scenario is part of the exercise. Future evaluations are needed to determine the general applicability of CJML.

Conclusion validity While the formal evaluation of the basic part of CJML engaged a total of 48 participants, only 18 participants took part in the evaluation of the extended CJML for service delivery networks. The small sample size cannot justify a reliable conclusion about the precision of the results and the perceived usefulness of the extended CJML. Future evaluations are needed to obtain conclusive results.

External validity To date, we have used a physical setting with tangible toolkits for the exercises to assess target users’ modeling efforts. Work is in progress to develop tools, e.g., a graphical editor with drag-and-drop functionality, for a more efficient and satisfying modeling experience. Using online tools will also enable us to efficiently scale up the sample size during evaluations. This will, in turn, mitigate the threat associated with conclusion validity.

CJML targets a heterogeneous group of users who presumably have little or no modeling experience. At the same time, CJML supports the modeling of service delivery processes ranging from a dyadic customer–company relationship to a complex service delivery network. To date, we have recruited participants broadly from service-providing organizations without using exclusion criteria concerning previous experience with modeling. In future evaluations, it would be worthwhile to adapt the complexity of the modeling exercises to match the modeling experience of the participants.

7 Related work

In this section, we first provide an overview of related work on customer journeys. Then, we present approaches that add formalism to customer journeys. Finally, we present general-purpose modeling languages and contrast them against CJML.

7.1 Methods for customer journeys

The term “customer journey” has become a metaphor for taking a customer-centric perspective, but it also encompasses a large collection of methods to investigate end users’ encounters with service offerings. Almost exclusively, a customer journey materializes as a visualization referred to as a customer journey map. Customer journey mapping comprises a variety of practitioner-driven ways of portraying a time-logical sequence of customer touchpoints against a secondary dimension [24]. Basically, two approaches can be distinguished: analysis of an existing service process (“as is”) and design of a future service process (“to be”). Often, the two approaches are combined in service improvement and redesign.

Service blueprinting is a method that is important for the development of customer journey methodology. A service blueprint is a flowchart diagram that connects the essential customer steps with the underlying business processes. Originating from a business-centric perspective [50], service blueprinting has evolved to also encompass the customer’s perspective [60]. More advanced forms of the service blueprint, e.g., the service experience blueprint [61], contain a description of the customer-facing steps in a more structured way than general customer journey maps.

A theoretical framework to distinguish planned and actual customer journeys was introduced in [32]. The accompanying method called customer journey analysis has been identified as an important way to improve service quality [62].

7.2 Formalism and customer Journey Modeling

There are much related work in the literature focusing on touchpoint, the customer journey’s main construct. In a recent paper, De Keyser et al. [63] propose a nomenclature where touchpoint is central, based on a literature review in business and management journals. In the following, we describe works that model customer journeys that provide abstract syntax (mainly in metamodel format) and the concrete syntax of their visual notation.

Heuchert [30] proposes an overarching method for mapping customer journeys based on personas. For the core modeling procedure, the persona and the customer journey are modeled separately. The abstract syntax in provided in a metamodel format. Generalized lessons learned from the process are transformed into methodological guidelines that aid the target group in mapping their end-user journeys. Note that the overarching method deals with a (human) participatory approach and does not have a data-driven nature.

On the other hand, Berendes et al. [64] introduce a data-driven approach to modeling customer journeys specifically for high-street settings. The High-Street Journey Modeling Language (HSJML) focuses on digitalized touchpoints and includes the concept of an “intermediary,” which acts as the mediator between an end-user and a service provider that deals with the platform responsible for the data level. The authors also provide linguistic constructs and modeling rules confined in their metamodel. In addition, they provide a concrete syntax describing the visual notation. Similar to CJML’s adoption of swimlanes, HSJML was also inspired by and borrows its pools and lanes from the BPMN 2.0. Despite having a technological approach (and claiming a purely digital setting), their work is currently at a conceptual level, and no modeling tools that can build HSJML models automatically from event logs are available.

Moving from conceptual modeling to implementation, Lammel et al. [52] present a semantic lifting approach for customer journeys. The authors implemented semantic technologies from a previous version of CJML, Service Journey Modeling Language (SJML) [65], and proposed SJML 2.0. The paper builds on SJML concepts (i.e., metamodel and graphical notation) and focuses on the technical results from their technical architecture. With semantic lifting, the use of their ontology (although not disclosed) enables machine-interpretable semantics, allowing for analytical reports for the users. Such reports include, among others, end-user experience graphs, channel graphs (most channels used), and actor graphs (most active roles). Having semantically annotated data allows for smoother machine interpretation; however, it is a challenge to annotate unstructured data and apply semantic lifting in the real world.

In this respect, a more suitable technical approach uses process mining, which deals with messy real-world event logs. Bernard and Andritsos [66] have pioneered the use of process mining for customer journeys. They propose a journey mapping model based on process mining and customer journey constructs. Process mining is a data-driven analytics field for process management [53], which was leveraged to assess the impact of a journey’s duration on customer experience. At first, they identified the main components of customer journey maps based on information synthesized from a literature review. These journey constructs include customer (end-user in CJML), journey, mapping, goal, touchpoint, timeline, channel, stage, experience, lens, and multimedia. They provided a hierarchical presentation of the Customer Journey Map (CJM) model based on the aforementioned journey constructs. This shows the CJM model’s abstract syntax, even though it is not necessarily in metamodel format. Their work does not focus on visual language and does not provide concrete syntax (visual notation). This scenario is opposite to CJML, as it began as a visual language and will be integrated with data-centric technologies, i.e., Process Mining and Machine Learning, in the upcoming versions.

Table 4 The comparison of CJML with the general-purpose languages, such as BPMN, CMMN, and UML, that concern the main customer journey constructs

7.3 Comparison of CJML with GPMLs

GPMLs such as BPMN [34], CMMN [67], and UML [33], can model customer journeys to some extent. Here, we discuss their differences with CJML when modeling customer journeys. We assume the reader has background knowledge of these languages and direct them to the corresponding references if more information is needed.

Unlike DSMLs, GPMLs are not capable of capturing the detailed constructs needed for specific domains. For instance, the modeling platform for Customized Design Thinking (CuTiDe) [68] is accustomed to the requirements of Design Thinking principles and acknowledges the weakness of GPMLs toward Design Thinking. In addition, HSJML [64] is an example of a DSML that captures the details of high-street consumer settings and compares their work with other languages, including GPMLs. The authors of HSJML also state that BPMN, as a GPML, does not capture customer journey constructs such as stages (or journey phases in CJML), touchpoints, and high-street events. Although it is already well known that GPMLs are less efficient in specific domains, we discuss the extent to which GPMLs can model in the customer journey domain and why there is a need for CJML.

Table 4 shows a detailed comparison of these languages concerning the customer journey constructs. We start by comparing languages with the primary journey constructs, which are the steps, sequence, and end-user perspective. The comparison also includes the supplemental features needed to illustrate a customer journey efficiently.

In summary, the table shows that CJML has numerous advantages over GPMLs. CJML has the end-user perspective of the touchpoints and provides multi-channel information, end-user experience, and journey phase. It also provides a view of the actual journeys individually. On the other hand, GPMLs can capture the steps (although not necessarily from the end-user’s perspective), sequence flow, journey operators (or logic gateways), and the multi-actor view. The table also shows the limitations of CJML. CJML can model the message content, but it only models the message flow partly (only for the network diagram). CJML also cannot model the data objects and is not capable of advanced functions, such as hierarchical decomposition or aggregation of touchpoints. BPMN and CMMN have these capabilities, while the UML Sequence Diagram leads in modeling messages. Below, we discuss each GPML in detail.

BPMN BPMN is a standardized language for business processes. It contains a rich set of graphical notations for expressing activities that can be (part of) a customer journey. The tasks in BPMN are “atomic,” which may correspond to the “atomic” CJML touchpoints. The BPMN pool and lane can view multiple actors in a journey similar to the CJML’s network diagram. BPMN can also disclose the initiator and receiver of a task through the message marker (i.e., initiator = light envelope icon, receiver = shaded envelope icon).

In a multi-actor setting, the message, message direction, and message marker can identify the initiator or receiver. The tasks that possess the message notation correspond to CJML communication points. BPMN also models a human task (no communication), which directly corresponds to the CJML action. The AND and XOR operators are used in BPMN (Parallel and Exclusive gateway) and CJML (Concurrency and Decision Point), but BPMN provides more advanced gateway functions than these. BPMN also has advanced features, such as hierarchical decomposition, which enables BPMN to model subprocesses and collapse activities into choreographies. Finally, BPMN also models data objects. These advanced features are not part of the current CJML.

There are some examples of BPMN being used to model customer journeys [34, 69, 70]. For instance, the authors in [70] considered BPMN’s process metaphor (i.e., sequential flow) to represent customer journeys. However, they later changed from a process-driven metaphor to a case-driven metaphor using CMMN for simplicity [54]. In [69], the authors customized the BPMN notation to visualize a single customer journey instance. However, the language only captures the parts of the customer journey that relate to business processes (i.e., process-centered), as also stated in [64, 65].

CJML has always been user-centered and models touchpoints exclusively from the end-user’s viewpoint. These touchpoints could be digital (e.g., the customer orders through an app) or non-digital (e.g., the customer walks in a park). Also, BPMN does not distinguish among different communication channels and only provides a generic “message” notation, whereas CJML explicitly states the channel used. Today’s services allow end users and service owners to choose their preferred marketing channel, and this information is crucial for improving the quality of service. In addition, BPMN only provides a graphical notation for the process model. When BPMN is used to model the customer journey, it can only view the planned journey. The basic BPMN does not provide a graphical notation for each actual journey, as well as its deviations. Also, BPMN does not have journey-specific constructs such as journey phases, experience, channel, and actor information. Finally, CJML is intended for users without technical backgrounds and can be learned in one sitting. On the other hand, BPMN is a rich language that is intended for technical users (e.g., process analysts) and takes more time to learn [43, 71] relative to UML and CJML.

CMMN As BPMN is for business process management, CMMN is for case management [67]. CMMN provides a metamodel and graphical notation for expressing a case. It consists of tasks performed by a subject to achieve an intended result. These tasks can be performed in response to situations that may be unintended, hence, case-dependent solutions. Although CMMN aims to model cases, it can also be used to model customer journeys. In this scenario, the case subject becomes the end-user. In [54, 72], CMMN was used to model customer journeys by taking advantage of CMMN stages, events, and tasks. These stages are similar to CJML journey phases, though CMMN stages are not strictly ordered. The generalized journey stages in [54, 72] were derived from the Bagozzi purchasing model, which consists of unknown, desire, intention, implementation, trying, purchase, and feedback stages. In addition, CMMN events were used similarly to CJML touchpoints initiated by an end-user, while the CMMN tasks are similar to CJML communication points initiated by the service provider. Finally, the basic CMMN does not include the modeling of communication channels, but the authors in [54, 72] included multi-channel information using CMMN.

The main advantage of using CMMN is the explicit introduction of tasks on-the-fly to combat unintended scenarios during run-time, which is handy for the business analyst when introducing specific solutions. However, this also means that CMMN customer journey models do not have a structured flow. It opposes the essence of modeling customer journeys—a set of customer steps ordered in time. Also, similar to BPMN, CMMN can only visually model a planned journey and does not provide a visual notation for actual journey instances. In [54, 72], the planned journey is illustrated using the CMMN visual notation, but actual journeys are presented using only tables of data. Finally, the stages are intended for the cases of buying customers that end in purchase following the Bagozzi purchasing model [54, 72]. However, different models of journey stages that end in purchase also exist in the literature (e.g., [52, 53]). CJML is not limited to the predefined stages and can model any end-user journey (e.g., patient, employee, citizen), even those that do not necessarily end in a purchase.

UML Sequence Diagram (SD) The UML SD models a sequence of events that focuses on the entities and their message interaction [33]. It is specialized for viewing message exchanges between entities. The main functions include initial/reply messages, asynchronous/synchronous messages, and deleting messages. In modeling customer journeys, UML SD portrays the actors, their messages, and the interaction in a clear fashion. It is easy to point out the end-user using human stick figures and the end-user’s interaction among service providers. Finally, similar to CJML, UML SD is probably easier to learn compared to BPMN and other advanced languages due to its simple notation and less advanced features.

The main disadvantage of an SD is the lack of step information. It does not explicitly define the steps and only portrays the message that may relate to a step. For instance, BPMN clearly distinguishes the step and message labels through the sequence and message flow, respectively. Also, the SD lacks journey constructs such as channel information, journey phase, experience, and deviation.

UML activity diagram (AD) The UML AD is a behavior diagram that graphically represents the flow of actions involved in a use case. It is intended for modeling activity workflows and includes the data object flows relating to actions. An activity can express UML actions, which is an essential unit of behavior in UML [33]. Note that a UML action does not directly correspond to a CJML action. A UML action corresponds to a CJML action if it does not contain communication and is a user-centered step.

UML AD using swimlanes is the most suitable UML diagram to model business processes [65]. In modeling customer journeys, UML provides the steps ordered in time, but not necessarily from the end-user’s point of view. The swimlane diagram provides multi-actor information and the sequence arrows allow to point for the identification of the message sender (initiator) in case of communication. For the single-actor view, the message sender (initiator) uses the sender notation and the receiving action uses the receiver notation. Unlike SDs, ADs do not include the message content but can be passed in a UML note notation. The note symbol is used to convey messages not captured by the system. UML AD also provides concurrent and decision paths similar to CJML. In addition, data objects are explicitly modeled using the object notation and can be included in the sequence flow. Similar to SD, AD is simplified and reasonably easier to learn [43] than BPMN.

UML AD using swimlanes can potentially model customer journeys but has several limitations as also discussed in [65]. Similar to SD, it lacks journey-specific functions that are required to express customer journeys. It only shows actions in sequence flow, and crucial information, such as actor information, channel, journey phase, experience, and deviation, is missing. Unlike SD, an AD can provide a single-actor view, but the notation does not differentiate among multiple actors. An AD is also not intended to be used to view individual journeys, but it can be customized if needed.

From the discussion above, it is evident that CJML features different attributes than these GPMLs, as also described in Table 4. Research in the field has noted that there is no agreed-upon understanding of the basic components of a customer journey [24] and that there is a need to develop a customer journey modeling approach that allows for the participation of a broad audience in the creation process, especially those who have no prior experience in customer journey modeling [30]. This line of thought drives our work and serves as the reason why a UCD approach (described in Sect. 2) was applied. At the same time, this UCD approach gave CJML its individual qualities and attributes, and positioned it in a distinctive place in the domain of customer journey modeling. Finally, the comparison also reveals that there are certain features of GPMLs that are not yet supported by CJML, and their future integration would further enrich the CJML’s capabilities (described in the future work of Sect. 8).

8 Conclusion and future work

Although the customer journey literature has grown significantly in recent years, it appears incoherent and fragmented [24, 29]. A seminal paper on customer experience has called for an improved conceptualization of customer journeys [26]. In this paper, we have presented an artifact, CJML, that constitutes a new approach to customer journey methodology and consequently allows for the detailed and precise modeling of individual customer journeys and the comparison of these against the service delivery process as planned by the service delivery network. The inherent “outside-in” approach of CJML contrasts general-purpose modeling languages and may serve as a standardized lens for investigating the end-user’s perspective and associated experience.

In this work, we have described how this industry-relevant DSML was developed and systematically improved in close collaboration with the target group, using a mixed-method approach. Serving the overall research question, our experience has been generalized into lessons learned and methodological guidelines (Sect. 5). Through the case studies, we have exemplified how service providers may adopt CJML as a unifying language for purposes such as documentation (journey discovery), analysis (journey conformance), and service innovation (journey redesign).

In Case 1 (Sect. 4.1), we have shown how the abstract syntax and semantics of the touchpoint had to be changed to accommodate the established practice in the target group (RQ1). This accentuates the importance of controlled experiments for evaluating the usability of the basic constructs. Case 2 (Sect. 4.2) provided an example of how the syntax was expanded to cater to unpredictability in planned journeys (RQ2). In addition to journey discovery, this second case also encompassed journey conformance and journey redesign, which is elaborated further in [58]. In Case 3 (Sect. 4.3), a complex service setting with multiple actors elicited the need for a new diagram type (RQ3). Lastly, in Case 4 (Sect. 4.3) a second controlled experiment was conducted with target users to investigate the usability of the journey network diagram (RQ4). Again, involving target users inspired several valuable improvements in the concrete syntax.

CJML is available online [44] in the form of specification documents, design templates, and guidelines. CJML’s pursuit for improvement continues. Work is in progress to further extend and improve the metamodel and supporting material. Also, an XML interchange format will be available. We are also extending the expressiveness for actor modeling, distinguishing among end-user types and providing customized attributes (e.g., actor’s role, personal traits, and user preferences). Ongoing work in improving the visual notation includes extending the current limitations of the journey and network diagram (e.g., adding message flow notation, experience for the journey level, and data object notation). Finally, CJML envisions integrating features provided by GPMLs, e.g., data object, message modeling, and hierarchical decomposition.

From the conception of CJML, it has aided its users through design templates (Microsoft PowerPoint, Visio stencils) and haptic tools (whiteboard toolkits, magnetic paper, and paper templates with sticky notes). As the CJML target group is diverse, these low-threshold tools have been advantageous. We are currently developing and exploring tools for constructing and verifying diagrams. Here, we envision a tool that verifies the syntactic quality of the customer journeys constructed and checks if they adhere to the CJML syntax following the quality assurance guidelines and conventions in [73].

In a long-term perspective, work is in progress to adopt CJML toward the advent of the data age by developing formalism and tools to automatically capture actual journeys. This will enable model-based compliance analysis of actual journeys toward planned journeys. Process mining in combination with artificial intelligence opens possibilities to make predictions in real-time journeys and even to prescribe solutions to avoid service failure and customer dissatisfaction. The ultimate research challenge is how to structure a service delivery network to optimize the customer experience in response to such real-time intelligence.