An initial step towards design guidelines for invoice management in CRM

(1)

An initial step towards design guidelines for invoice management in CRM

Jakob Skogby Steinholtz Uppsala, Sweden

Jakob.Skogbysteinholtz.6849@student.uu.se

ABSTRACT

The purpose of this study is to address uncertainty for the implementation of functionality concerning invoice management in the context of the customer relationship management (CRM) system Salesforce by providing design guidelines. It is a qualitative research project that follows a user-centered design (UCD) approach. Seven themes cover- ing perceived difficulties were identified from a diverse set of stakeholders. The themes were analysed in a workshop where two Salesforce developers used their expert judg- ment to address the themes with liable design suggestions.

This was followed by a heuristic evaluation session where an external Salesforce developer evaluated compressed versions of the design suggestions, leading to a concluding proposal of guidelines: 1) Comprehensive error handling and feedback, 2) Modular architecture, 3) Clarify systems relationship and provide detailed information, 4) Group similar functionality according to user role and provide direct feedback, 5) Understand user needs and utilize data graphics 6) Provide transparency for errors when possible, and 7) Provide traceable documentation based on functionality and workflows.

Author keywords

User-centered design (UCD); Customer Relationship Man- agement (CRM); Invoice management; E-invoicing; Us- ability; Information Technology (IT); Design guidelines INTRODUCTION

Customer relationship management (CRM) brings together information technology (IT), humans, and workflows to learn more about the customers and members of an organisation or company in terms of their needs and values. Its purpose is to assist companies in maintaining, developing, and creating a close relationship with their customers.

When successfully integrating CRM into a company, customer loyalty is likely to increase, which also can entail cu- mulative economic profitability [11].

This work was submitted in partial fulfilment for the master of science degree in Hu - man – Computer Interaction at Uppsala University, Sweden. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copy- rights for components of this work owned by others than the author(s) must be hon- oured.

CRM is the biggest software market in the world, predicted to have revenue surpassing 80 billion dollars in 2025 [67], which makes it an exciting topic of research. Previous research on CRM has targeted the topic in different ways [24,54,58], although what is especially interesting for this study is research about critical success factors (CSF) for CRM success [29,37,53], as design guidelines for part of a CRM system will be developed. Several studies show that usability is a prominent factor for the success of E-CRM and performance [2,40,63], which is interesting for this study and has influenced the choice of user-centered design (UCD) as a methodological approach.

In this study, the specific CRM system that will be investigated is Salesforce. Salesforce is the world’s leading CRM system working with over 150 000 companies. Its purpose is to assist companies with customer-related tasks such as marketing, sales, services, and e-commerce [68]. The Sales- force platform is cloud-based and has integrated tools like artificial intelligence (AI), internet of things (IoT), and voice control, to bring companies closer to their customers [69]. The focus of this research project is on invoice management through CRM. In 2011, only around 10% of the invoices sent each day were in digital format [20]. In general, E-invoicing is an extensively researched area, and several problems and difficulties have been identified [31,48,52,25]. However, for e-invoicing in the context of CRM, research is lacking.

Although there is limited research on difficulties in relation to e-invoicing within CRM, it is extensively argued by the company Öhlmér Utveckling, the partner this study is done in collaboration with. Project leaders and developers working with Salesforce at the company have expressed that a lot of uncertainty for integrating invoice related functionality in CRM is present. The uncertainty is mainly about the integration between different systems, such as CRM and an accounting system, the design of the interface, and how varying requirements for invoice related functionality can be implemented in a structured way. Furthermore, the company expressed a general lack of knowledge for what users actually value regarding invoice management in Salesforce, arguing that they, therefore, have an inadequate view of what to consider during the development process of this kind of functionality.

(2)

The goal of this research has, therefore, been to explore difficulties experienced by multiple companies working with Salesforce, regarding invoice management. The formulated difficulties have been analysed in order to provide an initial proposal of design guidelines for invoice management through Salesforce. The formulated research question is:

“What design guidelines can be formulated in order to cap- ture and address perceived difficulties from a diverse set of stakeholders regarding invoice management in the context of a single CRM system?”

BACKGROUND

Five components were identified as crucial to form an ade- quate understanding of previously conducted research con- necting to the formulated research focus. Below, they are described and motivated.

User-Centred Design

In this study, UCD has been used as an overarching framework. UCD is a well-known research methodology within the field of Human-Computer Interaction, and have been successfully used in different contexts by researchers over the years [3,4,23,39,51]. Researchers have called it a “mul- tidisciplinary design approach based on the active involvement of users to improve the understanding of user and task requirements, and the iteration of design and evaluation”

[35:105], which seemingly can be done in different ways.

Other researchers explain UCD as focusing on collecting data about the users and how they work, to later use that data to influence design decisions [49]. There are different alternatives for user involvement when constructing an artefact, and the extent of user involvement can vary depending on the project [1]. Limited research has been found when UCD was used in the context of CRM systems, but due to its dynamic use, it can be argued that it is likely to successfully work in such a context as well. Research where UCD has been applied for developing web-based sites and applications [9,13,57], however, are interesting to look at as it gives insight into how it would work in the context of CRM and specifically Salesforce, as it is a web-based system.

Other research regarding UCD and its application in different projects have been done. For example, agile development in relation to UCD has been investigated, providing five different principles for the combination of both [10].

This combination has been researched by others as well [15,27,55] and provides interesting information as the company from where this study is conducted, uses agile development regularly. Research, where frameworks for conducting UCD are constructed, are regularly performed [17,28,38], assisting practitioners with structured assistance for the application of UCD in various contexts.

CRM systems

Research on CRM has increased over the years, providing insights into its definition and use. For example, a framework for increasing the likelihood of business success with

CRM have been developed. [65]. Other frameworks have also been constructed to assist in other parts of CRM. One example is a framework for widening the perception of CRM, investigating how it can increase value for businesses in different ways [47]. Another example is one that focuses on processes in CRM [46]. Research have shown that implementing a CRM system can have positive consequences regarding organisational performance if the right strategy is followed [12]. CRM can also entail improved customer loyalty, and in the long run, an economic increase [11]. However, in order to successfully benefit from implementing a CRM system in an organisation, the key is to not only see CRM as a technology, rather a strategy that can require structural changes within the organisation [11]. This is something that is argued in other research as well, where determining factors for the effectiveness of CRM systems were investigated. Ease of use, e-learning systems, and in- frastructure capabilities were considered as important factors for the success of implementing CRM [42].

Examples of more recent research on CRM is the approach

“customer portfolio management” (CPM) and how it can be used to understand how different types of customers bring value to an organisation [58], how the implementation of CRM relates to customer satisfaction for hotel business [54]

