Conversational agents, or chatbots, providing question-answer assistance on smart devices, have proliferated in recent years and are poised to transform online customer services of corporate sectors.1,6 Implemented through dialogue management systems, chatbots converse through voice-based and textual dialogue, and harness natural language processing and artificial intelligence to recognize requests, provide responses, and predict user behavior.5,28 Market analysts concur on current adoption trends and the magnitude of growth and impact of chatbots anticipated in the next five years. According to a report by Grand View Research, for instance, already 45% of users prefer chatbots as the primary point of communications for customer service enquiries, translating into a global ‘chatbot’ market of $1.23 billion by 2025, at a compounded annual growth rate (CAGR) of 24.3%.9
Key Insights
- The key question is how can chatbot capabilities and architecture scale up for corporate services of increasing complexity, sensitivity, delivery processes, and duration?
- There are two distinct types of service interactions for delivering complex services via chatbots, including: search-oriented interactions (that is, service discovery: search for available services, rifles, locations, and forms) action-oriented interactions (for example, filling application forms, checking for eligibility and entitlements, for service offers, and service boarding tasks). Chatbots must scale up to cover both types of services.
- Chatbots should be retrofitted into a multifaceted contextual-aware service delivery, where dialogue can be effectively anchored, directed, and sustained through distinct contexts to meet user goals.
The strategy for conducting conversations using chatbots requires an efficient resolution of two key aspects. First, user queries or automatically perceived needs through user interactions have to be interpreted and mapped into categories, or user intents. This is based on historical processing of queries and needs, and the use of intent classification techniques.12 Second, conversations must be constructed for specific intents using frame-based dialogue management2 and neural response generation techniques.15 In frame-based dialogue management, the chatbot needs to converse with the user to have a fully filled frame (for example, flight information) in which all slot values are provided by the user (for example, airline carrier, departure time, departure location, and arrival location). Inputs on one or more frames results in meeting the user’s goal. The dialogue flow is constructed through an ordered sequence of frames.
As seen through widely adopted examples such as Google Assistant, Apple Siri, and Amazon Alexa, chatbots have been effective for search, recommender, and singleton task capabilities involving bounded contexts, where service knowledge is limited and the conversations are short (typically, not more than a few question-answers). Building upon these capabilities, examples have emerged from retail, financial, government, and other corporate sectors, where chatbots are advancing and moving toward having better capabilities of assisting with in financial, trust and risk sensitive services, traditionally delivered by staff and enterprise systems.22,23
These next-generation chatbots are expected to operate in broader user contexts and operating environments of systems, given the extent of data, business rules, and processes involved.23 Examples of trends underway are as follows. Transport for London’s Travel demonstrated how chatbots can be integrated with enterprise systems to find information about services in user contexts, including geospatial and historical user preferences and patterns.27 Online travel systems such as Expedia, Booking.com, Skyscanner, Cheapflights, and airline companies such as KLM, British Airways, and Icelandir, assist customers in making and changing flights, thus extending the reach of actions associated with dialogue to tasks undertaken by enterprise systems and transactional tasks within them. AI Jim from Lemonade Insurance26 integrates chatbot dialogue with inputs and outputs of multistep processes by supporting customers in capturing claim details, scheduling repair quotes, and providing instant payments, where possible. Despite these advances, the task-based repertoire of current chatbots are currently limited to single tasks or a small set of tasks where user conversations involve filling in a small number of frames, typically one or two.
This article provides a domain-specific exposition, drawn from social welfare, on how chatbots can scale customer service delivery processes in corporate sectors. Services in social welfare have long-running processes, with multiple steps, stages and user goals, and carry increased data exchange through service interactions compared to the examples above. They involve a mixture of customer, self-assistance interactions and staff-assistance through call centers and service centers and their processes are managed through customer relationship management and other enterprise systems. The nature of the service processes and service dialogue is studied to understand how user conversations associated with different users goals align with, and are interweaved through, long-running delivery processes. As a result of empirical insights, an architectural strategy which supports enhanced tight-coupling of chatbot systems and service delivery systems, is proposed. Through this, we identify the key challenges for developing and integrating dialogue models and service delivery processes, through extensions to machine learning techniques and provide recommendations.
Empirical Method
Our study of a complex service domain relates to a large provider of social welfare services in a Commonwealth country. Its services, involving unemployment benefits, family support, medical insurance payments, senior pensions, and many other payments, are among the highest in volume and complexity for customer services. The agency provides call centers, service centers, a website and mobile applications among its channels to support customers across many demographics, needs, and vulnerabilities, to access payment-based and other assistance services. It utilizes whole-government, one-stop shop service centers and websites and third-party partner systems as further channels.
First, we conducted an archival analysis of service delivery process steps and customer journey maps at the same time with an extensive observation of service delivery interactions to understand the nature of service interactions. With regards to the archival analysis, we reviewed the organization’s existing service delivery process steps and customer journey maps for the top one hundred (the most requested services) which were designed by the service management, analytics, channel management, IT, and enterprise architecture groups at the organization. These process steps were in the form of operational guidelines and BPMN process models. With regards to the observation of service delivery interactions, we focused on observing the face-to-face interactions between staff and customers at six major offices in three large cities to further our understanding of the service interactions at a large call center of the organization and observed customer interactions with the self-service technologies (for example, website and chatbot) at the areas of the service offices which were providing computer and internet facilities for customers. Overall, we observed over 250 face-to-face service interactions and over 400 service interactions between customers and the self-service technologies.
Next, given that design of digital services often builds upon contributions from multiple areas of expertise,10,14 we conducted two workshops where experts from several different areas of organization with different areas of expertise participated. In each workshop we discussed the process steps, the challenges and opportunities of digitizing service delivery using intelligent agents, with a focus on complex social welfare services using animated process steps and scenario walkthroughs. Each workshop took three hours with 10 participants including the directors, associate directors, and service support personnel at the service desk management, applications, infrastructure, and business analytics departments within the social welfare agency.
The overall result of these observations and workshops was a deep understanding of the nature of services and service process steps at the organization and different patterns of service interactions from the customer’s perspective, which also led to modifying some of the service delivery process steps at the organization. Our insights from these methods are presented later. These insights helped us to move to the next step which is designing protocols for focus groups and individual interviews to understand how the patterns of service interactions need to correspond to the back-end processing of the interactions, enabling us to propose recommendations for developing an architectural strategy for integrating chatbots and service delivery systems.
Figure. Current and future state strategy for integrated chatbots and service delivery systems.
We then conducted six focus groups (on average, 12 people in each focus group, each of which took sixty to ninety minutes) and twelve individual interviews (on average, 60 minutes each interview) were conducted. Participants were different individuals within the same groups of participants who had attended the two workshops (that is, directors, associate directors, and service support personnel at the service desk management, applications, infrastructure, and business analytics departments within the agency). We followed Miles et al.21 for our thematic analysis of the individual interviews and followed Nili et al.24 for thematic analysis of focus groups. The researchers in the team discussed the thematic analysis process and the findings iteratively at five meetings, resulting in compete consensus among the researchers on the insights we gained from the data.
The overall insight from individual interviews and focus groups was that the heart of the challenge of chatbot scalability in the corporate sector is integration of customer dialogue processes with task-based service delivery processes (in an interweaved way), which existing chatbots do not provide. In this regard, we also identified major challenges including: the challenge of chatbot systems and service delivery systems be properly integrated, and the need for assisted learning of dialogue models be done coherently with service delivery processes. Drawing upon the insights we gained from these methods, we explain the current state architecture and its technical capabilities and propose recommendations for a future state architectural strategy for integrating chatbots and service delivery systems in the corporate sector, contextualized through the social welfare domain. Moreover, the details of the systems involved (for example, channel applications and service delivery systems) are also shown in the current and future state architecture covered and depicted on the left-hand side of the accompanying figure.
Background on Customer Service Delivery in Social Welfare
Organizations in the finances, energy, government, and other corporate sectors provide a wide range of product-oriented services for diverse customer segments, needs, and circumstances.4,8 Unlike the delivery of ‘everyday’ consumables through e-commerce applications, examples such as home loans and insurance claims carry higher risk, longer cycles (days, months, or years) and mutual exchange of personal, agency and third-party data, making them difficult to be delivered seamlessly through a self-managed set of steps online.18 This is especially the case for social welfare services, sought by individuals, families and other social groups, across a wide spectrum of demographics and temporary or permanent vulnerabilities (for example, unemployed, aged, single parents and child custodians, disabled, and students).7,23
Many social welfare service types across different domains are offered through government social welfare providers through different types of payments (for example, aged pension, medical insurance, unemployment benefits, and paid parental leave), concessions (for example, public transport, and health services) and tenancies (for example, public housing).23 Not only is service matching complex given the range of needs and circumstances of customers that need to be properly elicited and evidenced, but access to these is subject to equity and transparency regulated by legislated policy and business rules.
Services are delivered through a combination of front-office interactions that take place via self-serve and staff-assisted channels and ‘back-office processes managed by various service delivery management systems. Many tasks of the service delivery (for example, service matching, filling in claims application forms and tracking claims assessments service access) are available through self-serve channels, reflecting the digital by default strategy advanced by governments in recent years.19 In addition, service and contact centers are available for customers to engage in staff-assisted interactions that are required when they face uncertainties in finding, applying, and accessing, or when they need to be physically present, for example, for meetings or identification processes.13,23
The channels are supported by channel applications, for example, service center applications, contact center systems, self-serve Web and mobile applications, and business center applications. The purpose of these applications is to provide context-specific interfaces for customer and service processes presented to customers or staff, for example, presenting coherent service information for different customer cohorts, supporting service discovery or allowing service application forms to be filled in. The applications are tailored to the processes for specific channel contexts and have dedicated capabilities, for example, customer dialogue scripts used for the call center applications. The channel applications interact with enterprise systems, providing the core processes. These consist of: a customer relationship management system (CRM); a service management delivery system (managing service applications, services for customers, service contracts and obligations and interactions with third-party systems); and a payment engine. We observed the both channel applications, CRM and service delivery management systems were adapted from either bespoke or off-the-shelf enterprise systems (for example, SAP ERP), providing an integration framework for these including shared databases.
A key challenge is to effectively understand specific contexts in the requests, from which the relevant direction of dialogue can proceed, from a choice of dialogue directions.
Self-serve channels can support chatbots for specific and well-understood tasks such as service finding and providing indicators for service eligibility as part of online customer inquiries. Conventionally, chatbots have operated through dialogue management systems, which use natural language processing and semantic knowledge of the domains to parse user requests, infer intents and formulate responses.5 A basic strategy for operating chatbots is to store unstructured question-and-answers through social media, automatically classify these (intent classification), match user queries using these to retrieve recommended responses, and to allow user rating of the recommendations. In this way, internal and external social channels can be harnessed through chatbots. However, more targeted forms of chatbot strategy involved dialogue management, through conversational interactions. This involved identifying key data entities relevant to customer intents, for example, customer identification as frames and customer name, customer identifier, date of birth, and residential address as slots.11 For multi-interaction conversations,3 multiple frames/slots and corresponding dialogue request/response interactions can be coordinated in defined sequences, allowing capture, confirmation, action, and interactions to be coordinated.
Multiple chatbot applications apply, for example, for anonymous customers, identified customers and (internal) staff. These applications operate through specific channels, for example, the chatbots for anonymous and identified customers are available through self-serve and mobile applications while chatbots for staff operate on the business center channel application. We observed that these applications are not currently connected to service delivery systems. They only support channel applications, which control interactions with “backend” service delivery systems.
Search-oriented interactions. When customers pose requests at channels as part of the first stage, or potentially other stages, of service delivery, they typically undergo a general service triage step so that their requests are immediately answered or routed to different tasks, systems or channels for further processing. In the simplest case, the needs are obvious in the request. A service or a related aspect is explicitly provided in a request posed by a customer, for example, get study allowance, aged carer’s allowance or make an appointment for a social worker assessment. The interactions that follow serve to confirm the service need and communicate details about where to access it and the conditions of eligibility and use.
However, in other cases, the service need is either ambiguous or unknown in the request. This can arise when providers offer a variety of services for similar customer segments and circumstances, for example, the set of welfare benefits for single parents, which vary depending on whether parents are working full/part-time or not, have direct custody of dependents or not, or are biological parents or custodians of dependents. As such, the indications of needs in requests must be ‘unpacked’ through question-answer dialogue. The key challenge as part of this is to effectively understand specific contexts in the requests, from which the relevant direction of dialogue can proceed, from a choice of dialogue directions—for example, as seen through dialogue scripts used by staff in call and service centers.
There are at least three types of contexts at play when customers present requests in which they are uncertain or unaware of the services relevant for their needs. The first is a customer’s personal context (or circumstances). The nature of the need may be couched in terms of customer circumstances or more directly in terms of service needs for circumstances. The second type of context for open-ended requests concerns services, whereby a service or service area is indicated through, or can be inferred from, a request. For example, when the need for unemployment benefits is requested by a customer, the dialogue is directed to confirm the service area or specific service stated by the customer and the circumstances of customers relevant for the service, for example, the customer’s age, any existing services being provided and any current, part-time employment, and income level. It may turn out that instead of unemployment benefits, a customer needs either youth allowance, parenting payments, unemployment benefits, or the aged pension, depending on their age and dependent responsibilities. The third context is a situational context, such as an event or occurrence, which in some way implicates a customer’s circumstances or needs and may trigger the discovery of required services or action in relation to existing services being accessed. As examples, emergencies such as flooding, industrial action or changes to social welfare policy may be reported, requiring triage-style dialogue involving details of the situation, in order to determine specific concerns, incidences, or needs of customers. This can then be used to determine further course of interactions in relation to customer and service contexts.
Action-oriented interactions. Most stages of service delivery, notably those that occur after service needs have been identified, involve actions on the part of both customers and providers. Examples of actions include customer registrations, filling and lodging application forms, assessment checking for eligibility and entitlements, negotiations for service offers, and service on-boarding tasks. While the nature of actions varies widely, we observed common characteristics in terms of their service interactions. Action-oriented interactions can be more cognitively targeted than search-oriented interactions because the services typically known when action are requested, specific information is involved, and the tasks are deterministic, compared to more open-ended nature of service discovery.
Consider a prominent action task, involving the filling in application forms, which follows service needs being identified and customers being registered. The details relate to their circumstances with over 150 data fields for information, such as: customer identity, relationships, dependencies, employment, and details about existing services or claims, and information from third-parties, for example, taxation reference, study course transcripts, medical certificates, and income pay details. When filling in application forms, people may have questions concerning uncertainties in the form, commitments being made, corrective actions and tracking of progress. Examples of questions which trigger interactions include: the meaning of data fields such as dependents, where the applicant does not have custody of children and does not live at the same address as them; the interpretation of defacto partner for a recently formed relationship where both partners live at a parent’s residence; and the privacy implications for providing consent to the agency to obtain information about the customer from a third-party organization like the tax agency.
In more complex cases of questions, customers may query the interpretation of service eligibility or entitlement rules related to their circumstances, as required to be captured in the form. Examples of commitments include provision of data that is missing and agreeing to provide consent to the provider to get information from a third-party agency. Although updates and corrections are often made during the claims application process, we observed corrective actions being ones that are formal (for example, making appointments for social worker assessments or contesting decisions for assessment outcomes). Tracking involves targeted and straight-forward questions about the claims processing and assessment progress.
Architectural Strategy for Integrating Chatbots and Service Delivery Systems
Chatbots have been designed for efficient natural language interactions with users and are managed through dialogue management systems and knowledge (frame-based dialogue systems), which are decoupled from service delivery systems—with no data sharing and limited process integration with service delivery systems. This raises uncertainties about how chatbots could be more effectively integrated and exploited through service delivery systems, and how service interactions handled by both chatbots and channel applications could be better integrated, leading to an enriched and a coherent user experience. To open up insights in this regard, we elaborate on key limitations of how chatbots are architected to operate with service delivery systems and, accordingly propose recommendations for a future state architectural strategy. The figure depicts the current and future state architectural strategy, referred to in the discussion of the recommendations.
The architectural strategy is extended from the current state of service delivery operations and systems, as discussed earlier. As such, it addresses the following aspects: channel user interfaces which govern the types of interactions and modalities that can be supported; channel applications which coordinate the resources that can be engaged in service interactions (self-serve or staff-assisted); dialogue management system managing the dialogue-related knowledge using frames and dialogue interactions sequences which refer to the frames; the service delivery systems through which service interactions and tasks are coordinated, notably customer relationship management and service delivery management systems. The aspects of the current state architecture were drawn from our empirical analysis. Using this structure, the future state analysis for scaling up chatbots in an integrated service delivery systems architecture is discussed in the following (noting that the blue arrows between the components are the architectures signify key differences).
Context-Awareness of Dialogue Intents and Conversations in Customer Interactions
The wide-ranging set of requirements that customers seek at different stages of service delivery involve distinct contexts, specific to customers, services, or events. As analyzed through the public social welfare agency, customers typically nominate circumstances when they are uncertain about which services are suitable for them. In this case, service delivery interactions focus on determining service needs based on customer contexts. In cases where customers request services, the focus is on service contexts, while specific aspects of services such as eligibility checks result in interactions that relate to customer contexts.
However, current approaches for dialogue management make no distinction between such distinct contexts. Rather, a singular dialogue context is captured, through relevant frame and slot-filling method, and chatbots determine dialogue intents from customer requests against this. Existing chatbot architectures do not address scenarios that involve multiple goals to be addressed in a single conversation. For example, a customer could start a conversation with a search-oriented interaction such as, “Am I eligible for any payment if I am studying and working for a few hours per week?” the chatbot needs to capture minimal details of the customer to determine one of more payment services the customer may be eligible for and further capture specific details that are required to identify the customer’s eligibility for the payment. These complex scenarios cannot be captured by having singular dialogue graph that is often the design approach of enterprise chatbots using frame-based dialogue management.
For the future state, we recommend that distinct contexts be managed through the dialogue management system and used to direct conversations. As illustrated in the figure’s architectural strategy, a general dialogue context (or dialogue state) can be used to orchestrate overall dialogue flow. It can be used to generally triage intents and coordinate dialogue related to customer, service or event contexts. As an example, when a customer describes the need for financial support related to food, rent, and transport, the customer context can be used to direct the conversation to identify the customer circumstances such as income, dependencies and other circumstances. Once this is determined, the conversation can shift to service eligibility rules, among others, which is supported by specific dialogue knowledge for the service context.
Accordingly, we propose: chatbots should be retrofitted into a multi-faceted contextual-aware service delivery, where dialogue can be effectively anchored, directed, and sustained through distinct contexts to meet user goals. The distinct contexts (general, customer, service and event) are implemented through corresponding respective service, customer and event models of the dialogue system.
To support and distinguish search-oriented and action-oriented interactions with the customer, it is useful to maintain different contexts. The customer model would consider frames and slots related to the customer and customer circumstances. By ‘model,’ we refer to the behavioral specification of the dialogue (or dialogue policy). During a search-oriented interaction, the goal of the dialogue would be to capture relevant and optimal information about the customer. For action-oriented interactions the focus would shift to capturing or retrieving information about the service. To support relevant interactions, the dialogue policies or rules of customer, service, or event model are handcrafted as a set of production rules. A production rule is a condition-action pair. The rules consider the conditions pertaining to customer, service or event context. The action could involve seeking more details from the customer, retrieving information of a service, or handing off to a staff agent when the conversation cannot be handled further.
The production rules when chained together implicitly result in dialogue graphs. Each context specific dialogue graph is aligned to the business process tasks and business rules of the service delivery system. The alignment of contextual dialogue graphs to the underlying business process of service delivery system ensures that actions of the chatbot are coherent with the actions directed by the system when the customer uses other channels such as a web-based interface or a staff-assisted enquiry. Designing dialogue rules and constructing the dialogue graphs as a sequence of possible interactions can be time-consuming, expensive and intractable. The interleaving of different contextual models further makes it difficult to choose an optimal rule for dialogue designer. Additionally, the coverage and completeness of production rules and dialogue graphs is difficult to assess given distinct ways of customer interactions. Hence, learning from real-world conversations is imperative.
There are multiple techniques to generating optimal dialogue graphs dynamically: reinforcement learning, automated planning. Optimality could be the cardinality of customer interactions that leads to customer meeting their set goal. In reinforcement learning, the dialogue manager learns from dialogue conversations based on the feedback from the customer or a staff agent supervising the chatbot responses.15 The feedback collected at the end of the conversation between the chatbot and the customer is used to refine dialogue trees. Based on the feedback rewards or penalties are applied to the refine the conversation. Another approach of generating dialogue tree is to use automated planning. A non-deterministic planner is used to orchestrate the production rules. Given the complexity of service system rules and artifacts, use of learning approaches or automated plan generation approaches to generate dialogue graphs of a large service delivery systems is still an open research challenge and their suitability needs to be ascertained. Hence, we propose they are used with traditional proven and reliable hand-crafted dialogue trees.
Context-awareness of service delivery execution in customer interactions. Service delivery systems manage information related to customers and services required for managing service delivery tasks while dialogue systems provide knowledge contexts related to customers and services required for managing dialogue interactions. However, in the current state, no alignment exists across service delivery and dialogue systems in relation to customer, service and event information. This can lead to redundancies and inconsistencies concerning this information across both systems, for example, the management of customer circumstance attributes related to service eligibility is captured in both frames of dialogue management systems and business rules of service delivery systems. More problematically, dialogue systems do not fully leverage detailed information available in service delivery systems. For example, the conditions for service eligibility, circumstance reporting obligations and penalties of violating obligations, could be provided to users and further clarified through dialogue interactions and information displayed in the user interface information.
If service models and service data in service delivery systems were aligned with dialogue management, the data returned from systems could be updated into concretely specified slots of frames and be used as part of user interactions.
If service models and service data in service delivery systems were aligned with dialogue management, the data returned from systems could be updated into concretely specified slots of frames and be used as part of user interactions. The frames and the slots could be filled with the data retrieved from the service systems data for dialogue construction. In addition, dialogue frames and slots could be specified abstractly, with data retrieved from service systems data for dialogue to then be constructed flexibly. For example, a customer identification frame could have slots determined from systems data, such as customer reference number, customer name, residential address, and marital status. This way, frames related to customer identity could be concretely refined (expanded) through identity information in customer profiles managed by service delivery systems. Likewise, details about what services offer (for example, payments and concessions), their claim forms, conditions of access, among others can be linked directly through an abstract-concrete data alignment relationship between dialogue and service delivery systems. Such relationships would also allow for dialogue models to automatically support changes to data at the service delivery systems level.
We therefore propose: chatbots should be integrated with service delivery processes, such that dialogue interactions and systems interactions are effectively integrated.
As indicated in the figure, to support transparency of data at the service delivery systems level for alignment with dialogue models of dialogue management systems, we recommend support for dedicated masters data repositories for customers profiles and service catalogues.23 For example, service catalogues store information such as service delivery processes, service tasks and their inputs/outputs, and service level agreements, can be fully referred to and aligned with service dialogue models. Access to execution state of services can further enrich service dialogue contexts.
Supporting a tight integration of the chatbot interactions with the service delivery system requires the frames and slots need to be aligned to the artifacts of the service delivery system. The dialogue actions further need to invoke relevant service operations with the inputs as slot values and interpret the results of the service delivery system into responses. The dialogue production rules that lead to calling the service operations with relevant input values of slots need to be hand-crafted by the dialogue designer. This can be time-consuming and expensive to specify and maintain for all possible customer interactions, especially in scenarios where there are hundreds of services operations with different input parameters. Often, it is feasible for the dialogue designers to account for the most common dialogue interactions rules where the integration with one or more service operations is specified.
To alleviate the cost and effort of building the dialogue actions for all scenarios, deep neural networks have been explored to train dialogue manager. Recent studies have explored the use of end-to-end training of task-oriented dialogues. Here, a chatbot is trained with the dialogue conversations that allows it to learn all tasks in the dialogue pipeline: slot filling, dialogue state management, and the dialogue actions including making calls to specific service operations.15 Although these approaches have gained research attention, their applicability for goal-oriented chatbots comprising of multiples frames and several slots is still a challenge. End-to-end neural network-based models need for large amounts of hand-curated data before they start generating a coherent and fluent response. They further provide no control on the actions chosen by the chatbot.20 Their advantage, however, is the ability to memorize and learn from past conversations and can be suitable for learning the actions when new slot values are encountered, the sequence or the sets of services operations that can be called, or when certain exceptions occur in the dialogue interactions not recorded dialogue designer.
To alleviate the cost and effort of building the dialogue actions for all scenarios, deep neural networks have been explored to train the dialogue manager.
Accordingly, we propose: chatbots should use the hybrid approach of using traditional frame-based method in conjunction with end-to-end neural network-based learning to support reliable common dialogue interactions and distinct staff-assisted customer interactions.
In the hybrid approach, scenarios, where the frame-based dialogue management fails to provide suitable response indicated by long conversations or user requesting staff-assistance, the dialogue is first directed to a staff agent to continue, and close the conversation. The staff agent responds to the customer and invokes relevant calls to the service delivery system. The conversational data containing the responses and the invocations to the service operations is used to train the end-to-end neural network-based dialogue manager. The model is trained to identify slots, provide the relevant response, invoke the relevant service operations of the service delivery system. The chatbot learns from the newly accumulated data.
The approach benefits from the use of an optimal subset of real-world conversations to teach the chatbot.29 Hence, the training data only contains conversations that the chatbot needs to learn for future interactions.16 Updates to production rules, resulting from changes in government policies or service delivery rules, are updated by dialogue designers. The end-to-end data-driven model would re-learn from the staff assisted conversations when such updates are made. For example, if policies related to an age pension changes and the dialogue rules are updated, the neural network model is re-trained with the new dialogue conversations related to age pension. The hybrid approach allows the chatbot to use the reliable and traditional frame-based approach for a standard set of scenarios, and end-to-end dialogue learning with machine teaching by staff assisted conversations for other alternate dialogue interactions.
To support the hybrid approach to learning from human-assisted teaching and feedback, the conversation from a chatbot can be routed to a contact center. Similarly, when customers are assisted through calls, they should be automatically routed to other staff, systems or even chatbots, depending on how manageable the required action is. A future-state service delivery system should provide pro-active processes where the right forms of channels and interactions are available and pre-empted where possible, depending on in-situ customer needs.
Thus, we propose: chatbots should operate as part of a coherent, multi-channel service delivery process aimed at a consistent, predictable and proactive interactions. This means the delivery processes need to be carefully orchestrated to use delivery resources including staff in different delivery roles and chabots, in a way that is consistent and avoids delivery latencies for customers.
Our proposed architectural strategy supports service delivery via a chatbot that requires dialogue graphs or the models to consider different contextual elements of the social service domain and support distinct customer interactions. The interactions are aligned with the underlying service delivery process. As interleaving these interactions into a tractable dialogue graph is difficult, data assisted learning methods can be used to generate the optimal dialogue graphs. Further, a tight integration of the chatbot with the service delivery system is required to provide coherent interactions to the customer, consistent with interactions via other channels. To provide such a tight integration for all dialogue interactions, we suggest a hybrid approach that combines frame-based dialogue management with an end-to-end neural network-based machine taught dialogue manager.
Conclusion
In this article, we presented important insights of corporate service delivery, drawn from the public sector, in order to elicit key ways in which chatbot systems can be applied and extended in this setting. Our contributions were twofold. Firstly, we provided an exposition of multi-channel service delivery systems involving both self-serve and staff assisted interactions and the different types of interactions that customers encounter across different stages of service delivery. In particular, this shed light on the different systems contexts that chatbot systems need to couple with (for example, front-end channel applications and service delivery systems) and the specific dialogue management foci that are in play for different service delivery interactions.
Building upon these insights, our second area of contribution related to four key recommendations for chat-bot integration with service delivery systems are: dialogue management for customers, services and events, for effective targeting of dialogues for specific service delivery tasks; alignment and integration of dialogue management with service delivery processes and data; hybrid approach that uses traditional frame-based dialogue management in conjunction with human-teaching and feedback based end-to-end neural network-based dialogue management; and multi-channels allowing chatbot and staff to co-opted for assistance tasks. Future work can focus on detailed design, development and experimental analysis of these recommendations with corporate systems not only in the public sector but also in any sector featuring complex customer services.
Figure. Watch the authors discuss this work in the exclusive Communications video. https://cacm.acm.org/videos/scaling-up-chatbots
Join the Discussion (0)
Become a Member or Sign In to Post a Comment