A Comparison of Concepts in Service Blueprinting and Process-Chain-Network ( PCN )

Service blueprinting has been used for over 30 years as a service process visualization technique. A new service process visualization technique called Process-Chain-Network (PCN) has been recently introduced and is claimed to be an improvement on previous visualization methods. We use the method of conceptual evaluation to compare and explore the similarities and differences between the concepts in service blueprinting and the concepts in PCN. Specifically, we aim to answer two research questions: 1) how well do PCN concepts support service blueprinting concepts? and 2) how well do service blueprinting concepts support PCN concepts? The results of this study show that these modeling formalisms have different views towards the categorization of service activities. We conclude that whilst service blueprinting depicts business roles and their interactions with a customer, PCN focuses on the nature of interaction between customer and service provider. Moreover, we find that PCN is a better method for process re-engineering in comparison with service blueprinting, both modelings supporting customer experience to some degree.


Introduction
A century ago, most of the people around the world were working in farms (Chesbrough & Spohrer, 2006).However, the rise of new technologies during the past century caused a shift of employment from manufacturing into knowledge intensive service industries (Chesbrough & Spohrer, 2006).Today, the service sector is the largest part of all economic activities in industrialized countries (Spohrer & Maglio, 2010).Vargo and Lusch (2004, p. 2) define services as "the application of specialized competences (knowledge and skills) through deeds, processes, and performances for the benefit of another entity or the entity itself".
Company strategies to survive in a hyper competitive global economy and gain operational excellence have led them to invest in service innovation and design (Rai & Sambamurthy, 2006).Service design has a major impact on service delivery costs, customer satisfaction, and loyalty (Ostrom et al., 2010).In fact, providing a high quality customer experience plays an important role in service design and innovation (Calabrese & Corbò, 2014).
Service blueprinting was developed over 30 years ago by Shostack (1982) as a method to visualize a service process from the point of view of the customer.Service blueprinting is a first generation process-based approach for service design (Bitner, Ostrom, & Morgan, 2008).Service marketers and practitioners employed the service blueprinting method to depict the sequence of service activities and tasks in a dynamic manner (Hara & Arai, 2011).The critical touch points between the customer and service provider, hidden support, management activities in different layers of the organization, and all physical evidences seen by customers are represented in a service blueprint.Service blueprinting is used by business consultants and information architects for business process modeling and documentation (Glushko & Tabas, 2009;McKenna, 2000).
Process-Chain-Network (PCN) is a new service visualization technique, introduced by Sampson (2011Sampson ( , 2012bSampson ( , 2012a) ) to provide a balanced view of the interaction between customer and service provider.Specifically, PCN considers service as a type of resource/process configuration.Sampson (2012a, p. 17) claims "PCN diagrams build on the strengths of other flowcharting techniques, while emphasizing the unique conditions and design opportunities for interactive service processes".
The aim of this study is to compare and explore the similarities and differences in concepts of these two modeling methods.By doing so, we can understand how these models can be used in tandem.In addition, understanding similarities and differences between concepts of these models can facilitate the process of mapping from one model to another.Therefore, the main research question is as defined as below: What are the similarities and differences between the concepts in service blueprinting with the concepts in PCN?
To find the answer to the above question, we must first answer two subordinate research questions: 1) How well do PCN concepts support service blueprinting concepts?
2) How well do service blueprinting concepts support PCN concepts?
Current research utilizes the method of conceptual evaluation (Milton & Kazmierczak, 2004) to answer each of these subordinate questions and finally the main question.The method of conceptual evaluation is used in this study as it was the only method we found in the service science literature for conducting a comparison of this nature.This method was employed for the first time in service science by Milton and Johnson (2012) to study how business process modeling notation (BPMN) conceptually supports service blueprinting.Later, we (in press-b) used this method to understand how PCN conceptually supports service blueprinting.However, this paper employs a new version of this method to conduct a more rigorous comparison between these two modelling formalisms.Specifically, we (in press, 2015) introduced the new version of the method of conceptual evaluation to reduce the subjectivity of it.This paper continues with describing this research method, and then service blueprinting and PCN are described in detail.The next sections are dedicated to the conceptual evaluation of PCN against service blueprinting and the conceptual evaluation of service blueprinting against PCN.Following that, findings from these evaluations and conclusions are presented.The paper concludes with research limitation and future work.