and how social media can be connected to CRM and “social CRM” [24].

Studies investigating CRM in relation to usability are interesting, as this is one core part of UCD [1]. Research has shown that usability is one of the deciding factors for E- CRM success and performance [2,21,40,63]. This is valuable knowledge for this particular study, as UCD has been used.

IT in organisations

Several frameworks for business value in relation to IT have been produced [30,41,56], all concentrating on the challenge of determining the revenue of an IT investment for organisations.

The reason for why the implementation and adoption of varying kinds of IT systems fail has been researched to a great extent and brings interesting knowledge for this study, as guidelines for a part of a bigger IT system (CRM), have been developed. For example, organisational habits and not enough preparation within the company have been identified as contributing aspects not being able to pursuit SAP (Systems Applications and Products in data processing) im- plementations [22]. Organisational culture as a potential point for failure regarding information systems (IS) has been argued by other research as well, together with more aspects related to failure [64]. Others argue that the recog- nized usefulness of the system is highly related to the acceptance of it [16] and that the level of incentives and en- gagement the users have to actually use the system are determining factors for success [34]. Research focusing on

(3)

management for small businesses identified technical knowledge, economic constraints, and appropriate alloca- tion of time resources as crucial factors for whether or not the implementation of IS would succeed [60]. Research on small businesses in relation to IT gives valuable insights for this study as the majority of the selected companies for participation can be classified as such.

E-invoicing

Extensive research for invoice management and e-invoicing has been made [31,48,52]. For example, research focusing on organisational resistance factors towards e-invoicing states that aspects such as “lack of benefits”, “IT readi- ness”, and “error-proneness” are contributing aspects [25].

Ease of use, compatibility, usefulness, and security of data transport have been identified as key points for the adoption and use of e-invoicing [26]. The aspect of ease of use was something that was identified as an important consideration in a maturity model for e-invoicing as well, along with other conditions such as work practices and legal regula- tions [14]. Other research has focused on identifying core problematic aspects of e-invoicing applications and presents a solution based on frequently used security objectives [43].

As can be understood from the aforementioned examples, e-invoicing comes with various obstacles. However, the research addressing e-invoicing through specifically CRM systems is limited, although there are some interesting examples. Research has been done about what functionality different companies find most attractive in a CRM-system and where the line between a CRM system and an enter- prise resource planning (ERP) system can be drawn. The author articulates that a CRM system often is connected to an ERP system that usually offers functions regarding the economy and specifically invoicing. The author also presents a problem with multiple systems in an organisation not being able to communicate with each other in an optimal way, leading to internal issues [5].

Design guidelines

Previous research gives insight into various strategies for the process of developing design guidelines for different purposes. Especially relevant for this study are guidelines regarding web-based technologies. One study covers the process and results of developing web design guidelines for older people, using techniques such as literature review, card sorting, affinity diagram, and heuristic evaluation [66].

Another study focuses on design guidelines about human factors. The researcher argues that to formulate the final design guidelines, scientific techniques to analyse the data, such as categorization and ordering, should be combined with other more “artistic” techniques like heuristic- and expert judgement. The author also states that the process of developing design guidelines varies between different projects and that there are no clear sets of methods and techniques to follow. However, the author do bring up different methodological aspects that are considered useful.

These are about being educated and well-informed of sys-

tem designers and the context of system design, having an extensive database of relevant data, reviewing activities and having well-defined criteria for selection. Further aspects are the use of analytical techniques and having an open approach to the use of heuristics, experience, and judgement to construct the guidelines. Finally, the author promotes using methods to present the guidelines in a way that ad- dresses users needs and requirements [8]. It can be argued that other research conflicts the suggestion of heuristic, experience, and expert judgement as useful methods for design guideline development, saying that subjectivity in the development process can be a factor for making the guidelines non-effective. Furthermore, the author of this research brings up a different aspect to think about when constructing the guidelines, namely that the findings need to be rep- resentative and relevant for the topic and cannot be

“methodologically flawed”. The author also presents five steps to avoid these aspects and states that guideline development is best done collaboratively [18].

Previous research on developing design guidelines for web- based technology has influenced the analytic and practical work of turning data into actual guidelines. There seems to be no clear recipe for success for this kind of work, as different research promotes different strategies. However, the challenges and suggestions have been kept in mind in order to make the suggested final design guidelines as excellent and useful as possible.

METHOD

In this research project, UCD has been used both as a theoretical framework and method, meaning that the theory of UCD have been taken into consideration throughout the project as well its suggested methods having an impact of the decisions for the practical work. Shortly described, UCD focuses on involving the end-users as much as possible in the process of developing and evaluating an artefact.

The major advantage of UCD is that it is more likely that the final product will be more appreciated by the users regarding usability and serving its intended purpose [1].

However, since the research goal of this study is not to develop an artefact, but to propose design guidelines, UCD is viewed as a theoretical base rather than a strict set of methods. Previous research on e-invoicing brings up usability factors as concerns related to e-invoicing [14,26,33]. As usability is one core part of UCD [1], it was believed that using UCD as a theoretical base, was an appropriate approach. The choice of using UCD also follows the suggestions of constructing design guidelines collaboratively [18], as well as using heuristics and experience [8], as another central part of UCD is integrating the users in the research to a great extent [1].

Initial data collection

The participants in this study were recruited using judgement sampling [36]. For the initial data collection, seven individuals participated. The participants were of three kinds;

(4)

four external first-hand users of Salesforce with extensive knowledge of working tasks related to economy and invoicing, two project leaders from Öhlmér Utveckling with comprehensive experience of developing CRM systems including economy and invoice-related functionality, and one external product manager of a CRM and accounting-system integration technology. The goal with the chosen sampling method was to gather key informants [6], that could partici- pate and provide information in different settings throughout the period of the research.

All five external participants have experience using Sales- force for their business and have an interest in being able to perform their invoice management from within Salesforce, making them interesting and useful participants for the research. The specific individuals from each company have been chosen as they have the main responsibility for working tasks related to invoice management and Salesforce.

They are expert users regarding this and provided lots of useful information throughout the study.

Regarding methods for the initial data collection, an on-site observation was performed at the companies that agreed to it as well as where it was physically feasible. The observations focused on “the person”, “the place”, and “the thing”

