Chris is a thirty-something, young urban professional who walks into her favourite grocery store where she usually shops. As she drops items in her shopping ...
A Development Framework for Customer Experience Management Applications: Principles and Case Study Imen Benzarti and Hafedh Mili LATECE Laboratory, University of Quebec at Montreal
Montreal (Quebec), Canada {benzarti.imen@courrier., hafedh.mili}@uqam.ca Abstract—Customer experience management (CEM) denotes a set of practices, processes, and tools that aim to personalize a customer's interactions with a company around the customer's needs and desires. This personalization depends on the purchase scenario at hand, and on how much a company knows about its customers. In turn, the purchase scenario depends, among other things, on the complexity of the product or service being offered (e.g., a carton of milk versus a house), and the complex set of motivations that can trigger a purchasing process. E-commerce software tool vendors need to provide the building blocks that enable retailers to configure and develop CEM functionalities that take into account these factors. In earlier work, we proposed such building blocks within the context of a CEM development framework that relies on a cognitive modeling of the purchasing process and identifies the touch points between seller and buyer and relevant influence factors. We envision a CEM scenario specification tool that enables business analysts to specify their purchase scenario, from which we generate data structures and algorithms to implement CEM functionalities by instantiating the framework. The framework is embodied in a set of ontologies and algorithm templates that can be instantiated with the specification parameters. In this paper, we present the principles behind our approach, and a prototype CEM scenario specification tool. We illustrate the tool with a moderately complex purchasing scenario, to validate the underlying theory, and to explore implementation strategies Keywords: CEM, intentional software.
I.
Customer behavior,
semantic
Web,
INTRODUCTION
Chris is a thirty-something, young urban professional who walks into her favourite grocery store where she usually shops. As she drops items in her shopping cart, the food labels are automatically displayed on her iPhone. As she drops a box of crackers, she gets a warning, because of its high-level of sodium - given her family history of blood pressure. She walks through the produce section, and gets notices about latest arrivals of fair trade certified products. She is pleased, of course, being an active member of Equiterre (an environmental organization). Walking into the meat section, her attention is drawn to a special on lamb chops that her significant other enjoys immensely. She picks a rack and drops it into the shopping cart. She gets wine suggestions: two thumbs up for a Syrah from northern Rhone, and one thumb up for a Merlot.
Cheese with that? A French baguette? In the seafood section, Chris picks a slab of tuna steak. She gets a warning to the effect of having consumed big fish already four times already this week (watch out for mercury!). While getting toothpaste, she gets an SMS about the special on size 4 diapers. See, she has been buying size 3 diapers for the past six months, and so she is due for size 4! Customer Experience Management (CEM) denotes a set of practices, processes, and tools that aim at personalizing a customer's interactions with a company around the customer's needs and desires [1]. This personalization depends on the type of service or product being offered, the type of customers that are being catered to, and how much a company knows about them. It is what makes the above shopping scenario possible. While the technical ingredients for implementing such scenarios are available (sensors, text messaging, predictive analytics, etc.), there is a crying need for: a) a methodology to help organizations (a food retailer in this case) design such applications, from business decisions to technology implementation, and b) software tools that e-commerce tool vendors can provide to help their customers (e.g., retailers) develop such applications. This is the problem that we propose to tackle in our work [2]. To solve this problem, we need to answer the following questions: Q1) what are the typical steps of a purchasing process, Q2) which of these steps require interactions between customers and companies, Q3) how to customize such interactions to customers' needs. In turn, Q3 leads to the questions: Q4) what data is needed for the customization, Q5) how to obtain that data, and Q6) how to deal with incomplete data. In [2], we proposed a purchasing process based on [3], answering Q1 and Q2. Factors influencing consumers' decision process are identified, answering Q3, Q4, and Q5 (partially). The steps at which those factors intervene determine opportunities for customization. They also embody consumer data that is needed to perform the customization [2]. We proposed ontologies for representing customer and product data, answering question Q4. We also explored strategies for obtaining consumer data and dealing with incomplete knowledge - answering Q5 and Q6. Finally, we outlined a process for developing CEM applications using the above artifacts [2]. In this paper, we propose to validate the framework described in [2] on a case study. Our framework for customer experience management is
summarized in section 2 where we present: a) a customer experience management pattern that shows how to translate the behavioral model into CEM functionalities, and b) ontologies for implementing CEM functionalities. For our case study (section 3) we chose the purchase of a bicycle, because it represents a moderately complex purchase that is part utilitarian (as a mode of transportation), and part socalled lifestyle purchase (sport) which is usually sensitive to various subjective factors. The application of our framework to the case study is shown in section 4. The implementation is discussed in section 5. We conclude in section 6. II.
TOWARD A FRAMEWORK FOR CUSTOMER EXPERIENCE MANAGEMENT
A. A customer experience management pattern Customer Experience Management (CEM) aims to manage the interactions between a consumer and a provider, each executing their own 'processes,' and pursuing their own objectives. Customers are "dynamic systems" whose internal processes (stay alive, pursue happiness, etc.) require a number of resources (food, transportation) or states (fulfillment, happiness, etc.), triggering consumption processes to replenish the resources ("we are out of milk") or to attain those states ("I need to be entertained"). Similarly, commercial enterprises are "dynamic systems" that build products that they need to sell to consumers. The purchasing 'experience' is where the consumer's purchasing process meets the enterprise's selling process. To properly manage this experience, an enterprise needs to answer at least the following questions: 1. What are the different steps of the customer purchasing process? 2. In particular, at what point does the prospective customer make a decision to: a) want to purchase a particular product type (e.g., buying a bicycle), and b) select the specific combination? 3. Which factors influence those decisions? 4. At what point does the customer interact with the enterprise? 5. Can the knowledge of those influence factors be used to customize those interactions? 6. To what extent can the enterprise use those factors to its advantage? To answer the first three questions, we rely on a psychological modeling of purchasing process. Indeed, consumer behavior has been studied thoroughly by social psychologists trying to understand its mechanics [3] [4] [5]. The different theories recognize that purchasing decisions are determined by a combination of objective/rational factors such as the ability of a product to fulfill a biological need, and subjective/irrational factors such as self-image (e.g. being fashionable), and personal values (e.g. promoting fair trade). Bagozzi [3] proposed a model that integrates all of the influences that have been identified by researchers. The model presents steps of the purchasing process and the
influence factors that act on each step. There are different paths through this process, depending on the type and complexity of consumption decisions. For example, habitual or low-risk consumption activities (e.g. grabbing a carton of milk) involve neither deliberation nor planning, whereas more complex purchasing decisions (e.g. buying a computer or a car) do. In [2] we gave more details on Bagozzi’s model. We described different steps of the process for reaching the goal of purchasing, starting from goal desire when we recognize the need, to the purchase-planning step until the goal attainment and feedback step. In addition, we explained different influence factors like emotions, attitudes, subjective norms, etc. To answer the last three questions, we established a set of interpretations of the psychological model. Fig. 1 shows how this knowledge can be used to answer the last three questions. It illustrates the following challenges: ● Some steps do not involve an interaction with the enterprise (step i). For those that do, the interaction can be initiated by the consumer (e.g. visiting a store/web site) or by the enterprise (e.g. cold calling). ● The influence factors embody data about the customer ● The enterprise benefits from "reading" the "value" of the factors that influence the steps of the process (steps i-1 and i+1). In the CEM scenario of the introduction, knowledge of Chris's 'second order moral values' (a fair trader) was used to push specific products. ● Some influence factors may be modifiable by the enterprise (step i+1); e.g., well-designed and targeted advertising can enhance the desirability of a product. To properly apply the pattern of Fig. 1 to the various steps, we need to: 1. Analyze the different types of factors, to determine whether they can be “read” or “modified”. In [2], we identified two dimensions: a) object (about the customer, the product, or the relationship between the two), and b) type (objective, and hence immutable vs. subjective and hence possibly malleable). 2. Analyze the different types of process steps to see
Figure 1 Towards a systematic view of customer experience management.
whether they lend themselves to customizable interactions. In [2], we identified three types: a) purely cognitive steps, which happen inside the customer's head, b) external steps that normally involve interaction with the seller, and c) external steps that do not normally involve interactions with the seller. B. Ontologies for customer experience management In this section, we focus on formalizing our knowledge about the consumers and products in a way that supports the customization of their interactions with the enterprise. We present the required knowledge models in the form of ontologies. We used the term ontology in two complementary ways: 1. We use it in the computer science/information systems sense, i.e. as specification of a set of representational primitives used to represent a domain of knowledge [6]. 2. We also use in the sense of reflecting a shared conceptualization of a domain. Consumer Data Knowing the consumer is key to a successful CEM. As mentioned in section II.A, the influence factors that are relevant to the consumption process steps represent information that consumers use to make their choices and reach their decisions. This information can be used by an enterprise to: 1) identify those among its products that best address the needs and desires of those customers, and 2) position those products in a way that appeals to those customers, considering their (known) attitudes, biases, emotions, and values. Fig. 2 shows the customer profile ontology. Starting with the upper half, it shows that consumers have properties (HasCustomerProperty) as data property of class Customer. Consumers belong to Categories (the class customerCategory). Thus, a customer shares some properties with members of categories to which he belongs. These properties are used to describe or to infer a part of the data about the customer. For example, we may have no value for the PreferredTransportationMode property for a customer, but because s/he is a member of a socially responsible consumer category, we can infer that they prefer public transportation. The properties of a category of customers are represented by the data property hasCustomerCategoryProperty. Similar to the concept of Category, we have the concept of State. A consumer can be in different states, which correspond to qualitatively different consumption behavior, in terms of needs, attitudes, and the like. This accounts for the family life-cycle theory, where states represent life-cycle stages [7]. State-Transitions are triggered by events (EventType), which can be property change events. (PropertyChangeEventType), as in getting married, or timer events (TimerEventType), as in going from size 3 diapers to a size 4 diapers after a fixed number of months.
Figure 2 A customer profile ontology
Product Data To take full advantage of our knowledge about the consumer, we need a 'comparably rich' representation of the products and services sold by the company. Product modeling is commonly multilayer, where we distinguish, the category of the product, model of the product and the physical item (see e.g. [8] [9]). Fig. 3 illustrates our representation of products. In the same way that consumers are grouped in categories, products belong to categories. Each product category is characterized by a set of category properties (hasCategoryProperty). Product models (ProductModel class) that belong to a category share a set of properties with other product models of the same category, in addition to having specific properties (hasProductProperty) like brand or price. Product items (ProductItem class) are individual instances of a product model, i.e. the actual items that consumers purchase. Items have instance properties (hasItemProperty) like serial number or warehouse location. Note that the consumer and product ontologies have several levels of instantiation. This means that we need to treat classes of one level as instances of the level above it. Only OWL Full, which is the most expressive of the semantic Web ontology languages, supports this. However, OWL Full is undecidable [10]. Many researchers have attempted to represent several levels of instantiation in OWL (basic). There are two general approaches. The first one extends OWL by adding new axioms and taxonomy to support metamodeling. In [11], an extension of OWL for metamodeling is proposed that defines new axioms that equate classes and individuals that describes the same concepts. In [12], the problem is addressed by defining new relation types as isPowertypeOf or specifies. The second family of approaches represents class objects as individuals. In [13], e.g., the authors adapt ideas from conceptual modeling to ontology engineering by mapping m-objects to OWL. An m-object embodies an abstraction level by: a) specifying concrete values for the properties of the level above it, and b) describing properties that are common to the levels below it.
Figure 3 Product representation for CEM functionalities
Our approach sort of combines the two approaches by applying the Zig-Zag pattern [14] on OWL. The Zig-Zag pattern allows several levels of instantiation. We describe class objects using regular instance objects, which allow us to go up an additional instantiation level. A meta class instance (e.g. a product category instance) points to a class instance (e.g. a product instance) through an object property called “describes”, and a class instance points back to a meta class instance through an object property called “described by”. III.
CASE STUDY: BUYING A BICYCLE
To validate our general approach, we apply it to a case study involving a specific purchasing scenario. While the purchasing process model in [4] can handle any purchasing scenario, we should focus on a process of medium complexity - somewhere between buying a carton of milk and buying a house - to get the opportunity to exercise the different parts of the framework, without getting overwhelmed with details. We chose the purchase of entrylevel/mid-range bicycles, which involves non-trivial problem solving steps, and which combines a utilitarian function (as a mode of transportation) and a lifestyle need which is more amenable to subjective factors. We distinguish three categories of bicycles: 1) hybrid bicycles, for everyday use, the urban bicycle that are used to move around the city are a subcategory of hybrid bicycle. 2) road bicycles, to travel long distances or for road racing and 3) mountain bicycles, for sporting excursions on rugged terrain. The kind of bicycle a customer needs depends on what they do with it. We recognize three categories of customers: 1) Performance Plus customers: customers who choose performance over comfort for their bicycle; they prefer lightweight bicycles that allow them to reach maximum speed on roads, 2) Comfort Plus customers: customers who choose comfort over performance, because they use the bicycle in trails or for long distance, and 3) Utility Plus customers: customers who look for the balance between comfort and speed. They are interested in bicycles for moving, shopping and exercising. IV. CEM FRAMEWORK CONFIGURATION AND INSTANTIATION FOR A SPECIFIC PURCHASE SCENARIO In [2], we proposed a procedure for 'instantiating' our framework for a specific purchasing scenario, consisting of: 1. Specifying the purchase scenario by the customer experience (CE) designer: selecting the steps and influence factors that are relevant to the scenario, 2. Building the relevant data schemas: instantiating CEM ontologies shown in section II.B to create scenariospecific data models, 3. Generic functionality instantiation: instantiating generic CEM algorithms to create scenario-specific CEM
algorithms. As mentioned in section I, we plan to develop tools that CE designers (business analysts, marketing specialists) can use to specify their CEM scenario, from which we can configure or generate software artifacts that implement the scenario. For the time being, we focus on: 1) specifying the purchase scenario (section IV.A), 2) instantiating CEM ontologies based on such a specification (section IV.1)), 3) building data models by generating database schemas (section IV.B.2)), and 4) instantiating generic CEM algorithms using scenario-specific ontologies/databases (section IV.C). These steps help illustrate—and validate—the general approach, the models, and the algorithms on a concrete scenario. A. Specification Step: specifying the purchase scenario 1) Selecting steps and influence factors The purpose of this step is to select, among the steps and influence factors shown in the generic process model of [2], those that apply to the purchase of a bicycle. The result is shown in Fig. 4. Note for a given step in Fig. 4, we did not keep all of the influence factors identified in [2] for the same step. The reason being that while they may all be relevant, only a subset maybe salient, i.e., likely to make a difference, for a/this particular purchasing scenario. We will comment below on the steps and influence factors. Forming the intention of purchase: this step combines the steps “goal desire” and “goal intention” (see distinction in [2]), where the goal is to own a bicycle (an end state), for whatever purpose the customer desires. The salient influence factors for this step are: 1) anticipated positive/negative emotions, i.e. how it would feel to own, or fail to own, a bicycle (the joy of cycling, fitness, etc.), 2) social identity, i.e. how a consumer perceive her/himself (athletic, urban, environmentally conscious, etc.), depending on the type of bicycle, and 3) frequency of past behavior, i.e. how often the customer buys new bicycles. We dismissed the following factors: 1) feasibility, because we felt that given the price range for an entry/medium level bicycle, this is probably not an issue, and 2) outcome expectancy, because there are no “obstacles” to buying bicycles, again given their price range. Planning the purchase. This corresponds to 'implementation intention' step in [2]. The plan will be more or less elaborate, depending on how often the customer purchases bicycles. An experienced cyclist will have a clear list of retailers to visit, and models to check. The salient factors are frequency of past behavior and second-order moral values and self-evaluative standards. Such moral values may influence the choice of the manufacturer based on origin (e.g., buying local), or labor practices (e.g., child labor), etc.
properties of categories and customers. Properties like usage or emotions are category properties whereas properties like name or address are properties of customers (see Table 1). 4) The initialization of property types according to the selected influence factors. In the first step of the specification, the CE designer selects a subset of the relevant influence factors. In a subsequent step of the specification, the CE designer defines the properties of products and customers. At this stage of the specification, the framework defines influence factors as property types. Figure 4 Steps and influence factors selection for the bicycle purchase scenario.
Trying to execute the plan: this corresponds to the 'trying' step in [2]. The customer executes the shopping plan (visiting stores, evaluating bicycles, checking online customer feedback, etc.). At the end of this step, the customer will have identified the bicycle to purchase. This step is influenced by frequency of past behavior. Purchasing: this corresponds to the goal-directed behavior in [2]. It is influenced by frequency and recency of past behavior. Use and Feedback: The feedback can be about the shopping experience or the product itself. 2) Product configuration: General description of the product: The purpose of this step is to describe the product and its properties. For each property, the CE designer defines the name and the value type. In the case of bicycles, we have properties like number of speeds (type: integer) and handlebar (type: {flat, drop}), etc. Some properties are common to all products. We suggest predetermining these properties by default; such properties can be the functions or the price of a product. Levels of instantiation of product descriptions The first level is the product category as in the category of ‘hybrid bicycles’. The second level is the product model (e.g., Grant Hybrid Bicycle 2017) and the third level is the product item (e.g., John’s Grant Hybrid Bicycle 2017).
In turn, the CE designer: 1) assigns certain category properties to influence factors, and 2) defines associations between customer category properties and product category properties of the same type. Association properties represent semantic joins between product categories and customer categories. For example, we can associate the (bicycle) use property of customer categories with the function property of product categories (see Table 1). B. Instantiation Step 1) Ontology Instantiation: CEM ontologies are instantiated according to the CE designer specification. The resulting instance is an ontology that is specific to the purchase scenario. Fig. 5 illustrates the instantiation of the products ontology for the bicycle purchase scenario. Customer categories and product categories defined in the specification are defined as subclasses (using the relation rdfs:subclasseof) of, respectively, the classes CustomerCategory and ProductCategory. Product models and items are subclasses of the classes Product and ProductItem, respectively. Product properties defined in the specification are defined as data properties in the ontology according to the ranges specified by the CE designer. Fig. 6 illustrates how we create the hierarchy of bicycle categories properties. This consists of defining two levels of inheritance (subDataProperty), in the first level we define the properties with their possible ranges of values. When descending from an inheritance level, restrictions are applied to the properties according to the characteristics of the category.
The CE designer provides a description of the three levels of instantiation by defining applicable properties to each level. In our scenario, the property handlebar configuration is assigned to the product category level, the price property is assigned to the product model level, and the serial number is assigned to the product instance level (see Table 1). 3) Customer configuration The configuration of customers is similar to the configuration of products. The CE designer specifies the Figure 5 CEM Product ontology instantiation.
Table 1 Example of CE designer specification for the scenario of purchasing a bicycle Steps Goal desire, Goal intention, Implementation intention, Trying Influence factors:Anticipated Emotions, Social identity, Frequency and Goal directed behavior recency of past behavior Product Specification Customer specification Categories usage: (sport, racing sport) Categories Bicycle: wheels diameters (double) comfort: (low) handlebar configuration (drop, flat) UtilityPlus: efficiency: (high) usage (string) function: (sport, transport) Mountain: super category (bicycle) comfort: (high, medium, low) comfort: (medium) wheels diameters (700mm) PerformancePlus: comfort: (high) handlebar configuration (flat) function: (sport, racing sport) efficiency: (low) usage: (sport, transport) comfort: (high) Road: super category (bicycle) comfort: (medium) efficiency: (low) wheels diameters (>700mm) ComfortPlus: efficiency: (medium) handlebar configuration (drop) function: (sport, mountain sport) Urban: super category (Hybrid) usage: (sport, racing sport) comfort: (low) wheels diameters (>700mm) comfort: (low) efficiency: (high) handlebar configuration (drop) efficiency: (high) Model: Price: double Item: Color: String Customer: name: string e-mail: string Brand: string Serial number: String address: string phone: string Property type matching Property type: Emotions type: Customer property: comfort Product property: comfort Customer property: efficiency Product property: efficiency Property type: UsageType: Customer property: usage Product property: function Property type: SocialIdentityType: Customer property: usage Product property: social Identity
2)
Generating the database schemas
The database is generated by parsing of the generic ontology and the scenario-specific ontology. Generating categories: Fig. 7 shows how we generate product category tables. The tables of categories of products and categories of customers will define the ranges of properties of each category. The table’s columns are the direct sub-data properties of the data property hasCategoryProperty. Thus, the data properties “wheel diameters,” “handlebarconfigurations,” and “suspension” in Fig. 7 are columns of the product categories table. Using the second level of the inheritance of data properties, which defines the ranges of properties for categories, we insert the different rows in the database. Each row describes a category and its corresponding values range. Generating the tables of products and customers: In section II.B, we showed how we use the zig-zag pattern to build our ontology and that the use of this pattern allowed us to model several levels of instantiation in the same ontology. Fig. 8 illustrates how we use the relation “describes” to generate the table of products which holds information about product models. A product model has some specific properties like price or brand, but also it has information described by the category of products to which it belongs. To fill information about the product in the database we need two individuals: an individual "A" that instantiates the category to which the product belongs and another individual "B" that instantiates the product itself. Individuals are bound by the relations “describes” and
“described by.” The tables of customers are generated by following the same principles. Generating items: the generation of the product items table is performed in the same way as the generation of the products table. However, we use the relation “describes” between product model and product Item. C. Instantiating algorithms The first question that we had to address is: how do we represent a CEM algorithm (e.g. a recommendation algorithm) generically, without referring to a (purchasing scenario-)_specific data model? For example, a recommendation algorithm for bicycles might match the function of a bicycle category with the intended use of the bicycle by a customer of a particular category. But how do we represent such an algorithm generically, knowing the properties function and use are both scenario-specific? The general idea is to specify the algorithm in a way that it refers to properties that satisfy certain properties, themselves, as opposed to named properties. Put another way, the recommendation algorithm will compare properties
Figure 6 Hierarchy of products properties.
Figure 7. The generation of the product categories table.
specified intensionally (in terms of properties they themselves satisfy), as opposed to extensionally, i.e. by naming them. This is actually an example of intensional programming described in [15]. . We apply the same principle of ontology instantiation on CEM algorithms (see Fig. 9). The algorithms are defined intentionally, and at the instantiation of the framework for a specific scenario, the corresponding extensional algorithm is generated according to the CE designer’s configuration. Fig. 9 shows the algorithm instantiation process for a simple recommendation algorithm. Based on the CE designer’s specification, the code generator verifies two conditions: 1) the customer property and the product property have the same type of property and 2) they are associated and look for intersection of values between the two properties. As of a certain predefined threshold, the product is recommended. Afterwards, it generates an extensional algorithm by replacing the categories by individuals and the property types by concrete properties. V.
IMPLEMENTATION
A. Lessons learned from the case study Our CEM development framework allows CE designer to specify a specific purchase scenario and to transform that specification into software specifications in the form of data structures and algorithms that implement CEM Intentional recommendation algorithm input: PC a product category input: PCP a product category property input: CC a customer category input: CCP customer category property input: threshold a recommendation threshold;
➔
if (PCP.getType() = CCP.getType() and isAssociatedTo (PCP,CCP)) then if (value(PCP(PC))∧value(CCP(CC)) ≥ threshold × value(CCP(CC)) then add PC to recommendations of CC
Figure 8 The generation of the table of products.
functionalities. Our approach consists of: 1) instantiating generic domain models (CEM ontologies), and 2) instantiating parameterized CEM functions into scenariospecific algorithms. It is a generative approach. To the extent that the specific CEM application generated depends on the intention of the expert, the encoding of CEM functionalities embodied in our framework can be seen as intentional software. Intentional software separates the software content, which differs from one domain to another, from the implementation of the software, which is generic, thereby enabling the generation of the software based on the description of the content provided by an expert [15]. Intentional software relies on a domain schema, domain code, and generative programming [15]. The domain schema which defines intentionally each concept of the domain, the domain code consists of the specification of the CE designer, it’s the domain specific language (DSL) [16] and the generative programming which consists of designing and implementing generator programs that take input like a domain code and generate a target code [17]. Fig. 10 illustrates how we apply the principles of intentional software in our development framework. The domain schemas correspond to the “generic” CEM ontologies; the
Code generator
+ Analyst specification
➔Extensional recommendation algorithm input: bicycle a bicycle model input: customer a customer if (bicycle.function ∧ customer.usage ≥ 0.5 × customer.usage then add bicycle to recommendations of customer
Figure 9 Extensional algorithm generation according to generic algorithm and CE designer specification.
domain code corresponds to the “specific” CEM ontologies. In addition, the framework provides the following elements: • The specific ontology generator: that instantiates the CEM ontologies (see section IV.B.1), • The database generator: it instantiates data models (see section IV.B.2)) and • The code generator: it instantiates intentional CEM algorithms of the framework (see section IV.C). B. Proof of Concept: We implemented some parts of the framework as a prototype. The configuration step is done manually on the tool Protégé (5.2.0), an ontology editor (http://protege.stanford.edu/). We implemented the database generators (see Fig. 7 and Fig. 8). We used OWL API 5.1.0 (http://owlapi.sourceforge.net/) a reference java api for creating, manipulating and serializing OWL ontologies and Hermit reasoner (1.3.8) to deduce inferences from the specific and the generic ontologies. In addition, we implemented the recommendation generic algorithm that manipulates concepts from the generic ontology and a generation algorithm that instantiates the generic algorithm according to specification, and then it generates a database table of three columns: customer category ID, product category ID, and binary: recommend or not. The prototype must be further developed by adding more code generators and a user-friendly graphical interface for entering the scenario specification. VI.
CONCLUSION AND FUTURE WORK
CEM has been thoroughly studied in the literature from marketing, management, social psychology, and different angles of computer science or engineering (usability, ubiquitous computing, context-aware applications), but mostly in a silo fashion. We believe that all of these disciplines have something to contribute in the successful design and implementation of CEM functionality. We proposed a CEM development framework in [2], which incorporated some of these disciplines, but left many conceptual gaps and unanswered questions. This is a first attempt at filling some of the gaps and answering some of the questions through a case study. We focused on the content of the specification of the purchase scenario and how to transform this specification to data models and algorithms. Much work remains to be done, both at the theoretical level (e.g., guessing the progression of a customer within a purchasing process, a more systematic 'consumer scripting' through better integration with service design [18], etc.), and tool development level like algorithms code generators and graphical interface to configure the framework.
Figure 10 CEM framework components
REFERENCES [1] Walker B, The emergence of Customer Experience Management solutions. For eBusiness& Channel Strategy Professionals.: Forrester, 2011. [2] Mili H et al., "Context Aware Customer Experience Management: A Development Framework Based on Ontologies and Computational Intelligence," In Sentiment Analysis and Ontology Engineering, pp. 273-311, 2016. [3] Bagozzi R P, Gurhan-Canli Z, and Priester J, The Social Psychology of Consumer Behavior.: Open University Press, 2002. [4] Bagozzi R P and Warshaw P R, "Trying to consume," Journal of consumer research, vol. 17, no. 2, pp. 127-140, 1990. [5] Ajzen I, From intentions to actions: A theory of planned behavior.: Springer, 1985. [6] Gruber T, "Ontology," Encyclopedia of database systems, pp. 19631965, 2009. [7] Browning M and Crossley T F, "The life-cycle model of consumption and saving," The Journal of Economic Perspectives, vol. 15, no. 3, pp. 3-22, 2001. [8] Lee J H et al., "A semantic product modeling framework and its application to behavior evaluation," IEEE Transactions on Automation Science and Engineering, vol. 9, no. 1, pp. 110-123, 2012. [9] Bock C, Zha X, Suh H W, and Lee H J, "Ontological product modeling for collaborative design," Advanced Engineering Informatics, vol. 24, no. 4, pp. 510-524, 2010. [10] Motik B, "On the properties of metamodeling in OWL," Journal of Logic and Computation, vol. 17, no. 4, pp. 617-637, 2007. [11] Motz R, Rohrer E, Severi P, and Vidal I, "OWL Extended with Metamodelling," ISW-LOD@ IBERAMIA, pp. 55-60, 2016. [12] Brasileiro F, Almeida J P A, Carvalho, V. A. V A, and Guizzardi G, "Expressive Multi-level Modeling for the Semantic Web," International Semantic Web Conference, pp. 53-69, October 2016. [13] Neumayr B and Schrefl M, "Multi-level conceptual modeling and owl," International Conference on Conceptual Modeling, pp. 189-199, November 2009. [14] Mili H and Pachet F. “Metamodeling for Multidimensional Reuse,” The 2000 Maghrebian Conference on Soft. Eng. and AI, pp. 29-39, Nov. 13, 2000 [15] Simonyi C, Christerson M, and Clifford S, "Intentional software," ACM SIGPLAN Notices, vol. 41, no. 10, pp. 451-464, October 2006. [16] Mernik M, Heering J, and Sloane A, "When and How to Develop Domain Specific Languages," ACM Computing Surveys, vol. 37, no. 4, December 2005. [17] Czarnecki K, Østerbye K, and Völter M, "Generative programming," ECOOP Workshops, vol. 2002, pp. 15-29, June 2002. [18] Teixeira J, Patrício, N J, Nunes L, Nóbrega L, Fisk R P, and Constantine L, "Customer experience modeling: from customer experience to service design.," Journal of Service Management, vol. 23, no. 3, pp. 362-376, 2012.