Research Method
Firstly, let us define A and B as two different process modeling formalisms being studied.In comparing these two process modeling formalisms, the steps are described as follows: Step 1. Determine the concepts of A. The concepts of A are <a1>, <a2>, … , <an>.
Step 3. Perform a conceptual evaluation of B against A. Therefore, concepts from A will be taken in comparison to concepts from B, utilizing semiotic theories in order to do this.Milton and Kazmierczak (2004, p.30) believe that there are two reasons for using semiotic theories to provide comparisons between concepts: "Firstly, terms and concepts are clearly semiotically related.Secondly, comparison of concepts is semantic with semiotic theory providing an ideal basis for explaining semantic differences in terms."Specifically, concepts "span parts of a semantic field (Eco, 1976), or conceptual plane (Cruse, 2000, Culler, 1976).Alternatively, each term possesses an essential depth (Liska, 1996) which similarly evokes the conceptual span of a term" (Milton & Kazmierczak, 2004, p. 30).As a matter of fact, when comparing two concepts that come from two different process modeling formalisms, we actually are comparing the similarities and differences of the "semantic field" associated with each concept.
We define three categories of the results when we compare <ai> (i = 1 … n) with concepts from B: full respective coverage of the semantic field, partial respective coverage of the semantic field and no coverage of the semantic field.When the semantic field covered by concept <ai> fully overlaps with the semantic field of one or a combination of more than one concepts from B, we call this full coverage.Similarly, partial overlap between the semantic field covered by concept <ai> can be from one or a combination of more than one concepts from B. No overlap is where there is no coverage by B at all for the concept <ai>.Firstly, it is necessary to examine whether or not there is total overlap between the semantic field of <ai> and the concepts from B. If no such total overlap is found, we look for partial overlap.
Importantly, a simple concept or a minimal combination of concepts from B covering the maximum semantic field is chosen.This simple or minimal combination of concepts is called a 'supportive concept'.For example, together, as a supportive concept, the concept(s) <bi'>, … , <bj'> (0 < i' j' m) from B, may provide partial or full coverage of the semantic field for the concept <ai>.For ease of expression, the supportive concept is shown as <bi' + … + bj'> (during discussion we used the word 'plus' instead of '+').
If there is no coverage from B of the semantic field for the concept <ai>, then Si(B) = {Ø}.

 p 
Figure 1.Degree of overlap in coverage of semantic field for <ai> by Si(B) Figure 1 provides us with a diagrammatical representation of the explained three categories of results for the coverage of <ai> by Si(B).In this figure, the three symbols (), (p), and (), are used for full, partial, and no coverage respectively.These symbols are used in results tables later in the paper.
Step 4. Almost identical to step 3, however this time dedicated to a conceptual evaluation of A against B.

Service Blueprinting
A service blueprint consists of two dimensions (Fließ & Kleinaltenkamp, 2004, p. 396): "the horizontal axis represents the chronology of actions conducted by the service customer and service provider.The vertical axis distinguishes between different areas of actions.These areas of actions are separated by different "lines:"".An action is the work that was done by an actor.The sequence of actions by an actor is called action flow.A communication flow presents the sequence of actions between two actors.The things which affect customer's service perception are called props and physical evidence (Bitner et al., 2008).
Figure 2 presents a service blueprint for a hotel stay.As the figure indicates, all props and actions are illustrated with boxes.There are five actors in a service blueprint: customer, onstage employees, backstage employees (or systems), support, and management.Four lines are separating these actors and their actions.These lines are (Bitner et al., 2008): Line of interaction: separates customer actions from onstage and backstage actions; Line of visibility: separates the actions of onstage employees from backstage actions; Line of internal interaction: separates the actions of backstage employees (or systems) from support actions; Line of implementation: separates support actions from managerial actions.
In addition to these lines, Fließ and Kleinaltenkamp (2004) added another line: Line of order penetration: separates customer induced actions from customer independent actions.
Customer induced actions are affected by customer actions, goods, and information.Customer independent actions does not involve customer actions, or his/her properties (Fließ & Kleinaltenkamp).The steps of building a blueprint are (Zeithaml, Bitner, & Gremler, 2006): 1) Defining the target service process;  <Environmental Conditions Label> An Environmental Conditions Label used to label the process steps where there is a physical evidence seen by customer.
Note.Definitions from Sampson (2012a).The following paragraphs utilizing semiotic theories discuss and justify these results in detail.