[50], to collect information about the physical environment and structure of the workplace. This was followed by individual semi-structured interviews [32], influenced by guidelines for qualitative focus [62], with each of the participants. The interviews were either face to face at the participants’ workplace or over the phone when a physical meet- ing could not be arranged. The interviews with users from external companies and the interviews with the project leaders from Öhlmér Utveckling, as well as the product manager, differed in their structure. For the users from the external companies, the interview focus was primarily on perceived difficulties with invoice management in Salesforce from their first-hand perspective. With the project leaders and the product manager, the focus was divided. One focus point was what they, through experience, had learned was difficult for the users regarding invoicing and accounting related tasks in Salesforce. The other focus area was on gathering data for constructing the guidelines. Here, ques- tions about the development process and how any perceived problems could be assessed was prompted. The data collected by the latter focus area was used as a complement during the analysis of the results where a workshop was conducted with two external Salesforce developers, as explained under “Results analysis”.

Before conducting the first interview, a pilot test [62] was conducted with another developer at Öhlmér Utveckling in order to identify any flaws within the interview structure.

The developer was an appropriate test person as he pos- sesses similar technical knowledge as the developers who were interviewed.

Data analysis

For interpretation of the data gathered by the interviews and observations, inductive qualitative analysis [50] was conducted. The interpretation was following a six-step framework for thematic analysis [7], including “become familiar with the data”, “generate initial codes”, “search for themes”, “review themes”, “define themes”, and “write up”.

This was done with an inductive approach [7] in order to identify generic processes, recurring arguments and other aspects regarding invoice management for each participating individual. The process of interpreting the data was of iterative manner and continued until data saturation, where no new aspects of the data emerged. For the resulting themes, stakeholder checks [59], was conducted with the participants and developers, confirming the validity of the interpretation.

Results analysis

To analyse the results, a workshop was conducted where two developers at Öhlmér Utveckling, who had not yet participated in the study, were recruited. Workshops can be a useful tool for gathering various aspects of a subject, reach- ing consensus among stakeholders, and can be either un- structured or structured with prepared points for discussion [49]. The workshop in this study was structured with the prepared points consisting of the themes generated from the interview- and observation data. The goal of the workshop was to get the developers - the future practitioners of the final guidelines, to express what they believed was the best strategies to address each of the different aspects, and for them to reach consensus about this. The specific developers were chosen as they were the most experienced Salesforce developers at Öhlmér Utveckling, increasing the probability of valid and reliable results. After the workshop, the generated data for each point, as presented in the analysis, was summarized and compressed into a shorter format, leading to a first version of guidelines. This process was solely done by the researcher. These guidelines were then used in an evaluation session, as explained in the following paragraph.

Evaluation

Evaluation of guidelines has previously been conducted using heuristic evaluation [44] on websites and systems, investigating whether or not the guidelines are useful [61,66].

The same was done in this study. The design guidelines were evaluated by a Salesforce developer from an external company. The participating developer analysed a previously developed solution for invoice management in Sales- force, for which several problems had been expressed by the users. The participants’ own experience as a developer, the UI of the system that was used for evaluation as well as the associated code, was taken into consideration when evaluating the design guidelines in order to get a full view of the system itself and its associated context. The goal of this evaluation was to see if the first proposal of design guidelines made sense in the context of where they will be

(5)

used in later development projects, thereby providing insight into its usefulness and validity. Its purpose was also to formulate a final set of design guidelines for invoice management in CRM.

Ethical considerations

Regarding ethical considerations, safety measures have been followed in order to make the participants' involvement in the study as secure as possible and preventing any classified data from being shown to other than the researcher, as this could have harmful consequences. As the central systems used by various corporations have been investigated, confidential data has been exposed to the researcher. Therefore, it has been clearly articulated to the participants in advance that the raw data will only be shown to the researcher and that it will be anonymized in the re- port. It has also be stated that their consent for participation can be withdrawn at any time during the project, which would lead to the deletion of all data gathered for that participant. Furthermore, the fact that several of the participants have a working relationship with Öhlmér Utveckling has emphasized the importance of both professional contact and transparency regarding what the participating individuals will gain from the research so that the relationships do not get affected.

RESULTS

Below are the final themes that emerged from the data analysis. Each theme is explained and motivated with quotes and arguments from the collected data.

Automatization

One aspect that was emphasized in all interviews was the importance of automatization. Participants argued that not having to click buttons and fill in various information in order to execute processes such as sending out membership invoices to different clients and preparing different types of invoices, was of high value as much time could be saved.

“There are loads of time to be saved if some steps are automated.” and “The best thing about the system is that it auto- mates many processes to save time.” are examples of quotes from two participants that support this. One participant whose system had support for automation of processes, in theory, expressed that the idea of automated processes is fantastic, but that it is frustrating when it does not work as intended, “I can not sit for hours to try to solve a problem which should have worked automatically”. Another participant said that one good aspect with not having automatization is that it feels safe because you know everything is correct, but argued that it, at the same time, is not preferable to manually jump between systems as it is time-consuming.

Another point that was expressed was the automation of data communication between the CRM and accounting systems. The participants expressed that it would save valuable time if the same task did not have to be performed twice. A developer who was interviewed brought up an interesting contrast towards automatization, namely that some users

that he had worked with prefer to have control of everything that happens in the system, making automatic processes less attractive in some cases. The developer, however, added that it often has to do with the users previous knowledge of IT. In conclusion, it is apparent that automatization is highly desirable for some of the processes of economy and invoice related tasks for different users.

Lack of system support for certain functionality

What was apparent during the interviews was that the participants expressed that their system needed to support a lot of different functions for various parts of their invoice- and economy-related work. Some commonly mentioned functions between the participants were the creation and book- keeping of invoices, support for different kinds of invoices depending on what type of customer or client they are dealing with, PDF-scanning, and invoices that require no payment. Some outliers that were not mentioned to the same extent during the interviews was print-option and exceeded invoice payment registered as a donation. The common de- nominator was, however, the participants’ expression of system support for multiple kinds of processes, implying the importance of a system that can be flexible and ad- justable for specific user needs.

Problems with CRM and accounting system integration One frequently discussed aspect that came up during each of the interviews was the importance of a solid CRM and accounting system integration. Multiple participants emphasized the value of mirroring fields from one system to another and articulated that it is of importance that the fields mean the same thing if they have the same name. Further- more, the majority of the participants expressed that the connection between the two systems was unclear and ineffi- cient in regard to error derivation and tracking. They expressed that when, for example, an invoice was incorrect, it is not clear where in and in what system the problem actually occurred. The users were often forced to check both the systems and seldomly came to clarity regarding what had caused the error. Some participants also expressed that they felt like they were doing a double amount of work in regards to the inadequate integration of CRM and the accounting system. One participant gave an example of this by registering a new contact as a client in Salesforce, “It would have been nice if you only had to do it in Salesforce and then it would be ready for import in the accounting system”. Another participant said, “it would be good if you would not have to log in to the accounting system at all, so it is only something that lies in the background and creates invoices.”, supporting the need for seamless integration.