Conceptual Evaluation of PCN against Service Blueprinting
We explain the nature of the gaps according to the represented order of concepts in Table 3.
An <Action> is defined in service blueprinting as the job performed by an actor.A <Process Step> also is the work done by involved entities in a service process.An <Action> can be defined simply (e.g., assemble pizza) or can be described in detail (e.g., the sequential steps of assembling pizza).In a similar way, a <Process Step> can be simple or complex.The concept of <Process Step> in PCN supports the concept of <Action> in service blueprinting.
Service blueprinting identifies five categories of actions: customer action, onstage action, backstage action, support action and management action.PCN diagrams identify the customer as a <Process Entity> and the customer <Process Domain> which consists of customer process steps.Thus PCN supports customer actor from service blueprinting.The four other actors are not defined in PCN diagrams (onstage employees, backstage employees, and support personnel).The main reason is because PCN categorizes process steps based on whether they involve another participant entity and they are interactive or not, rather than the performer of a process step.Consequently, the semantic field of both <Process Entity> and <Process Domain> are needed from PCN to partly cover <Actor Categories> from service blueprinting.We know from the research design section that we can make a supportive concept by using the word "plus" between the names of two concepts.In this case, we can say that the supportive concept of <Process Entity plus Process Domain> in PCN partially covers <Actor Categories> in service blueprinting.
An <Action Flow> indicates the order of actions by an actor in a service blueprint.A <Communication Flow> shows communication between actions of different actors.In comparison, Sampson (2012b) highlights that an <Arrow> in a PCN diagram shows the state of movement of goods and / or information like arrows in a supply chain diagram.He continues that an <Arrow> can illustrate a movement of goods and / or information like arrows in a supply chain diagram.We explained above that the concept of <Process Step> in PCN supports the concept of <Action> in service blueprinting.An <Arrow> in PCN does not differentiate whether connected actions are done by one actor or each of them are done by a different actor.Therefore, <Arrow> fully covers both <Action Flow> and <Communication Flow>.
One of the most critical parts of service blueprinting is the <Line of Interaction>.The <Line of Interaction> defines the interface between the customer and frontline employees.Since service blueprinting is based on the customer view, the interaction between customer and frontline employee plays an important role in this model.Bitner et.al. (2008, p. 72) states that "every time the line of interaction is crossed via a link from the customer to a contact employee (or company self-service technology), a moment of truth has occurred."Moments of truth affect customer perceptions of the delivered service.In other words, the frontline of a company has a major impact on customer satisfaction.In a PCN diagram, <Process Entity> and <Process Domain> together can be utilized to categorize customer process steps, but we cannot clarify which process steps are done by frontline employees.For instance, whilst in Figure 2 service blueprinting identifies both "Make reservation for guest" and "Take bags to room" as actions by frontline employees, in the PCN diagram (Figure 3) the first one is a part of <Direct Interaction Region> and the second one is a part of <Surrogate Interaction Region> (Note: "Make reservation" and "Make reservation for guest" actions of Figure 2 are combined in Figure 3 to make the "Make reservation" process step).Consequently, <line of Interaction> from service blueprinting is partially covered by <Process Entity plus Process Domain> from PCN.
The next presented lines in service blueprinting are the <Line of Visibility>, <Line of Internal Interaction>, <Line of Order Penetration> and <Line of Implementation>.PCN only fully covers <line of Order Penetration>.The <Line of Visibility> divides onstage actions from backstage actions.In PCN, the interface between onstage and backstage personnel is not defined.In other words, in a PCN diagram it is not possible to determine the visibility of contact employees' actions.Therefore, PCN does not cover <Line of Visibility> in service blueprinting.
The <Line of Internal Interaction> divides frontline actions from support ones.In PCN, there is no mechanism to show whether an action is performed by frontline employees or support personnel.The reason is because both frontline employees and support employees can perform a surrogate interaction and PCN does not clarify whether an action is done by support or frontline employees in the <Surrogate Interaction Region>.Specifically, an action which includes preparation works and activities in a service blueprint can be a part of <Surrogate Interaction Region> in PCN.As a result, <Line of Internal Interaction> in service blueprinting is not supported by any concept in PCN.
As we mentioned above, The <Line of Order Penetration> in service blueprinting is fully supported by PCN.This line divides provider actions to two different categories: Actions that involve interaction with a customer or customer's resources and actions that are done independently by the provider.PCN defines <Independent Processing Region> which can separate process steps that are done solely by the provider from other actions.Consequently, <Line of Order Penetration> in service blueprinting is fully covered by <Independent Processing Region> in PCN diagrams.
The last line in service blueprinting is the <Line of Implementation>.This line divides support actions from management ones.PCN does not define any concept to classify process steps based on whether they are executed by support personnel or management.Therefore, there are no concepts in PCN to support <Line of Implementation> in service blueprinting.
The <Props and Physical Evidence> is an important concept in service blueprinting diagrams.They are visible items to the customers and have a significant effect on customer perceptions about service quality.They help us to understand how physical evidence should be designed to increase service quality.PCN does provide support for <Props and Physical Evidence> by defining <Environmental Conditions Label> and it can be used to show important aspects of the service escape (Bitner, 1992;Sampson, 2012b).A PCN diagram consists of a sequence of steps with an identifiable purpose (Sampson, 2012a(Sampson, , 2012b)).Service blueprinting <Action> concepts are the steps that each actor is taking as part of service delivery process.As a result, the concept of <Action> in service blueprinting covers the concept of <Process Step> in PCN.