Another participant expressed frustration in regards to an insufficiently programmed integration. She found it hard to know what would happen in what system if a button was pressed in the CRM system, and if something went wrong, she argued it should not be up to her as a user to solve it, but rather the developer. Moreover, an aspect that came up from one of the participants, as well as one of the project

(6)

leaders, was the lack of communicating system limitations from the accounting system to the CRM system. A problem that had occurred due to this was the number of requests per time interval that could be accepted by the accounting system. The problem had led to some invoices not getting sent properly, having negative implications for the company. In conclusion, during each of the interviews, it was clear that the users, to varying extent, had a problematic experience with the integration between their CRM and accounting systems.

Complex and non-intuitive UI

The majority of the participating individuals expressed concerns regarding the user interface (UI) of Salesforce, arguing a lack of intuitive and clean design. Something that came up in several of the interviews was that the design was messy and cluttered, making it hard to find the functionality and information you were looking for. This had implications for the working processes of invoice management and economy. For example, it was expressed that it was hard to find the right clients within the systems, as it was not clear how the client list could be sorted. Fields with similar names were mixed up, leading to a risk of sending the invoice to the incorrect person. In contrast, one participant said that the UI looked good and spacious at first glance, but that it did not feel like that when something a bit more complex needed to be done. Another aspect regarding the UI was buttons. One interviewee expressed that an explanation of buttons was missing, “Often when I click on a button something completely different from what I had in mind is happening”. In relation to the perceived shortcom- ings in the UI, participants also mentioned that they thought Salesforce had great potential but that it was hard to take advantage of this potential due to the non-optimal design.

One participant expressed: “If you want to configure a Salesforce module, it is not the sharpest of technologies. It is a bit tedious to manipulate if you want to satisfy specific functionality.” This statement is supported by other participants as well, saying that without knowledge of programming, it is hard to customise the UI to meet their needs. In- terestingly, one participant said that they considered switch- ing from Salesforce to another CRM system for their business due to the fact that they did not understand how they could modify the UI to satisfy their requirements.

Transparency and overview

Transparency and overview kept coming up as desirable aspects of supporting the users working processes regarding invoice management and economy. One of the interviewed project leaders expressed that through his experience working with different clients, transparency was especially important for new users of a system. He exemplified with the often present background processes, dealing with communication between the CRM and accounting system, and said that the users want these processes to be transparent so that they can see the status of the data being transmitted. For example, what invoices have been registered or paid. Another

participant talked about transparency in regards to being able to get it upon request and explained that the company she is employed at is a non-profit organisation, making it highly important to get transparency and overview in advance of the year-end closings, to see where they are at in regards to profitability. She added, “we want to have very close control of our expenses”. Furthermore, one of the participants articulated that they want transparency for the status of their invoices and said: “for example, we want to get notified about an invoice that should have been paid 30 days ago, in our CRM system”, indicating overview and transparency in the system as desirable aspects. One participant also argued for this, saying that the system needs to be transparent with what is happening since a lot of things can go wrong otherwíse. In relation to the previous theme about intuitive and clean UI, the majority of the participants argued that the aforementioned cluttered UI worked against this, saying that it is hard to locate the valuable information in order to quickly get an overview of the data and the system in general. Both project leaders said that they, upon request by users, limited the UI for invoice and economy-related tasks to fit on one single page within the system, as they too heard from the users that transparency and overview were desirable system traits. In different contexts throughout every interview, transparency and overview of relevant data came up as central aspects obstructing the working processes with invoice and economy in Sales- force.

Complex error tracing

One frequently mentioned theme that came up during all the interviews was errors, with the focus on error solving and error prevention. Two different kinds of errors were regularly brought up: errors caused by the user, such as clicking the wrong buttons or entering incorrect values and errors caused by the system, such as bugs and nonoptimal programming solutions. Participants frequently argued that once an error had occurred, independently of the kind of error, it was difficult to trace the error to understand its cause.

It was argued that this sort of functionality was missing in their respective system. For example, one participant articulated: “When something goes wrong, you want to trou- bleshoot effectively”. “It is a major confusion when things are not right, which leads to a big frustration”, was said by another participant. A third example of a quote from the interviews is “Some simple way of getting an overview and identifying things that are wrong or weird”, and was proposed as an initial idea of how to address this issue. The project leaders said that from their experience working in different projects, it was clear that users have a tendency to fill in incorrect data in fields, leading to confusion for them if they are not aware that the mistake was made. Further- more, regarding any solving processes of errors, it was frequently expressed by the users that they often have to switch between the CRM and the accounting system in order to see what went wrong, making it an unnecessarily tedious process. One of the users exemplified this with ex-

(7)

plaining if an incorrect invoice had been sent out from the CRM system, they first had to enter the accounting system to mark the invoice as paid manually, and then go back to the CRM system to remove the invoice from there once the process in the accounting system had been registered. These sorts of lengthy processes could also be reflected in the aforementioned theme of CRM and accounting system integration, as it has to do a lot with the communication between the two systems. Another interesting example of de- sired functionality that was argued as missing in one of the users’ systems was guidance for the user to work with the system as intended. It was explained that the lack of this led to a lot of unnecessary errors, which in turn entailed a loss of valuable time. Some of the participants said that some errors were rather easy to solve, but yet had a feeling that they could easily be prevented from being caused in the first place, contributing to the aforementioned feeling of frustration.

Lack of sufficient support and documentation

The last theme that emerged from the interview data was the frequently mentioned lack of documentation and support. This aspect can be viewed as different and less technical when compared to the other themes, as it is not necessarily about the system functionality and processes but rather about the lack of guidance to utilize the functionality and processes to its full potential. When inquired about existing Salesforce documentation that is available online, the participants said that they either had not looked at it or that they failed to extract any value from it due to the massive amount of information that is available. The majority of the participants said that as an inexperienced Salesforce user, it is particularly difficult to navigate in the system and make sense of how different objects, tabs, and buttons are connected. Most of the participants had been provided with a user manual at the system delivery but had often found it not useful due to it being overwhelming in length and non- pedagogical. However, when queried about having access to a user manual in general. All participants had positive re- sponses. One of the participants said that the company where he had worked had tried Salesforce for six months, but then chose another CRM system as they failed to utilize it in regards to their business needs not being met. He explained that this was due to not being able to make sense of the existing documentation and the lack of support from any Salesforce professionals. He continued and said that if sufficient documentation and explanation had been available at the time, they probably would have chosen to con- tinue with Salesforce as their CRM system since they knew about its great potential. One of the interviewed project leaders mentioned that one client had chosen not to use the provided user manual but instead chose to create their own, as the provided one arguably was too lengthy and complex.

What also came up as an aspect regarding support from a user-interviewee, was the lack of rapid communication between the users and the system-supplier. The user explained that if vital bugs were identified in the system, it was usu-

ally the case that communication for this and final solving of the error was lingering, making any errors cause more significant problems than necessary.

ANALYSIS

The themes from interviews were analysed one by one during the workshop, leading to seven different arguments for design: 1) Comprehensive error handling and feedback, 2) Modular architecture, 3) Clarify systems relationship and provide detailed information, 4) Group similar functionality according to user role and provide direct feedback, 5) Un- derstand user needs and utilize data graphics, 6) Provide transparency for errors when possible, and 7) Provide traceable documentation based on functionality and workflows.

During the workshop, it became apparent that some of the themes were nested, and that certain themes could not be addressed without simultaneously addressing another theme. As the structure of the workshop was to go through and analyse each theme separately, it can be argued that certain design arguments have a stronger connection to specific themes. However, what is essential regarding the following design arguments, is that all arguments are developed to collaboratively address all themes with perceived difficulties rather than what specific argument responds to exactly what theme. At the end of the analysis, the conducted evaluation leading to the final proposal of guidelines is explained, followed by a last subheading containing the proposed final guidelines.

Comprehensive error handling and feedback

To solve the described problematic consequences of automated processes not working properly, it is argued that comprehensive error handling and feedback should be pri- oritized. To provide comprehensive error handling, the workshop participants argued it is essential to conduct extensive testing and research about requirements and the technical context of where the system will operate, before delivering a system that includes automated processes. One of the developers added: “think through the whole chain of processes and draw it before starting the development process.” Furthermore, a developer should be creative and construct use cases in order to test and error-proof every case imaginable. It is also important to study any previous code that is to be integrated into the system so that this does not cause any unexpected errors. If errors should occur de- spite the conducted testing, feedback should be provided.

The data that is used to start the automated processes needs to be validated before execution. If the data is incorrect, direct and clear feedback needs to be present so that the user can quickly adjust the specific data that is incorrect before execution. If any error should happen during the automated process, regardless of whether or not it is a programming related issue or something that the user caused, as clear feedback as possible needs to be provided. This will address why the error occurred and arguably put less stress on the user. The participants in the workshop both agreed that

(8)

adding clear feedback and transparency regarding what happens during the automated processes is time-consuming and therefore economically expensive, emphasizing the argument of carefully validating the data that is used to start the processes before execution.

Modular architecture

In order to ensure that the system can be updated to address future user needs for invoice management, it is suggested that the architecture of the system is built in modules. The developers believed that a modular architecture eases the process of implementing support for new functionality as the majority of vital functionality is divided, making the addition of any new requirements more straightforward and less likely to cause problems to already existing code. To achieve architectural modularity however, every design decision must be thought through and planned so that the different modules do not get nestled to the point where minor changes affect important functionality. To achieve a modular architecture, the developer should start with the easy parts in each module and, first at a later stage, try to connect them. One workshop participants argued that it is often hard to keep the development process simple and said: “It is good to have the mindset of ‘keep it simple’, but it is difficult to live up to it as the project progresses”. Furthermore, it was argued that as a developer, limits for data transmis- sion between multiple systems, should be considered, so that the addition of new functionality does not cross any predefined limit. Furthermore, taking advantage of any testing assistance that ensures functionality, such as automatic testing in Salesforce, is recommended if this is provided for the used CRM system, as it ensures the function of previously developed modules.

Clarify systems relationship and provide detailed infor- mation

It is argued that in order to make the connection between the two systems easier to understand, the relationship needs to be clarified. Detailed information and feedback need to be provided to the user. The participants that were in the workshop argued that If one of the systems is master, this needs to be communicated so that the user understands in what direction the systems communicate with each other, making it more intuitive in which system the user should adjust and correct any errors. If any action needs to be made in a specific system, this needs to be explicitly communicated to the UI. It is also important that any limitation within the accounting system is communicated to the CRM system, making it easier for the user to understand why something went wrong. One of the workshop participants said: “present the user with all the information that can be presented”. Another argued that the accounting system often gives scarce error messages, something that also needs to be conveyed so that the user does not search for something that does not exist.

Group similar functionality according to user role and provide direct feedback

It is suggested that grouping similar functionality to the role of the user as well as providing direct feedback, can prevent the feeling of the UI being overwhelming. If the system provides a lot of functions and different processes for different tasks, it is recommended to divide and group related functionality to each other, making it more clear of where in the system the user is and potentially preventing the feeling of the UI being overwhelming. Another strategy that the participants in the workshop suggested to address complex and non-intuitive UI was to disable non-relevant functionality for specific users in cases where multiple users are using different parts of a system. Furthermore, direct feedback should be communicated whenever an active decision is taken. The workshop participants suggested utilising functionality such as tooltips, self-explanatory button names, and direct links to the user manual with an explanation of the current task that the user is trying to accomplish.

Understand user needs and utilize data graphics During the workshop, it was argued that understanding the user needs and utilizing the potential of data graphics within CRM, are core points to prevent a lack of transparency and overview. Both participants in the workshop agreed that understanding the user needs is key to knowing what data is valuable to present in the UI. It is therefore important to clearly define the user needs early in the development process, during the requirement elicitation phase. A potential strategy to ensure transparency and overview was for the developer team to, as soon as they are done with the core functionality, investigate how the valuable data can be presented in the UI in order to provide transparency and overview of the data. This can be done by utilizing built-in tools for data graphics such as diagrams, progress bars, and dashboards. Furthermore, exporting of valuable data and grouping of similar functionality, as mentioned in the above guideline, should be considered. The workshop participants emphasized that implementing this sort of functionality usually is a time-consuming task, making it important to clearly define whether or not it is part of the system requirements or not.

Provide transparency for errors when possible

During the workshop, it was argued that transparency was highly important to reduce the complexity of addressing any errors occurring in the system. One of the participants in the workshop said that “as a developer, you can always check the data logs for tracing an error. But that is not always feasible as a user”. The participant continued and said that it would be good if similar information as exists in the logs, can be communicated to the user in the UI, arguably increasing transparency for errors. To increase the explanatory level of error messages regarding unique and complex errors, the other workshop participant suggested that an error-table could be provided, linking the error message to an explanation of why it occurred and how it can be solved.

(9)

Furthermore, it was suggested immediate feedback should be provided as soon as an error occurred, explaining what went wrong. The participant explained: “In order for the user to understand why something went wrong and how it can be solved, immediate feedback needs to be presented so that the user can address the error before moving on to the next task”. To prevent the error from occurring in the first place, both of the workshop participants argued for reduc- ing the risk of human-factor errors such as filling in the wrong values and clicking the wrong buttons, suggesting similar measures as for addressing the theme of complex and non-intuitive UI.