Conceptual Evaluation of Service Blueprinting against PCN
An <Arrow> in a PCN diagram indicates state dependency between two actions.The definition of state dependency is not based on whether both actions are performed by one actor or two different actors.However, in service blueprinting <Action Flow> and <Communication Flow> concepts are defined based on the performer of an action.While an <Action Flow> presents the order of actions performed by an actor, <Communication Flow> connects two actions performed by two different actors.Consequently, <Action Flow plus Communication Flow> from service blueprinting are needed to cover the <Arrow> concept in PCN.
<Process Entity> concepts of PCN can be depicted in a service blueprinting diagram, using <Actor Categories>.Considering a <Process Entity> performs and makes decisions about a set of process steps in a service process (Sampson, 2012a(Sampson, , 2012b)), an actor in a service blueprint also does the same and has control over a number of actions.In fact, a service blueprinting diagram not only depicts participant entities; but also it can divide each participant entity to different actors who are performing different parts of the process.Consequently, the <Actor Categories> concept of service blueprinting fully covers the <Process Entity> concept of PCN.
Recall from section 4, the <Value> concept is defined as "the satisfaction of process entity needs" (Sampson 2012a, p. 28).This is not defined in service blueprinting.Service blueprinting does not define needs and how they can be met.Thereby, service blueprinting does not support <Value> in PCN.<Generic Beneficiary> in PCN is defined as "An entity that participates in a process chain to have needs met by the specific competencies in the process chain" (Sampson 2012a, p. 28).For example, a customer who receives consultancy advice from a consultancy firm is a <Specific Beneficiary>.The PCN concept of <Specific Beneficiary> is defined as "An entity that participates in a process chain to acquire generic resources (money) to meet needs from other process chains" (Sampson 2012a, p. 28).Considering the above example, a consultancy firm is a <Generic Beneficiary>.Like <Value>, the PCN concepts of <Specific Beneficiary> and <Generic Beneficiary> cannot be covered by any concept from service blueprinting as there is no mechanism to identify what an entity in a service blueprint diagram expects to receive in order to meet its needs.
A <Process Domain> in PCN diagrams consists of parts of a process chain which a <Process Entity> has control over (Sampson, 2012a(Sampson, , 2012b)).<Actor Categories> can play a similar role in a service blueprinting diagram.Each actor in a service blueprint is responsible for a set of actions which are performed by that actor.In fact, service blueprinting designers identify different actors in a firm to understand which action is done by which actor.This means that <Actor Categories> from service blueprinting supports <Process Domain> from PCN.
PCN defines three separate regions for a <Process Domain>: <Direct Interaction Region>, <Surrogate Interaction Region> and <Independent Processing Region>.<Directinteraction Region> consists of process steps that involve interaction between persons from one entity with persons from another entity.Service blueprinting covers a part of PCN <Direct Interaction Region> through actions executed by onstage employees.All actions carried out by onstage employees involve an interaction with customers.It is important to remember that customer actions are not just between customer and provider employees, a customer can work on a provider's resources (e.g., information, goods and technologies) or a customer can work on his/her own resources.In addition, backstage employees do not only execute actions including interaction with customers, but also work on some resources owned by customers.Therefore, <Actor Categories> from PCN partly supports <Direct Interaction Region> from service blueprinting.
<Surrogate Interaction Region> in PCN consists of process steps that incorporate interaction with nonhuman resources (e.g., Information or goods) of another participant entity.The <Line of Internal Interaction plus Line of Order Penetration> from service blueprinting partly covers <Surrogate Interaction Region> from PCN.An action between these two lines involves interaction with customers' resources.
The third defined region in PCN is the <Independent Processing Region>.<Independent Processing Region> includes process steps that do not involve interaction with the customer or the customer's resources.The <Line of Order Penetration> introduced by Fließ & Kleinaltenkamp (2004) in service blueprinting separates provider actions which involve interaction with customers or a customer's resources from the actions that are performed independently by the provider.In consequence, <Line of Order Penetration> from service blueprinting fully covers <Independent Processing Region> in PCN.
<Nonmonetary Benefits Tag>, <Nonmonetary Costs Tag>, <Monetary Compensations Tag> and <Monetary Costs Tag> are employed in PCN to identify <Value> propositions of <Specific Beneficiary> and <Generic Beneficiary>.Discussed in section 4, <Value> propositions are used to understand during which <process step> concepts <Value> realization occurs.Service blueprinting does not cover these four PCN concepts as it cannot identify the benefits and costs of an action for a participant entity.The comparison shows that these two process modeling formalisms categorize <Action> or <Process Step> concepts in two fundamentally different ways.Service blueprinting aims to show how a customer acts or interacts with a provider (<Line of Interaction>) and categorize the provider's actions based on their visibility to the customer (<Line of Visibility>), whether they are done by contact employees (self-service systems) or other parts of organization (<Line of Internal Interaction>), whether they are customer induced or independent of interacting with the customer (<Line of Order Penetration>), and what the management processes are (<Line of Implementation>).
In comparison, PCN defines customer <Process Domain> and provider <Process Domain>, divides the process steps in each <Process Domain> to three categories: the process steps involving customer interaction with provider employees (<Direct Interaction Region>), the process steps during which a participant entity is doing some job on the other participant entity's resources such as goods, information or technology, (<Surrogate Interaction Region>) and the process steps which are totally under the control of the customer or provider and are not interactive (<Independent Processing Region>).
The abovementioned difference in categorization of activities explains why <Process Entity> and <Process Domain> of PCN is completely covered by <Actor Categories> of service blueprinting.<Actor Categories> in service blueprinting includes customer actions and categorizes provider actions to different organizational roles.Customer and provider are defined each as a <Process Entity> in PCN and their process steps are categorized each as a <Process Domain>.
We know from the method section that if <bi' + …+ bj'> fully covers <ai>, …, <aj> and <ai + …+ aj> partially covers at least one concept from <bi'> , … ,<bj'>, Then: <bi' + …+ bj'> has a broader semantic field than <ai + …+ aj>.In this chapter, it is found that <Actor Categories> in service blueprinting fully covers <Process Entity> and <Process Domain> of PCN.In addition, we found that PCN <Process Entity plus Process Domain> partially covers service blueprinting <Actor Categories>.As a result, <Actor Categories> has a broader semantic field than <Process Entity plus Process Domain> in PCN.
Service blueprinting distinguishes the relationship between actions based on their actor.Service blueprinting identifies two different types of relationship: the relationship between actions performed by an actor (<Action Flow>) and the connections between actions performed by different actors (<Communication Flow>).In contrast, an <Arrow> in PCN indicates state dependency between actions.
Considering defined lines in service blueprinting, the <Line of Order Penetration> is the only line that is completely covered by PCN.Specifically, Fließ & Kleinaltenkamp (2004) improved traditional blueprinting by introducing the <Line of Order Penetration> to separate actions that are customer induced from customer independent ones.That is exactly the purpose of designing <Independent Process Region> in PCN.<Line of Interaction> from service blueprinting is partially covered by <Process Entity plus Process Domain> from PCN.The reason is that customer process steps in PCN can be identified using customer <Process Entity plus Process Domain>.However, it is not possible to identify frontline actions in PCN.Backstage employee actions in service blueprinting include invisible actions that are invisible to the customer plus other actions performed by contact employees (systems) to prepare something as part of a service delivery process (Bitner et al., 2008).Therefore, some of the backstage actions do not involve interaction with customers and cannot be a part of <Direct Interaction Region> in PCN.Our investigations suggest an ambiguity by service blueprinting in identifying backstage activities and support processes.We found that some preparation works can be a backstage action or support action.Consequently, a frontline action in service blueprinting can fall under both <Direct Interaction Region> and <Surrogate Interaction Region> in PCN.Other lines of service blueprinting are not covered by any concept from PCN.
PCN includes a series of concepts related to the motivation of each <Process Entity> to participate in a service delivery process and it can determine whether a process step incurs costs or has some benefits.These concepts are: <Value>, <Generic Beneficiary>, <Specific Beneficiary>, <Nonmonetary Benefits Tag>, <Nonmonetary Costs Tag>, <Monetary Compensations Tag> and <Monetary Costs Tag>.Service blueprinting does not define any of these concepts.In fact, PCN framework improved service blueprinting by introducing these concepts and helping service designers and operations managers to address issues related to the costs and benefits for each process step.