Provide traceable documentation based on functionality and workflows

The participating individuals in the workshop agreed that user manuals should be focusing on workflows rather than specific buttons and functionality. It was argued that this would give the manual a clearer purpose and that it would be easier for the user to find what they are searching for.

One idea that came up during the workshop was to have links to the manual within the UI to the specific task the user is trying to perform, making the usage of the manual more efficient. Regarding online documentation, the participants in the workshop said that it should only be used if it is with direct links to specific online pages that clearly de- scribe parts of the system that is not directly related to what has been developed, but rather other aspects of the CRM system which might be of interest. It was also suggested that the UI could contain buttons that open the manual, making it more efficient for the user to access it. Further- more, there were speculations about if the manual could be opened and automatically show instructions relevant to the specific task that the user was trying to perform, increasing the ease of use further.

Evaluation

After the analysis of the themes, the researcher compressed all design arguments into shorter versions while still retain- ing their initial meaning, leading to the first proposal of design guidelines for invoice management in CRM. These design guidelines were then used in an evaluation session, as explained in the method section of this paper. The evaluator generally thought each one of the design guidelines made sense in the context of developing invoice related functionality in Salesforce but had some feedback regarding the se- mantics of the guidelines, as some of them were unclear in terms of what they specifically targeted. From the feedback, minor adjustments to the guidelines were made to make them more refined and well formulated. The updated guidelines were then shown to the evaluator, confirming that the perceived issues were addressed. This led to a final proposal of guidelines for invoice management in the context of CRM, presented under the following paragraph “Final guidelines”.

Final guidelines

The final proposal of guidelines are:

1) Comprehensive error handling and feedback

Developers should carefully research and evaluate background processes that build on automatization. Provide so- phisticated validation of data that is used for execution and give immediate feedback if any errors occur during the processes.

2) Modular architecture

Developers should divide the system into separate modules and perform continuous testing of functionality. Keep it simple and avoid deep nesting of code. Utilize functionality testing assistance if provided by the CRM system.

3) Clarify system relationship and provide detailed infor- mation

Developers should provide clear instructions in what system the user needs to perform a task. Present detailed information regarding any limitations for systems’ communication. Customize any insufficient pre-defined error messages to assist the users.

4) Group similar functionality according to user role and provide direct feedback

Customize the UI according to the user role and remove unnecessary components. Provide direct feedback in the form of tooltips, self-explanatory button names, and direct links to the user manual.

5) Understand user needs and utilize data graphics

A developer should continuously validate that the user needs are understood, and present requested information to the UI by utilizing any tools for data graphics, such as diagrams, progress bars, and dashboards.

6) Provide transparency for errors

Developers should provide clear and effective feedback to the user if an error occurs. The feedback should explain why the error occurred and how it can be solved.

7) Provide traceable documentation based on functionality and workflows

User manuals should be based on user workflows and core processes. It should be easily accessible from the UI.

DISCUSSION AND FUTURE RESEARCH

There are multiple aspects regarding the conducted research and its results that can be discussed and reflected upon. One aspect is UCD, which was the chosen theoretical approach.

It meant that a lot of focus was put on integrating future practitioners of the guidelines during both the data collection and the data analysis process. The participants greatly influenced what the proposed final guidelines looked like.

Although this approach follows the lines of UCD with integrating the user in the research as well as possibly increasing the usability of the product [1], other strategies might

(10)

would have led to more reliable results and conclusions. For the data analysis, replacing both the inductive thematic analysis and the workshop, an alternative could have been to analyse the data deductively with well-known usability heuristics for user interface design [19] or other sets of principles for design [45]. The choice of not following this approach was dependent on various considerations. One argument is that such an approach had not been used for the analysis within the development process of other guidelines from previous research [8,18,66]. Another argument is that the heuristics were focusing on the UI, making it not as fit for the context of CRM system development, as the majority of the UI already is defined, limiting UI design decisions. Furthermore, it was also believed that any type of framework for the analysis might lead to forcing certain data into categories where it might not belong, which possibly could distort the data and make the final guidelines less applicable for the context of CRM and Salesforce. It was, therefore, more attractive to keep an exploratory approach to the research.

Another aspect worth discussing is the participants used in the study. The main focus for the initial data collection, where interviews and observations were conducted, was to elicit perceived difficulties regarding invoice management in Salesforce. It can be argued that it would have been preferable if more first-hand users would have participated, possibly leading to the identification of further difficulties as well as making them more well-grounded. However, as the potential lack of first-hand perspectives was filled with second-hand perspectives from the participating developers, who had experience working closely with other first-hand users, it can be argued that the resulting themes with difficulties are valid, especially since data saturation was met during the later interviews. There is often a risk that not all aspects of a given problem have been identified, especially since the previous research on the topic is rather limited.

However, it can be stated that this research gives insight into the most commonly perceived problems and how they can be addressed in Salesforce, which can work as a base for future research that can investigate the problem further.

Another important thing to reflect upon is the performed heuristic evaluation, which confirmed that the guidelines made sense in the context of where they will be used. How- ever, it does not necessarily imply that they are useful during the actual development process of this sort of functionality. Optionally, the guidelines could have been evaluated with the context of two development projects that are different from each other in relation to the proposed guidelines, where the evaluator would look at both the code and the UI and rate the guidelines in regards to their usefulness, as is done in previous research for design guidelines [66].

Another strategy for evaluation could have been to let a developer team follow the guidelines in an actual development project. When the project is finished, the end-users could be inquired about how they perceived the system in

regards to the functionality of focus. This could have been a solid evaluation that would bring clear insight into the usefulness of the guidelines. Unfortunately, neither of the two strategies was applicable due to a lack of resources and a limited time frame. The strategies could, however, be interesting for future research on this topic, increasing the validity of the guidelines.

Lastly, the final results of the study can be discussed regarding its reliability. Due to limited previous research on guidelines in the context of CRM as well as invoice management, it is difficult to compare the final proposal of design guidelines serving this purpose, to other guidelines. As mentioned, the evaluation indicates that the guidelines are applicable within its intended context. However, due to a lack of more advanced testing as well as potential lack of participants, it is emphasized that the guidelines are not final nor should be followed strictly. Rather, they should be viewed as an initial proposal of how to address commonly perceived difficulties regarding invoice related tasks in CRM, and can hopefully spark further research that can build on the proposed guidelines to make them more refined and solid.

As the research regarding the chosen topic is limited, it makes room for varying kinds of future research. For example, research could look at guidelines for other kinds of functionality in CRM and make further delimitations solely focusing on the UI, making it interesting as the majority of the UI usually is predefined in the context of CRM. For that research focus, it could be interesting to see how the predefined UI relates to well-known heuristics and guidelines for UI design. Another interesting proposal for future research is to look at only one side of the development process within CRM, for example, strictly database architecture, and see what guidelines can be formulated to address pre- cisely that side of the system.

CONCLUSION

This research has explored perceived difficulties regarding invoice management in the CRM system Salesforce by continuously collaborating with a varied set of stakeholders through a user-centered approach. From the collected data, a final proposal of a set of seven design guidelines has been composed in order to address the identified problems, an- swering the formulated research question. The study was done in collaboration with the company Öhlmér Utveckling and successfully brought clarity into the aforementioned uncertainties regarding the implementation and integration of invoice related functionality. The probability of success- ful adoption of the presented guidelines is likely to increase if the CRM system in the specific context is Salesforce, as that is the CRM system that has been used by the stakeholders whom the guidelines are derived from. However, the guidelines have been formulated to be as generic as possible and can potentially be used successfully for other CRM systems as well.

(11)

REFERENCES

[1] Chadia Abras, Diane Maloney-Krichmar, and Jenny Preece. 2004. User-centered design. Bainbridge W En- cycl. Hum.-Comput. Interact. Thousand Oaks Sage Publ. 37, 4 (2004), 445–456.

[2] Khalid Al-Momani, Mohd Noor, and Nor Azila. 2009.

E-service quality, ease of use, usability and enjoyment as antecedents of e-CRM performance: an empirical in- vestigation in Jordan mobile phone services. Asian J.

Technol. Manag. 2, 2 (2009), 50–64.

[3] Christopher Andrews, Debra Burleson, Kristi Dunks, Kimberly Elmore, Carie S. Lambert, Brett Oppegaard, Elizabeth E. Pohland, Danielle Saad, Jon S. Scharer, and Ronda L. Wery. 2012. A new method in user-centered design: Collaborative prototype design process (CPDP). J. Tech. Writ. Commun. 42, 2 (2012), 123–

142.

[4] Danielle A. Becker and Lauren Yannotta. 2013. Mod- eling a library web site redesign process: Developing a user-centered web site through usability testing. Inf.

Technol. Libr. 32, 1 (2013), 6–22.

[5] Shayan Behnami Amin. 2014. CRM i små och medel- stora företag: En studie om företagens behov av CRM- funktioner. Mid Sweden University, Östersund, Swe- den.

[6] H. Russell Bernard. 2017. Research methods in anthro- pology: Qualitative and quantitative approaches. Row- man & Littlefield, Lanham, Maryland.

[7] Virginia Braun and Victoria Clarke. 2006. Using the- matic analysis in psychology. Qual. Res. Psychol. 3, 2 (January 2006), 77–101. DOI:https://doi.org/

10.1191/1478088706qp063oa

[8] John L. Campbell. 1996. The development of human factors design guidelines. Int. J. Ind. Ergon. 18, 5–6 (1996), 363–371.

[9] H. Yu Catherine, Janet A. Parsons, Susan Hall, David Newton, Aleksandra Jovicic, Danielle Lottridge, Baiju R. Shah, and Sharon E. Straus. 2014. User-centered design of a web-based self-management site for individuals with type 2 diabetes–providing a sense of control and community. BMC Med. Inform. Decis. Mak. 14, 1 (2014), 60.

[10] Stephanie Chamberlain, Helen Sharp, and Neil Maiden.

2006. Towards a framework for integrating agile devel- opment and user-centred design. In International Con- ference on Extreme Programming and Agile Processes in Software Engineering, Springer, 143–153.

[11] Injazz J. Chen and Karen Popovich. 2003. Understand- ing customer relationship management (CRM). Bus.

Process Manag. J. (2003).

[12] Tim Coltman, Timothy M. Devinney, and David F.

Midgley. 2011. Customer relationship management and firm performance. J. Inf. Technol. 26, 3 (2011), 205–

219.

[13] Michael D. Corry, Theodore W. Frick, and Lisa Hansen. 1997. User-centered design and usability test-

ing of a web site: An illustrative case study. Educ.

Technol. Res. Dev. 45, 4 (1997), 65–76.

[14] Angelica Cuylen, Lubov Kosch, and Michael H. Breit- ner. 2016. Development of a maturity model for elec- tronic invoice processes. Electron. Mark. 26, 2 (May 2016), 115–127. DOI:https://doi.org/10.1007/s12525- 015-0206-x

[15] Tiago Silva Da Silva, Angela Martin, Frank Maurer, and Milene Silveira. 2011. User-centered design and agile methods: a systematic review. In 2011 AGILE conference, IEEE, 77–86.

[16] Fred D. Davis. 1989. Perceived usefulness, perceived ease of use, and user acceptance of information tech- nology. MIS Q. (1989), 319–340.

[17] Mr Sachin Kumar Dhar Dwivedi, Mr Saurabh Upad- hyay, and A. Tripathi. 2012. A working framework for the user-centered design approach and a survey of the available methods. Int. J. Sci. Res. Publ. 2, 4 (2012), 12–19.

[18] Mary B. Evans. 2000. Challenges in developing re- search-based Web design guidelines. IEEE Trans.

Prof. Commun. 43, 3 (2000), 302–312.

[19] World Leaders in Research-Based User Experience. 10 Heuristics for User Interface Design: Article by Jakob Nielsen. Nielsen Norman Group. Retrieved June 7, 2020 from https://www.nngroup.com/articles/ten-usability-heuristics/

[20] Louella Fernandes and Clive Longbottom. 2011. E-in- voicing: Ready for prime time. Quocirca Ltd (2011).

[21] Jerry Fjermestad and N. C. Romano. 2003. An integra- tive implementation framework for electronic customer relationship management: revisiting the general princi- ples of usability and resistance. In 36th Annual Hawaii International Conference on System Sciences, 2003.

Proceedings of the, IEEE, 9–pp.

[22] Vidyaranya B. Gargeya and Cydnee Brady. 2005. Suc- cess and failure factors of adopting SAP in ERP system implementation. Bus. Process Manag. J. (2005).

[23] Anders Green, Helge Huttenrauch, Mikael Norman, Lars Oestreicher, and K. Severinson Eklundh. 2000.

User centered design for intelligent service robots. In Proceedings 9th IEEE International Workshop on Ro- bot and Human Interactive Communication. IEEE RO- MAN 2000 (Cat. No. 00TH8499), IEEE, 161–166.

[24] Sushmita Guha, Paul Harrigan, and Geoff Soutar.

2018. Linking social media to customer relationship management (CRM): A qualitative study on SMEs. J.

Small Bus. Entrep. 30, 3 (2018), 193–214.