Conclusion
In conclusion, service blueprinting has a different view toward categorization of organizational activities in comparison with PCN.A service blueprinting designer identifies actions performed by a customer, and then categorizes the provider actions to different business roles which are all maintaining delivery of a service to a customer.In comparison, PCN categorizes process steps based on the nature of interaction.PCN firstly identifies all process steps by each participant entity in a service process.These process steps make up the <Process Domain> of that <Process Entity>.PCN defines three process regions to categorize process steps which fall under a <Process Domain> based on the interaction between participant entities in a service process: <Direct Interaction Region>, <Surrogate Interaction Region> and <Independent Processing Region>.Therefore, while service blueprinting categorizes actions based on business roles, PCN does not define any business roles and it focuses on the nature of interaction between entities.In addition, service blueprinting defines two different concepts to order and connect actions based on their performer actors.PCN only defines <Arrow> to connect process steps.
It is understood that both modeling formalisms are useful when the purpose of designers is to identify customer induced and customer independent activities, considering user experience.However, PCN provides a better insight about the nature of interaction between participant entities involved in a service process.Therefore, PCN can be employed for the application of managerial issues especially process efficiency, economies of scale, and customization.Having a series of concepts for identification of value propositions in PCN, enables PCN users to apply these managerial principles, repositioning a process step or a set of process steps in a service process while considering the costs and benefits for each process step.

Research limitation
A limitation of this study is that we only compared the concepts theoretically based on the extracted definitions of concepts from the relevant literature.It would be appropriate to ask a number of practitioners and academicians how they define the concepts of these modeling formalisms.This could help to refine the definitions for each concept.

Future Work
Future research can be dedicated to refining and understanding what the definition of each concept is from the viewpoint of both academicians and practitioners, and then refining definitions for further comparison.While we used in this research a revised version of the method of conceptual evaluation (Milton & Kazmierczak, 2004), it is appropriate to employ other possible methods to compare not only conceptually these three modeling formalisms, but also in some other aspects.A possible method could be the theory of ontological expressiveness of Wand andWeber (1990, 1993).This theory absorbed the attention of many academicians in recent years (e.g., Bowen et al., 2009;Burton-Jones & Meso 2006;Shanks et al., 2008).In particular, the theory of ontological expressiveness is used (e.g., Recker et al., 2009) to examine and compare representational characteristics (completeness and clarity) of a conceptual modeling grammar in information systems.It is possible to employ this method to compare the representational capabilities of the studied modeling formalisms.
It would be appropriate to ask practitioners to utilize these methods and study the results.For example, if practitioners were asked to map a blueprint to a PCN and then again to a blueprint (blueprint (v1)→ PCN→ blueprint (v2)) or map a PCN to a blueprint and then again to a PCN (PCN (v1)→ blueprint → PCN(v2)), how would the ending results be compared and which mapping process would lose more information.We can also study how practitioners use/misuse these modeling formalisms: would practitioners reproduce the same model if they were to independently model a service using a given method; if not, what are the differences and similarities of the produced models. Fig