[25] Steffi Haag, Friedrich Born, Stanislav Kreuzer, and Steffen Bernius. 2013. Organizational Resistance to E- Invoicing – Results from an Empirical Investigation among SMEs. In Electronic Government, Maria A.

Wimmer, Marijn Janssen and Hans J. Scholl (eds.).

Springer Berlin Heidelberg, Berlin, Heidelberg, 286–

297. DOI:https://doi.org/10.1007/978-3-642-40358- 3_24

(12)

[26] Blanca Hernandez-Ortega. 2012. Key factors for the adoption and subsequent use of e-invoicing. Acad. Rev.

Latinoam. Adm. 50 (2012), 15–30.

[27] Shah Rukh Humayoun, Yael Dubinsky, and Tiziana Catarci. 2011. A three-fold integration framework to incorporate user–centered design into agile software development. In International Conference on Human Centered Design, Springer, 55–64.

[28] Constance M. Johnson, Todd R. Johnson, and Jiajie Zhang. 2005. A user-centered framework for redesign- ing health care interfaces. J. Biomed. Inform. 38, 1 (2005), 75–87.

[29] Stephen F. King and Thomas F. Burgess. 2008. Under- standing success and failure in customer relationship management. Ind. Mark. Manag. 37, 4 (June 2008), 421–431. DOI:https://doi.org/10.1016/

j.indmarman.2007.02.005

[30] Ram L. Kumar. 2004. A framework for assessing the business value of information technology infrastruc- tures. J. Manag. Inf. Syst. 21, 2 (2004), 11–32.

[31] Jiunn-Woei Lian. 2015. Critical factors for cloud based e-invoice service adoption in Taiwan: An empirical study. Int. J. Inf. Manag. 35, 1 (2015), 98–109.

[32] Robyn Longhurst. 2003. Semi-structured interviews and focus groups. Key Methods Geogr. 3, 2 (2003), 143–156.

[33] Lasse Lumiaho and Jussi Rämänen. 2011. Electronic invoicing in SMEs. In International Conference of De- sign, User Experience, and Usability, Springer, 475–

484.

[34] Yogesh Malhotra and Dennis F. Galletta. 2004. Build- ing systems that users want to use. Commun. ACM 47, 12 (2004), 88–94.

[35] Ji-Ye Mao, Karel Vredenburg, Paul W. Smith, and Tom Carey. 2005. The state of user-centered design practice. Commun. ACM 48, 3 (2005), 105–109.

[36] Martin N. Marshall. 1996. Sampling for qualitative re- search. Fam. Pract. 13, 6 (1996), 522–526.

[37] Luis E. Mendoza, Alejandro Marius, María Pérez, and Anna C. Grimán. 2007. Critical success factors for a customer relationship management strategy. Inf. Softw.

Technol. 49, 8 (August 2007), 913–945. DOI:https://

doi.org/10.1016/j.infsof.2006.10.003

[38] Jessica Meyerson, Patricia Galloway, and Randolph Bias. 2012. Improving the user experience of professional researchers: Applying a user-centered design framework in archival repositories. Proc. Am. Soc. Inf.

Sci. Technol. 49, 1 (2012), 1–7.

[39] Delnavaz Mobedpour and Chen Ding. 2013. User-centered design of a QoS-based web service selection sys- tem. Serv. Oriented Comput. Appl. 7, 2 (2013), 117–

127.

[40] Seyed Mahdi Mohammadi and Ali Reza Kartalaei.

2016. Identification of the components and factors affecting on electronic customer relationship management performance (case study: Iran telecommunica-

tions industry). Int. J. Humanit. Cult. Stud. IJHCS ISSN 2356-5926 1, 1 (2016).

[41] John G. Mooney, Vijay Gurbaxani, and Kenneth L.

Kraemer. 1996. A process oriented framework for assessing the business value of information technology.

ACM SIGMIS Database DATABASE Adv. Inf. Syst. 27, 2 (1996), 68–81.

[42] Nima Jafari Navimipour and Zeynab Soltani. 2016.

The impact of cost, technology acceptance and em- ployees’ satisfaction on the effectiveness of the electronic customer relationship management systems.

Comput. Hum. Behav. 55, (2016), 1052–1066.

[43] Michael Netter and Günther Pernul. 2009. Integrating security patterns into the electronic invoicing process.

In 2009 20th International Workshop on Database and Expert Systems Application, IEEE, 150–154.

[44] Jakob Nielsen and Rolf Molich. 1990. Heuristic evalu- ation of user interfaces. In Proceedings of the SIGCHI conference on Human factors in computing systems, 249–256.

[45] Donald A. Norman. 2013. The design of everyday things (Revised and expanded edition ed.). Basic Books, New York, New York.

[46] Atul Parvatiyar and Jagdish N. Sheth. 2001. Concep- tual framework of customer relationship management.

Tata/McGraw-Hill, New Delhi, India.

[47] Adrian Payne and Pennie Frow. 2005. A strategic framework for customer relationship management. J.

Mark. 69, 4 (2005), 167–176.

[48] Esko Penttinen and Maria Hyytiainen. 2008. The Adoption of Electronic Invoicing in Finnish Private and Public Organizations. In ECIS, 1298–1309.

[49] Jennifer Preece, Yvonne Rogers, and Helen Sharp.

2002. Interaction design: beyond human-computer in- teraction. Wiley, New York.

[50] Jenny Preece, Yvonne Rogers, and Helen Sharp. 2015.

Interaction design: beyond human-computer interac- tion (Fourth edition ed.). Wiley, Chichester.

[51] Rebecca M. Prince, Anthony Soung Yee, Laura Par- ente, Katherine A. Enright, Eva Grunfeld, Melanie Powis, Amna Husain, Sonal Gandhi, and Monika K.

Krzyzanowska. 2019. User-Centered Design of a Web- Based Tool to Support Management of Chemotherapy- Related Toxicities in Cancer Patients. J. Med. Internet Res. 21, 3 (2019), e9958.

[52] Hennariina Pulli. 2005. Factors affecting the adoption of electronic invoicing. (2005).

[53] Ilan Rahimi and Uri Berman. 2009. Building a CSF framework for CRM implementation. J. Database Mark. Cust. Strategy Manag. 16, 4 (December 2009), 253–265. DOI:https://doi.org/10.1057/dbm.2009.29 [54] Roya Rahimi and Metin Kozak. 2017. Impact of cus-

tomer relationship management on customer satisfac- tion: The case of a budget hotel chain. J. Travel Tour.

Mark. 34, 1 (2017), 40–51.

[55] Dina Salah, Richard F. Paige, and Paul Cairns. 2014. A systematic literature review for agile development pro-