Table 2 .
Labelling a number of process steps with a term to illustrate environmental conditions that affect customer service delivery perception.In figure3, 'hotel exterior' and 'reception desk' are environmental conditions labels for 'arrive at hotel' and 'go to front desk' process steps.Table2represents the key concepts of PCN and their precise definitions to complete step two of the research method.Concepts in PCN national Journal gram of the ho ities; the entiti he hotel and h s are called pr Figure 3. P eds.Based on d generic benef c benefit.In th articipates in a a generic bene <Generic Beneficiary>A Generic Beneficiary is a process entity that participates in a process chain to acquire generic resources (money) to meet needs from other process chains.<ProcessDomain>AProcessDomain is a portion of process chain that falls under a process entity's control and responsibility.<DirectInteractionRegion>ADirectinteraction Region is the areas of a process domain for process Steps involving person to person interaction between process entities.<SurrogateInteractionRegion>ASurrogateInteraction Region is the areas of a process domain for process steps involving interaction with non-human resources of another process entity (e.g.technology or information).<IndependentProcessingRegion> An Independent Processing Region is the areas of a process domain for process steps that are performed independent from other process entities in the process chain networks.<MonetaryCosts Tag> A Monetary Costs Tag identifies the process steps where the provider incurs costs.

Table 3 .
Results of conceptual evaluation of PCN against service blueprinting Table3shows the results of the conceptual evaluation of PCN against service blueprinting.The table indicates that <Action>, <Action Flow>, <Communication Flow>, <Line of Order Penetration>, and <Props and Physical Evidence> are covered completely by PCN.<Actor Categories> and <Line of Interaction> are covered partially.However, PCN does not support <Line of Visibility>, <Line of Internal Interaction> and <Line of Implementation>.

Table 4 .
Results of conceptual evaluation of service blueprinting against PCN Table 4 shows how well service blueprinting concepts cover semantics behind the definitions of PCN concepts.The table shows <Process step>, <Process Entity>, <Process Domain>, <Independent Processing Region> and <Environmental Conditions Label> from PCN are fully supported by different service blueprinting supportive concepts.The PCN concepts of <Direct Interaction Region> and <Surrogate Interaction Region> are covered partially.The PCN concepts of <Value>, <Specific Beneficiary>, <Generic Beneficiary>, <Nonmonetary Benefit Tag>, <Nonmonetary Costs Tag>, <Monetary Compensations Tag> and <Monetary Costs Tag> are not supported by service blueprinting at all.The following paragraphs will discuss these results according to the order of table 4 in detail, utilizing semiotic theories for this purpose.
Sampson (2012b)n table 4 is dedicated to the <Environmental Conditions Label>.Sampson (2012b)claims these labels are doing the same job as the <Props and Physical Evidence> concept in service blueprinting.Consequently, <Props and Physical Evidence> from service blueprinting fully covers <Environmental Conditions Label> from PCN.It is important to note that while <Environmental Conditions Label> work as labels on process steps in PCN, service blueprinting dedicates its first line from the top to <Props and Physical Evidence> indicating that it is an essential part of service blueprint diagrams.First of all the conceptual evaluation of PCN against service blueprinting indicates that PCN <Process Step> fully supports <Action> in service blueprinting, PCN <Independent Processing Region> fully supports <Line of Order Penetration> in service blueprinting and PCN <Environmental Conditions Label> fully supports <Props and Physical Evidence> in service blueprinting.Moreover, the conceptual evaluation of service blueprinting against PCN shows service blueprinting <Action> fully supports <Process Step> in PCN, service blueprinting <Line of Order Penetration> fully supports <Independent Processing Region> in PCN and service blueprinting <Props and Physical Evidence> fully supports PCN <Environmental Conditions Label>.We know from research design section that if <bi' + …+ bj'> fully covers <ai>, …, <aj> and <ai + …+ aj> fully covers <bi'> , … ,<bj'>, Then: <bi' + …+ bj'> covers same semantic field as <ai + …+ aj>.Therefore, we can conclude here that service blueprinting <Action> covers the same semantic field as <Process Step> in PCN, service blueprinting <Line of Order Penetration> covers the same semantic field as PCN, and <Independent Processing Region> and service blueprinting <Props and Physical Evidence> covers the same semantic field as PCN <Environmental Conditions Label>.