System and method for managing dialog between contact center system and user thereof

Abstract

To provide a telecommunication system and method for managing contact center operations and dialog therein.SOLUTION: A method for managing dialog in a contact center employing intent detection and context switching includes receiving input from a dialog; setting an intent and executing a root behavior tree to manage the dialog; executing at least one first-level behavior tree; managing the dialog via automated components to generate appropriate responses to a user; detecting a match with a new intent and modifying a sequence of execution in response to the newly detected intent; and outputting a new action.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present invention relates generally to telecommunications systems and methods, and more particularly to the operation of contact centers and the management of interactions therein. [Background technology]

[0002] In many contact center operations, interactions with and between users (this term includes contact center agents, customers or external parties communicating with the contact center, and contact center automated systems involved in communications with other users) are managed according to interactions, which are sequences of inputs and outputs within the context of a communication session.

[0003] In its simplest form, interactions may take the form of scripts employed by contact center agents to manage conversations with external parties. Scripts are written with a specific purpose in mind: to ensure a satisfactory interaction, to sell or provide a service, or to efficiently handle interactions with external parties. Such scripts suffer from the drawback of being relatively rigid and inflexible.

[0004] A further difficulty with this approach arises when attempting to automate the execution of a script to create a series of prompts at an agent workstation, for example, where the presentation of the prompts depends on the progress of the interaction so far. It can be difficult or impossible to predict how a particular interaction may develop, due to unexpected responses or questions, or simply because unpredictable variations in human interaction can lead the parties to jump between topics where individual requests are met within the script but there is no functional link from one topic to another.

[0005] A traditional approach to automating interactions within contact centers is to employ finite state machines (FSMs) to manage the interactions. Such models envision a set of states (i.e., the current point in the interaction or script, which determines the prompts presented to the agent) and associated transitions that define one or more actions to be performed when a condition is met or an event is detected, for example, to move execution to another state, trigger an automated contact center system, or terminate the interaction. Satisfactory operation of interactions using the FSM paradigm presupposes that all transitions are properly modeled, i.e., that at a given point in the interaction, received inputs and events are mapped to appropriate next steps. For reasons already mentioned, real-world interactions and conversations often deviate from their expected course, and FSM models can break if there is no defined transition for a given event or input. This can cause the script to either revert to common fallback points or erroneously navigate toward a prompt that is inappropriate for the input due to the lack of a better transition, potentially depriving the agent of any useful prompts. CROSS-REFERENCE TO RELATED APPLICATIONS

[0006] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 938,951, entitled "SYSTEM AND METHOD FOR MANAGING A DIALOG BETWEEN A CONTACT CENTER SYSTEM AND A USER THEREOF," filed with the U.S. Patent and Trademark Office on November 22, 2019. Summary of the Invention

[0007] A system and method for managing interactions between a contact center system and its users is presented. In one embodiment, a computer-implemented method for managing interactions between a contact center system and its users is provided, comprising the steps of: storing a root behavior tree including at least one flow control node and a plurality of child nodes, the at least one flow control node determining a sequence of execution of the child nodes; storing at least one first-level behavior tree that can be executed to accomplish a task having an associated intent, the at least one first-level behavior tree being a child node of the root behavior tree, the at least one first-level behavior tree including nodes that define actions to be performed by components of the contact center system; and communicating between the contact center system and its users. Detecting, by the processor, a match between the input from the interaction and a pattern of data, modifying a sequence of execution in the root behavior tree or at least one further behavior tree upon detecting a match, and providing an output in response to the modified sequence of execution to cause the contact center component to perform one of the actions.

[0008] Compared to conventional methods of managing dialogue, such as using finite state machine models, the present method is better adapted to dynamically change the dialogue in response to detected patterns of data from the dialogue, such as when a context switch is detected that indicates a need to comply with a new intent. Whereas conventional techniques require script to be encoded within the transition for each such context switch, the behavior tree model employed in the present method allows execution to be smoothly handed off to another part of the behavior tree or to at least one further behavior tree in a more seamless and adaptive manner.

[0009] In one embodiment, the pattern of data is associated with an intent that indicates a change in the sequence of execution required within the root behavior tree of at least one further behavior tree.

[0010] In one embodiment, the pattern of data is a predefined pattern of data stored in a memory accessible by the processor.

[0011] In one embodiment, the pattern of data is generated dynamically during the execution of the method.

[0012] In one embodiment, the patterns of the data are modified according to learned behavior after one or more iterations of execution of the root behavior tree or at least one further behavior tree.

[0013] In one embodiment, the interaction is conducted via a communication channel between the user and an automated conversation bot at a contact center, and the output is effective to redirect the communication channel to a communication device used by a human agent at the contact center, thereby placing the user in a conversation with the human agent.

[0014] In one embodiment, the interaction in step is conducted via a communication channel between the user and a communication device used by a human agent at the contact center, and the output is effective to redirect the communication channel to a different communication device used by a different human agent at the contact center, thereby placing the user in a conversation with the different human agent.

[0015] In one embodiment, the detected match is with a pattern in the data that indicates that escalation from one human agent to another human agent is required.

[0016] In one embodiment, the different human agent is a supervisor.

[0017] In one embodiment, the at least one first level behavior tree is defined to catch an exception and, in response to catching the exception, cause execution to return to the root behavior tree.

[0018] In one embodiment, the method further includes storing a plurality of additional behavior trees, at least one of which is a child node of the first level behavior tree.

[0019] In one embodiment, another one of the plurality of further behavior trees is a child node of the at least one further behavior tree.

[0020] In one embodiment, the method further includes storing a current context state that determines the sequence of execution of the running behavior tree, and detecting, by the processor, a match between input from the interaction and a predefined pattern of data associated with a context switch.

[0021] In one embodiment, in response to detecting a match associated with a context switch, the context switch is stored as an intent for future execution.

[0022] In one embodiment, in response to detecting a match associated with a context switch, execution is transferred from the behavior tree being executed to a different behavior tree.

[0023] In one embodiment, the method is recursive and involves multiple nested context switches.

[0024] In one embodiment, the predefined pattern of data includes multiple nested context switches.

[0025] In one embodiment, at least one child node of a behavior tree selected from one of the root behavior tree, the first level behavior tree, and the further behavior tree is an output that causes a message to be provided at a contact center device operated by the agent.

[0026] In one embodiment, at least one child node of a behavior tree selected from one of the root behavior tree, the first level behavior tree, and the further behavior tree is an output that causes a message to be sent to the user.

[0027] In one embodiment, at least one child node of a behavior tree selected from one of the root behavior tree, the first level behavior tree, and the further behavior tree is an output that causes a request to be sent to an automated system associated with the contact center.

[0028] In one embodiment, in response to the request, a response is received from the automated system, the response being an input used in determining the execution of the current behavior tree.

[0029] In one embodiment, at least one child node of a behavior tree selected from one of the root behavior tree, the first level behavior tree, and the further behavior tree defines an action that causes communication with a user to be transferred from an automated interaction to a live interaction with an agent of the contact center system.

[0030] In one embodiment, at least one child node of a behavior tree selected from one of the root behavior tree, the first level behavior tree, and the further behavior tree defines an action that terminates communication with the user.

[0031] In one embodiment, at least one child node of a behavior tree selected from one of the first level behavior tree and the further behavior tree defines an action that causes execution to be transferred to the root behavior tree.

[0032] In one embodiment, the method further includes generating a learned behavior tree from data obtained from previous interactions, the learned behavior tree optimizing a goal of the contact center.

[0033] In one embodiment, the method further includes expanding the learned behavior tree as a child node of an existing stored behavior tree.

[0034] In one embodiment, at least one node of a behavior tree is defined as a memory node having an execution flag and associated with a memory, whereby upon execution of the memory node, data is stored in the memory and the execution flag is marked, causing execution of the memory node to be skipped in subsequent iterations of the behavior tree of which it forms a part.

[0035] Also provided is a system for managing interactions between a contact center system and its users, the system comprising: a processor; and a memory, the memory storing instructions that, when executed by the processor, cause the processor to: store a root behavior tree including at least one flow control node and a plurality of child nodes, the at least one flow control node determining a sequence of execution of the child nodes; and store at least one first-level behavior tree that can be executed to accomplish a task having an associated intent, the at least one first-level behavior tree being a child node of the root behavior tree, and the at least one first-level behavior tree determining actions to be performed by components of the contact center system. a system for storing a behavior tree including nodes defining interactions between the contact center and its users, the interactions being conducted over a communication channel between the users and a contact center component; receiving input from the interactions; executing a root behavior tree and the at least one first-level behavior tree as child nodes of the root behavior tree in response to the input; detecting a match between the input from the interactions and a pattern of data; altering a sequence of execution in the root behavior tree or the at least one further behavior tree upon detecting the match; and providing an output in response to the altered sequence of execution to cause the contact center component to perform one of the actions.

[0036] In another embodiment, a computer-implemented method for supporting an agent of a contact center system engaged in an interaction with a user is provided, the method including: receiving, by a processor, input from an interaction conducted over a communication channel between the agent and the user; storing a knowledge base including a plurality of entries, a subset of the entries being defined as high priority entries; detecting, by the processor, a match between the input from the interaction and a plurality of the knowledge base entries; retrieving at least one of the plurality of entries corresponding to the match; and pushing the at least one of the plurality of entries as an output to one or more of a device operated by the user and a device operated by the agent; detecting, by the processor, a further match between the input from the interaction and a high priority entry in the knowledge base; and pushing the high priority entry to a device operated by the agent while the interaction is ongoing.

[0037] In one embodiment, the high priority entry includes one or more prompts to the agent device directed to achieving a defined goal.

[0038] In one embodiment, the at least one device is a device used by the agent, and the one or more prompts coach the agent to achieve a defined goal.

[0039] In one embodiment, the method further includes the processor continuing to receive input from the interaction and, in response to the detected input, pushing updated prompts to the agent, thereby coaching the agent through the interaction.

[0040] In one embodiment, a behavior tree is defined to implement match detection, where the behavior tree runs throughout the duration of an interaction and receives input from the interaction, whereby a detected match causes processing within the behavior tree to be transferred from one node of the tree to another node of the tree.

[0041] There is also provided a system for supporting agents of a contact center system engaged in an interaction with a user, the system comprising: a processor; and a memory, the memory storing instructions that, when executed by the processor, cause the processor to receive input from an interaction conducted over a communication channel between the agent and the user; access a knowledge base including a plurality of entries, a subset of the entries defined as high priority entries; detect a match between the input from the interaction and a plurality of the knowledge base entries; retrieve at least one of the plurality of entries corresponding to the match; push the at least one of the plurality of entries as an output to one or more of a device operated by the user and a device operated by the agent; detect further matches between the input from the interaction and a high priority entry in the knowledge base; and push the high priority entry to the device operated by the agent while the interaction is ongoing.

[0042] In a further aspect, a computer-implemented method for managing interactions between a contact center system and its users is provided, the computer-implemented method including the steps of hosting an interaction over a communication channel between an automated dialogue engine of the contact center and the user, the interaction including messages sent in both directions between the automated dialogue engine and the user; receiving, by the automated dialogue engine, an input message from the user; determining a response message in response to the input; detecting a trigger event from the message of the interaction that matches a rule; providing a summary of the interaction to the agent station in response to detecting the trigger event; and providing control of the automated dialogue engine to the agent station.

[0043] In one embodiment, the method further comprises pausing the automated dialogue engine from providing a response message after detecting the trigger event.

[0044] In one embodiment, the summary includes a transcript of the interaction, hi another embodiment, the summary includes information obtained from multiple data sources based on the interaction.

[0045] In one embodiment, the presentation of response messages is paused until an appropriate response message is selected at the agent station.

[0046] In one embodiment, the agent station is provided with a number of possible response messages by the automated dialogue engine and is allowed to select an appropriate response message from among them.

[0047] In one embodiment, the appropriate reply message is selected by composition of a message by a user of the agent station.

[0048] In one embodiment, after detecting the trigger event, the automated dialogue engine continues to autonomously determine and send response messages unless a control command to pause providing response messages is received from the agent station.

[0049] In one embodiment, the trigger event is determined by a rule matching a condition selected from determining keywords in one or more input messages, determining sentiment in one or more input messages, determining a change in speech volume or pitch, determining that an input message cannot be properly interpreted, determining that a response message cannot be determined in response to an input message, determining that a confidence level associated with a potential response message is below a predetermined threshold, determining that one or more input messages relate to a topic defined as requiring agent intervention, determining that one or more input messages relate to a topic defined as requiring agent intervention, and determining that agent intervention is requested by the user of the contact center.

[0050] In one embodiment, the method further includes the automated dialogue engine modifying the rules according to which a response message is generated in response to observing the control input received from the agent station.

[0051] There is also provided a system for managing interactions between a contact center system and its users, the system comprising: a processor; and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate an automated dialogue engine system engaged in an interaction hosted over a communication channel between the contact center and the user, the interaction including messages transmitted in both directions between the automated dialogue engine system and the user; accept input messages from the user and determine response messages in response to the input; detect trigger events from the messages of the interaction that match a rule; and, in response to detecting the trigger event, provide copies of the messages of the interaction to the agent station; and provide control of the automated dialogue engine to the agent station. [Brief explanation of the drawings]

[0052] [Figure 1] FIG. 1 illustrates an embodiment of a contact center system.

[0053] [Figure 2] FIG. 1 illustrates one embodiment of the logical architecture of a conversation orchestration engine.

[0054] [Figure 3] FIG. 1 illustrates one embodiment of a system architecture for a dialogue engine.

[0055] [Figure 4] FIG. 1 illustrates one embodiment of a system architecture for a dialogue engine.

[0056] [Figure 5] 1 is an example of a behavior tree structure used by a conversation orchestration engine.

[0057] [Figure 6] 1 is an example of a behavior tree structure used by a conversation orchestration engine.

[0058] [Figure 7] 1 is an example of a behavior tree structure used by a conversation orchestration engine.

[0059] [Figure 8] FIG. 1 illustrates one embodiment of the relationship between intent, context, and behavior trees.

[0060] [Figure 9] 1 is a flowchart of the operation of the conversation orchestration engine.

[0061] [Figure 10] 1 is a flowchart for supporting an agent of a contact center system engaged in an interaction with a user.

[0062] [Figure 11] 1 is a flowchart of a method for managing interactions between a contact center system and its users.

[0063] [Figure 12A] FIG. 1 illustrates an embodiment of a computing device such as may be employed in an embodiment of the present invention. [Figure 12B] FIG. 1 illustrates an embodiment of a computing device such as may be employed in an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0064] For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. Notwithstanding the foregoing, it will be understood that no limitation on the scope of the invention is intended. Any changes and further modifications in the described embodiments, and any further applications of the principles of the invention as described herein, are contemplated as would normally occur to one skilled in the art to which the invention pertains.

[0065] In a contact center environment, a dialogue may typically involve a conversation between two or more parties (e.g., a customer, an agent, and / or a system) to resolve a problem, fulfill a request, or otherwise accomplish some task / achieve some goal. The conversation may be conducted via various media channels, such as voice, chat, desktop, or web, to name a few non-limiting examples. An engine (e.g., a dialogue engine) may be used to understand the state of the dialogue at every turn. A turn may include an event from any party to the conversation or interaction, such as a response or question. The dialogue engine may further be used to control the next action taken via the system to move the conversation toward contact center or business goals. The dialogue engine includes "conversational AI," which further includes making context-aware decisions through interactions with customers in natural language, multimodal media. Actions may be directed to the parties in various ways. For example, actions may be directed to the customer via a message within the channel of the dialogue. In another example, the action may be directed to the agent by directly recommending a response to the agent or indirectly recommending a response as a coaching tip or other assistance guide on the agent's desktop. In another example, the action may be directed to the system in the form of an information request or the fulfillment of an appointment.

[0066] Conversational AI (or conversational artificial intelligence) presents several challenges to contact centers and enterprises, including uncertainty, multimodality, conversation, and complexity. Natural language understanding (NLU) used within conversational AI is prone to errors, making systems employing conversational AI uncertain. For example, parties can take the initiative in the dialogue (rather than just directed dialogue), making it difficult to manage the context of the conversation. Conversational AI is a multimodal experience, not just a simple chatbot. Interactions must be orchestrated between multiple parties, including customers, agents, and systems, to name a few non-limiting examples. In addition, there are many conversational channels (voice, digital, etc.) that must be considered, as well as backend systems that must be integrated with transactional APIs, knowledge bases, enterprise information stores, and so on. Furthermore, interactions must sound conversational and natural. This often means conveying a special type of voice and adapting it to the parties' (customer's and / or agent's) context (customer's and / or agent's). From a complexity perspective, conversational AI typically involves several multi-step processes and domain knowledge integration to orchestrate the journey of the customer and the resources (agents and systems) that make the orchestration and journey happen.

[0067] Behavior trees can be used to process modular, hierarchical, and hierarchically scalable behavior in interactions. Interaction building blocks are constructed and assembled together in a way that allows them to be reused and interactions to be orchestrated. In one embodiment, orchestration is reactive, enabling out-of-turn execution and goal-directed execution (e.g., completing tasks). Behavior trees are also suitable for machine learning and automated planning / optimization. "Slot filling," multi-turn context management, and integration with back-end systems can be achieved. Slot filling can be demonstrated by handling out-of-turn information, over-informing, and prompting for missing information before taking action as needed. Multi-turn context management is demonstrated by turn-wide persistence of intent, turn-wide persistence of slots, and context-aware slot switching. Back-end systems are integrated via plugins for custom actions and API calls, using functions to transform data (e.g., turning a day into a month) for more concise rendering. Behavior trees and their use within a dialogue engine are described in more detail below.

[0068] Contact Center System

[0069] FIG. 1 is a diagram illustrating one embodiment of a communications infrastructure generally designated 100. For example, FIG. 1 illustrates a system for supporting a contact center in providing contact center services. A contact center can be an in-house facility for a business or enterprise to serve the enterprise in performing sales and service functions related to products and services available through the enterprise. In another aspect, the contact center can be operated by a third-party service provider. In one embodiment, the contact center can be operated as a hybrid system in which some components of the contact center system are hosted on the contact center premises and other components are hosted remotely (e.g., in a cloud-based environment). The contact center can be deployed on equipment dedicated to the enterprise or a third-party service provider and / or in a remote computing environment, such as, for example, a private or public cloud environment with infrastructure to support multiple contact centers for multiple enterprises. Various components of the contact center system can also be distributed across various geographic locations and computing environments and need not necessarily be contained in a single location, computing environment, or even computing device.

[0070] The components of the communications infrastructure, generally designated 100, include a plurality of end user devices 105A, 105B, 105C, a communications network 110, a switch / media gateway 115, a call controller 120, an interactive media response (IMR) server 125, a routing server 130, a storage device 135, a statistics server 140, a plurality of agent devices 145A, 145B, 145C including workbins 146A, 146B, 146C, a multimedia / social media server 150, a web server 155, an interaction (iXn) server 160, a universal contact server (UCS) 165, a reporting server 170, a media service 175 which may include a media manager and media instances, and a conversation orchestration engine 205.

[0071] In one embodiment, a contact center system manages resources (e.g., personnel, computers, telecommunications equipment, etc.) to enable the delivery of services over the telephone or other communications mechanisms. Such services may vary depending on the type of contact center and range from customer service to help desk, emergency response, telemarketing, order taking, etc.

[0072] Customers, potential customers, or other end users (collectively referred to as customers or end users) desiring service from the contact center may initiate inbound communications (e.g., telephone calls, emails, chats, etc.) to the contact center via end user devices 105A, 105B, and 105C (collectively referred to as 105). Each of the end user devices 105 may be a communication device conventional in the art, such as a telephone, wireless telephone, smartphone, personal computer, electronic tablet, laptop, etc., to name a few non-limiting examples. Users operating the end user devices 105 may initiate, manage, and respond to telephone calls, emails, chats, text messages, web browsing sessions, and other multimedia transactions. For simplicity, three end user devices 105 are illustrated in 100, although any number may be present.

[0073] Inbound and outbound communications from and to end-user devices 105 may traverse a network 110 depending on the type of device being used. Network 110 may include communication networks for telephone, cellular, and / or data services, including, by way of non-limiting example, a private or public switched telephone network (PSTN), a local area network (LAN), a private wide area network (WAN), and / or a public WAN such as the Internet. Network 110 may also include wireless carrier networks, including code division multiple access (CDMA) networks, global system for mobile communications (GSM) networks, or any wireless network / technology conventional in the art, including, but not limited to, 3G, 4G, LTE, etc.

[0074] In one embodiment, the contact center system includes a switch / media gateway 115 coupled to the network 110 for transmitting and receiving telephone calls between end users and the contact center. The switch / media gateway 115 may include a telephone switch or a communications switch configured to function as a central switch for agent-level routing within the center. The switch may be a hardware switching system or a soft switch implemented via software. For example, the switch 115 may include an automatic call distributor, a private branch exchange (PBX), an IP-based software switch, and / or any other switch having dedicated hardware and software configured to receive Internet-sourced and / or telephone network-sourced interactions from customers and route these interactions to, for example, agent telephones or communications devices. In this example, the switch / media gateway establishes a voice path / connection (not shown) between the calling customer and the agent telephone device, for example, by establishing a connection between the customer telephone device and the agent telephone device.

[0075] In one embodiment, the switch is coupled to a call controller 120, which may act as an adapter or interface between the switch and other communication processing components of the contact center, such as routing, monitoring, etc. Call controller 120 may be configured to process PSTN calls, VoIP calls, etc. For example, call controller 120 may be configured with computer-telephony integration (CTI) software for interfacing with switches / media gateways and contact center equipment. In one embodiment, call controller 120 may include a session initiation protocol (SIP) server for processing SIP calls. Call controller 120 may also extract data regarding customer interactions, such as the caller's telephone number (e.g., automatic number identification (ANI) number), the customer's Internet Protocol (IP) address, or email address, and communicate with other components of system 100 in processing the interaction.

[0076] In one embodiment, system 100 further includes an interactive media response (IMR) server 125. IMR server 125 may also be referred to as a self-help system, a virtual assistant, or the like. IMR server 125 may be similar to an interactive voice response (IVR) server, except that IMR server 125 is not limited to voice and may also cover various media channels. In a voice-illustrating example, IMR server 125 may be configured with IMR scripts to query customers about their needs. For example, a bank contact center may tell customers via an IMR script to "press 1" if they want to retrieve their account balance. Through ongoing interaction with IMR server 125, customers may be able to complete services without needing to speak with an agent. IMR server 125 may also ask open-ended questions such as "How can I help you?" and the customer may speak or otherwise input their reason for contacting the contact center. The customer's response may be used by routing server 130 to route the call or communication to the appropriate contact center resource.

[0077] If the communication can be routed to an agent, the call controller 120 interacts with a routing server (also referred to as an orchestration server) 130 to find an appropriate agent to handle the interaction. The selection of an appropriate agent to route the inbound interaction may be based, for example, on a routing strategy employed by the routing server 130 and may further be based on information about agent availability, skills, and other routing parameters provided, for example, by a statistics server 140.

[0078] In one embodiment, routing server 130 may query a customer database, which stores information about existing clients, such as contact information, service level agreement (SLA) requirements, the nature of previous customer contacts, and actions taken by the contact center to resolve any customer issues. The database may be, for example, Cassandra or any NoSQL database and may be stored on mass storage device 135. The database may also be an SQL database and may be managed by any database management system, such as Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, or PostgreSQL, to name a few non-limiting examples. Routing server 130 may query the customer database for customer information via ANI or any other information collected by IMR server 125.

[0079] Once a suitable agent is identified as available to handle the communication, a connection may be made between the customer and the identified agent's agent device 145A, 145B, and / or 145C (collectively 145). For simplicity, three agent devices are illustrated in FIG. 1 , but any number of devices may be present. Information collected about the customer and / or customer history information may also be provided to the agent device to assist the agent in providing better communication service. In this regard, each agent device 145 may include a telephone adapted for regular telephone calls, VoIP calls, etc. The agent device 145 may also include a computer for communicating with one or more servers of the contact center, performing data processing associated with contact center operations, and interacting with customers via voice and other multimedia communication mechanisms.

[0080] The contact center system 100 may also include a multimedia / social media server 150 for engaging in media interactions other than voice interactions with the end-user devices 105 and / or web server 155. The media interactions may relate to, for example, email, voicemail (voicemail over email), chat, video, text messaging, web, social media, co-browsing, etc. The multimedia / social media server 150 may take the form of any IP router conventional in the art, with specialized hardware and software for receiving, processing, and forwarding multimedia events.

[0081] Web server 155 may include, for example, social networking site hosts for various known social networking sites to which end users may join, such as Facebook, Twitter, and Instagram, to name a few non-limiting examples. In one embodiment, web server 155 is shown as part of contact center system 100, but the web server may also be provided by a third party and / or maintained outside the contact center premises. Web server 155 may also host web pages for companies supported by contact center system 100. End users may browse the web pages to obtain information about the companies' products and services. The web pages may also provide mechanisms for contacting the contact center via, for example, web chat, voice call, email, Web Real-Time Communications (WebRTC), etc.

[0082] In one embodiment, deferrable interactions / activities may also be routed to contact center agents in addition to real-time interactions. Deferrable interactions / activities may include back-office tasks or tasks that can be performed offline, such as responding to emails, letters, participating in training, or other activities that do not require real-time communication with customers. The interaction (iXn) server 160 interacts with the routing server 130 to select an appropriate agent to handle the activity. Once assigned to an agent, the activity may be pushed to the agent or may appear in the agent's work bins 146A, 146B, 146C (collectively 146) as tasks to be completed by the agent. The agent's work bin may be implemented via any data structure conventional in the art, such as, for example, a linked list, an array, etc. In one embodiment, the work bin 146 may be maintained, for example, in a buffer memory of each agent device 145.

[0083] In one embodiment, mass storage device 135 may store one or more databases relating to agent data (e.g., agent profiles, schedules, etc.), customer data (e.g., customer profiles), interaction data (e.g., details of each interaction with a customer, including, but not limited to, the reason for the interaction, processing data, wait times, processing times, etc.), etc. In another embodiment, some of the data (e.g., customer profile data) may be maintained in a customer relations management (CRM) database hosted on mass storage device 135 or elsewhere. Mass storage device 135 may take the form of a hard disk or disk array, as is conventional in the art.

[0084] In one embodiment, the contact center system may include a universal contact server (UCS) 165 configured to retrieve information stored in a CRM database and to direct information to be stored in the CRM database. The UCS 165 may also facilitate maintaining customer preference and interaction histories, and may be configured to capture and store data regarding comments from agents, customer communication history, and the like.

[0085] The contact center system may also include a reporting server 170 configured to generate reports from the data aggregated by the statistics server 140. Such reports may include near real-time or historical reports regarding resource status, such as average wait times, relaxation rates, agent occupancy, etc. Reports may be generated automatically or in response to a specific request from a requestor (e.g., an agent / manager, a contact center application, etc.).

[0086] 1 may each include one or more processors that execute computer program instructions and interact with other system components to perform the various functions described herein. The computer program instructions are stored in memory implemented using standard memory devices such as, for example, random-access memory (RAM). The computer program instructions may also be stored on other non-transitory computer-readable media such as, for example, a CD-ROM, a flash drive, etc. Although the functionality of each of the servers is described as being provided by a particular server, those skilled in the art should understand that the functionality of various servers may be combined or consolidated into a single server, or that the functionality of a particular server may be distributed among one or more other servers without departing from the scope of embodiments of the present invention.

[0087] In one embodiment, the terms "interaction" and "communication" are used interchangeably and generally refer to any real-time and non-real-time interaction using any communication channel, including, but not limited to, phone calls (PSTN or VoIP calls), email, Vmail, video, chat, screen sharing, text messages, social media messages, WebRTC calls, etc.

[0088] Media services 175 may provide audio and / or video services to support contact center functions such as IVR or IMR system prompts (e.g., playing audio files), music on hold, voicemail / single-party recording, multi-party recording (e.g., audio and / or video calls), speech recognition, dual tone multi frequency (DTMF) recognition, fax, audio and video transcoding, secure real-time transport protocol (SRTP), audio conferencing, video conferencing, coaching (e.g., support for a coach to listen to an interaction between a customer and an agent and for a coach to provide comments to an agent without the customer hearing the comments), call analysis, and keyword spotting.

[0089] In one embodiment, the conversation orchestration engine 205 uses AI bots and dialogue services to mediate interactions between end users 105A, 105B, 105C and agents 145A, 145B, 145C to appropriately direct the interactions and respond to inputs as described further below. In another embodiment, the conversation orchestration engine 205 may also mediate interactions between end users and bots in self-service dialogue interactions (i.e., the end user is conversing with a bot without an agent being associated with the interaction).

[0090] As mentioned above, a contact center may operate as a hybrid system in which some or all components are remotely hosted, such as in a cloud-based environment.

[0091] Conversation Orchestration Engine

[0092] 2 is a diagram illustrating one embodiment of a logical architecture of a conversation orchestration engine system, generally designated 200. In one embodiment, system 200 may be employed in contact center system 100 (FIG. 1). Components of conversation orchestration engine system 200 include a conversation orchestration engine 205, a voice channel 210, a voice channel connector 215, a digital channel 220, a digital channel connector 225, a voice gateway 230, a time transcription (TTS) service 235, a speech to text (ASR) service 240, a bot gateway 245, a bot 250, a knowledge base gateway 255, a knowledge base 260, an API gateway 265, a device gateway 270, and an agent device 145.

[0093] Customers 105 may communicate with contact center system 100 in which conversation orchestration engine system 200 is implemented using communication channels such as a voice channel 210 and a digital (or video) channel 220. Other channels such as text channels, web chat channels, and multimedia channels may be supported as well, allowing communication with parties external to the contact center.

[0094] The channel connectors 215 handle the inbound and outbound information flow between the conversation orchestration engine 205 and the channels 210, 220. The channel connectors 215 may be platform-specific or common across multiple platforms (e.g., Apple Business Chat, Facebook Hub).

[0095] The voice gateway 230 provides access to a TTS service 235 and an ASR service 240 so that voice data can be converted to text and vice versa. Thus, other components of the contact center that employ text-based input and output can use audio data, including speech, as input or have their output converted to a recognizable voice audio signal. In one embodiment, the voice channel's TTS service 235 may be a third party. In one embodiment, the voice channel's ASR service 235 may also be a third party.

[0096] The bot gateway 245 provides a connection for one or more bots 250, allowing them to interact with the orchestration engine 205.

[0097] The bot 250 may be third-party (e.g., "Bring Your Own Bot") or organic (i.e., built into the dialogue engine used in the contact center). The bot knowledge (vocabulary and action set) includes a domain. Elements of a domain further include entities, slots, intents, utterances, behavior trees, contexts, and channel-specific implementations, which are described in more detail below.

[0098] The knowledge base 260 provides content in response to queries. The knowledge base can be a third-party knowledge base or an organic solution. An intermediary service (knowledge base gateway 255) is used to enable interactive context-based searches via knowledge sources registered with the gateway.

[0099] The conversation orchestration engine 205 acts as a conduit to orchestrate actions throughout the contact center in response to conversational flow. The conversation orchestration engine 205 includes platform-specific services and common services that can also incorporate the dialogue engine as part of native conversational AI capabilities. The conversation orchestration engine can also use third-party systems that provide voice-based and text-based conversational interfaces, such as Google's Dialogflow or Amazon Lex. This acts as a conduit to orchestrate all event flows. The conversation orchestration engine 205 is structured depending on the platform and target deployment model (cloud, premise, hybrid). Having this engine provides the ability to maintain universal context and resolve actions at nearly any level.

[0100] The agent device 145 (FIG. 1) includes interfaces that allow the contact center agent to engage in interactions or conversations with the customer 105, as well as interfaces that allow interactions with other agents, supervisors, and automated entities in the contact center, such as bots 250. An intermediary service (device gateway 270) handles pushing information to the agent's device 145 and facilitates queries from the device to the conversation orchestration engine 205.

[0101] The API gateway 265 enables the conversation orchestration engine 205 to interact with a wide range of other systems and services, including internal and external systems and services, via application program interfaces.

[0102] FIG. 3 illustrates one embodiment of a system architecture for a dialogue engine, generally designated 300. In one embodiment, system 300 may be used in a hybrid microservices architecture. Components of dialogue engine system 300 include a dialogue engine 305, a background database service 310, a storage database 315, a natural language understanding (NLU) service 320, an internet (or web) 325, an administration program 330, a designer program 335, a bot 340, and an analyst program 345. The administration program 330 allows an administrator to control user management within dialogue engine 305 through a User API via web 325. The designer program 335 allows system designers to create bot applications and bot models through an API connected to web 325. The NLU service 320 may be an artificial intelligence service that can receive and interpret naturally spoken speech data according to a trained language model. The NLU model is trained, and then the bot model is uploaded to storage database 315. Bot 340 inputs dialogue via the API. There can be any number of bot instances, e.g., one bot per interaction session with a user. The dialogue engine 305 can download the bot model from the storage database 315 and then process the interaction behavior tree as described in more detail below. The processing session is uploaded to the storage database 315. The web 325 provides a background service 310 that trains the model. The trained model is provided to the storage database 315 for use by the dialogue engine 305. The analyst program 345 requests reports for bot performance and tuning. The dialogue engine system 300 is implemented as a component within the conversation orchestration engine 205 (FIG. 2).

[0103] 4 is a diagram illustrating one embodiment of a system architecture for a dialogue engine, generally designated 400. In one embodiment, system 400 may be used in a cloud-native microservices architecture. Components of dialogue engine 400 include a designer program 335, a bot 340, an analyst program 345, a web 325, a bot hub 405 that links to multiple libraries 410a-d, a bot service 415, a bot session storage 420, a bot analytics storage 425, a bot analytics module 430, and an extract, transform, and load (ETL) module 435.

[0104] Vertically dividing the dialogue engine 305 into three services within the system 400 (e.g., bot hub 405, bot service 415, and bot analytics module 430) allows each service to be deployed, upgraded, and scaled individually to meet its own requirements. For example, the bot service 415 may require fast access to its session storage. MemCached, a general-purpose distributed memory caching system, may be deployed on top of database storage to speed data access by caching data and objects in RAM, reducing the number of times the database storage needs to be read. In addition, the bot service 415 often requires rapid scalability (up and down) in response to real-time loads. Conversely, the bot analytics 430 may not require real-time processing and may be run in batches. The bot hub 405 requires highly secure transactions and well-versioned control. It may also need global access. The bot hub 405 serves as the front-end and back-end for bot modeling. Users can pull, save, publish, and reuse all bot design artifacts from libraries 410a-d across projects. During deployment, bot service 415 can also pull domain files and trained NLU models from bot hub 405. Libraries 410a-d include a webhook library 410a, a natural language understanding (NLU) model library 410b, a behavior tree library 410c, and a bot library 410d.

[0105] The bot service 415 provides live bot services in real time. The bot service 415 can be integrated with omnichannel multimedia such as voice, messenger services (e.g., Facebook Messenger, Slack, Skype), social media (Twitter), etc. Real-time monitoring is also provided, and agent "barge-in" is also possible.

[0106] The bot analytics module 430 provides bot analytics that provide insight into contact center operations by retrieving past chat transcripts from the bot session storage 420 using the ETL module 435. Feedback from the bot analytics module 430, such as uninterpreted user utterances, unexpected user intent, bad business practices, bad actions, bad webhook requests, etc., can be used to further refine bot modeling and stored in 425 for use by other components, such as the bot app library 410d. Bots implement a behavior tree format of behaviors to control, direct, or manage conversations conducted with contact center customers.

[0107] Generally, as mentioned above, bot knowledge (e.g., vocabulary and action set) includes a domain, whose elements further include entities, slots, intents, utterances, behavior trees, contexts, and channel-specific implementations.

[0108] Entities can be aliases for data types. Entities can be built-in, like strings and dates. They can be defined as "plugin_name:de.entities.BuiltIn". This string declares that the entity called "name" is implemented by a particular plugin class. Entities can be pre-registered to be made accessible, and paths can be specified for custom entities.

[0109] A slot contains an instance of an entity. A slot may have a name, an entity, and may have a prompt to use when filling the slot. A prompt is an example of an utterance generated by the engine and may be defined in a template.

[0110] An intent is a semantic label assigned to an utterance. For example, Intent ask_temperature: display_name: "Weather Service" Phrase: -What's the temperature in [city:city] (Paris)? -Weather [City:City] (Prague) [Date Time:Date] (May) -Weather [city:city] (Dublin)? -Weather [Date Time: Date] (May) -Weather [city:city] (Galway) -Temperature [DateTime:Date) (Galway)?

[0111] The intent may also include a display name that can be used for confirmation behavior. The intent also includes a natural language text label.

[0112] Utterances or prompts include messages generated by the bot. Utterances can be defined using templates with parameters filled in from the context, or can be explicitly sent when the utterance is selected. Utterances can include alternative templates, allowing for variation in the dialogue. Not all templates may have the same parameters. Variation can also be desirable depending on the amount of information in the context. For example, "Your reservation is complete. Your reservation details have been sent to {{email}}" and "You're good to go, {{name}}. Your reservation details have been sent to {{email}}."

[0113] Behavior Tree

[0114] Generally, a behavior tree contains a single-rooted, oriented tree where leaf nodes are either conditions or actions, and intermediate nodes control execution semantics through their children. Execution of a behavior tree begins at the root, which sends ticks to its children at a certain frequency. Ticks are enable signals that allow the children to execute or be evaluated. Condition nodes evaluate to return success or failure. Action nodes evaluate to return success, failure, or running. The combination of reevaluation on every turn and the use of a running state allows nodes to have execution semantics across more than one turn. This is extremely useful when composing self-contained behaviors. The tree is evaluated from the root in a preorder traversal, left-to-right, top-to-bottom order. Behavior trees have proven to be expressive, simple, modular, hierarchically composable, and suitable for automated composition across interactions of varying complexity.

[0115] A behavior tree includes conditions, actions, sequences, nodes (e.g., fallback, parallel, branch, decorator, memory, action, etc.), and context. A condition is a Boolean function with a shortcut syntax for specifying an intent as a condition. A condition expressed as an intent (e.g., condition:buy_car) is logically equivalent to the implicit semantics of top_intent() == buy_car and prob(buy_car) ≥ THRESHOLD. Intent is probabilistic in principle, but in the embodiments described herein, it is used as a Boolean operator. It can drive confirmation behavior as needed. The concept of a condition can be generalized to include any expression or function that returns success or failure. The expression syntax is currently limited to intents and functions. Condition functions can be declared as plugins. For example, plugin greater_than:de.conditions.plugin

[0116] It is also used as follows: -Condition:greater_than(age, 18 years old)

[0117] Utterances, or prompts, comprise a special case of actions. In one embodiment, actions are plug-ins that are callable by the dialog. Actions can be registered as follows: Plugin weather_lookup:travel_bot.weather_lookup Plugin calc_month:travel_bot.calculate_month

[0118] Actions follow the pattern of an entity plugin with name:implementation_class. In one embodiment, pre-registered actions may be provided. Actions within a domain may be defined with parameters.

[0119] Within a behavior tree, a sequence contains descriptions assembled together as instructions to be executed one after the other. Also, various flow control nodes can be applied within a behavior tree. Different types of nodes include selector nodes, fallback nodes, sequence nodes, parallel nodes, branch nodes, memory nodes, and decorator nodes, to name a few non-limiting examples.

[0120] Selector nodes can often be used to define execution priority over possible child nodes, providing modular and configurable properties to the behavior tree.

[0121] A fallback node is used to find and execute (or tick) the first child that does not fail, so that the fallback node stops "ticking" subsequent child nodes for the first child node, in the order of the first child node that returns success (fallback node) and the first that returns failure (sequence node). A fallback node immediately returns a success or running status code when one of its children returns success or running. Children are ticked from left to right in order of importance.

[0122] In pseudocode, the fallback composition algorithm can be expressed as follows: [Table 1]

[0123] A sequence node is used to find and run the first child that has not yet succeeded. The sequence node immediately returns a failed or running status code when one of its children returns failed or running. Children are ticked in order from left to right.

[0124] In pseudocode, the algorithm for sequence synthesis is: [Table 2]

[0125] Parallel nodes are a hybrid between sequence and fallback nodes. Parallel nodes traverse nodes from right to right, and M or N nodes must succeed for the parallel node to succeed. In one embodiment, these may be used when multiple update modes are simultaneously available on the agent desktop in a contact center when bots are used to assist agents. For example, flagging for escalation to a supervisor, suggesting inline responses to the agent, surfacing knowledge, tracking and publishing sentiment, etc.

[0126] Decision nodes implement if-then-else semantics. They address gaps in behavior tree formats that are inconvenient to express. [Table 3]

[0127] The branching nodes are as follows: -Fallback: -action condition_clause:then_action -action not(condition_clause):else_action

[0128] A branch node can be denoted as follows: -Branch: -if: -Condition: condition_clause -then: -action: then_action -else: -action: else_action

[0129] The implementation is described as follows: [Table 4]

[0130] All nodes are ternary-valued.

[0131] A memory node can be used to avoid re-evaluation by allowing it to cache its last execution result, and if the node was successful, it is skipped. In the following exemplary representation, a memory node is * This prevents re-evaluation of completed children, so that from turn to turn, a templated outcome occurs for some part of the sequence. For example, -Sequence: -Condition: book_hotel -Sequence * : -action:clear_slot(hotel_name,hotel_booked) -action:utter_ack_book_hotel -Tree:bt_search_hotel -Tree:bt_reserve_hotel -tree:bt_conclude_booking

[0132] The reuse of cached results is generally predicted by the values of slots or variables used by the problematic node. This allows the node to be skipped if none of the input data has changed, and allows re-evaluation if the user explicitly changes the value of one of the slots. For example, the decorator pattern can be used: an action performed using variables x and y may need to skip execution if x and y have not changed. The note() decorator can be used to wrap an action (or any node), for example: -Action memo(x,y): do_action(x,y)

[0133] Decorators are evaluated as guards on execution, and their state can be cached in the context for that exact node_id in the context. For example, using reduce without an argument means that the decorated node will be executed at most once ever. This could be used in greetings, and could easily be extended to switch subtrees on and off.

[0134] New node types can be easily created to extend the behavior tree-based paradigm. For example, machine learning-based dialogue nodes that use dialogue examples (e.g., question and answer pairs) or more detailed "stories" to train policies for next-best actions. Fallback nodes can be used where the execution order is determined by a machine learning algorithm based on choosing a node ordering that maximizes the chance of success while minimizing the number of turns in a context-dependent manner. Furthermore, in one embodiment, similar feedback nodes can be used to choose among alternative, distinct messages for any given utterance in a way that optimizes several outcomes, as long as these outcomes can be captured. For example, any slot-filling behavior works when the slot is filled correctly with the minimum number of turns. This can result in a sequence of prompts that elicit the best response.

[0135] FIG. 5 shows an example of a simple behavior tree 500 used in a contact center to manage the greeting interactions that customers encounter when placed in communication with the contact center.

[0136] The behavior tree 500 includes a root node 505 , a “welcome message” utterance 510 , a fallback node 515 , a sequence node 520 , a “greeting” condition node 525 , an “utter_greeting” utterance node 530 , and a “waiting message” utterance node 535 .

[0137] Execution of the behavior tree begins with root node 505, which in turn sends a tick to each of its children, namely, speak "welcome message" node 510 and fallback node 515. In one embodiment, the speak "welcome message" node is marked to execute once so that the customer plays a welcome message on their first connection. The welcome message may be a recorded message played by IMR server 125 (FIG. 1) under the control of orchestration engine 205 (FIG. 2), which is running the behavior tree of FIG. 5 as a bot service. Thus, the exemplary behavior tree illustrated in FIG. 5 functions as a flowchart for customer interaction control.

[0138] After the first execution of the "Welcome Message" utterance 510, in each cycle a tick is sent to the Fallback node 515, which evaluates each of its children to find and execute the first one that does not fail. The children are ticked in order from left to right, i.e., the Sequence node 520 and the "Waiting Message" node 535 are ticked.

[0139] When sequence node 520 is ticked, it attempts to find and execute the first child that has not yet succeeded: the "greet" condition node 525 and the "utter_greeting" node 530. As mentioned above, when a sequence node receives a status code of either Failed or Running from one of its children, it immediately returns a status code of Failed or Running, and children are ticked in order from left to right.

[0140] If an agent is available or likely to be available, an automated greeting is played to handle the customer conversation. Thus, the "greet" condition node 525 checks agent availability to determine whether to play an automated greeting. If an agent is unavailable, the greet condition node returns a failure, which in turn causes sequence node 520 to return a failure to fallback node 515.

[0141] As a result, the fallback node (which is executing to find the first child that has not failed) sends a tick to the speak "waiting message" node 535, which results in a waiting message being played to the customer. A timeout (not shown) typically precedes the playing of this message, resulting in a predetermined period of time elapsed between wait messages with still no available agents. The speak "waiting message" node returns running, which causes the fallback node 515 to also return running to the root node.

[0142] The system continues to evaluate the fallback node as long as the same condition holds, i.e., as long as the agent is not free. Once the agent is free, the evaluation of the "greet" condition node 525 changes from failure to success on the next tick. Execution is then sent to the "utter_greeting" speech node 530, which in turn returns success. Because both child nodes returned success, the sequence node 520 returns success as well, and therefore the fallback node 515 also returns success to the root node 505.

[0143] The root node 505 can either terminate execution or continue to send ticks to its children, which continue to return the same state as long as nothing changes. In the example behavior tree of Figure 5, the "welcome message" node 510 holds a flag that it has already executed once, and the "greeting" condition node 525 and the "utter_greeting" utterance node 530 hold their success states, so no change is expected, which then means that at each tick, the sequence node 520 and fallback node 515 continue to return success indefinitely.

[0144] Figure 6 is an example of a behavior tree 600 that adds more functionality to the example illustrated in Figure 5, providing the basis for a complete interaction management system for a contact center. In one embodiment, root node 605 has two children: activation node 610 and branch node 615.

[0145] The activation node 610 is a behavior tree that contains its own children and defines the desired functionality at the start of an interaction. The children are not shown, but may be apparent to a user of the interface that Figure 6 captures by expanding the "+" sign at the bottom edge of the node's icon. The functionality of the behavior tree defined under this activation node 610 may be the same as the root node in Figure 5, for example.

[0146] In one embodiment, branch node 615 has three children: condition check 620, main loop behavior tree 625, and utterance 630. A tick is sent to condition check 620 at each iteration of the branch node, which performs a check on the session state value "IsSessionEnded" and returns success if the session is still in progress or failure if the session has ended. As long as the returned value is success, branch node 615 sends a tick to main loop behavior tree 625. When a failure value is returned from condition check 620, branch node 615 sends execution, which is typically a "goodbye" message, to utterance 630.

[0147] The main loop behavior tree 625 may have any programmed functions beneath it, some examples of which are described below. They have their own children, at least some of which will typically be complete behavior trees on their own. For example, in a pizza ordering contact center, there may be a tree that handles obtaining or confirming customer details, delivery addresses, etc., a tree that handles individual pizza orders, a tree that builds complete orders for each pizza, and a tree that handles payments.

[0148] FIG. 7 illustrates one embodiment of a behavior tree 700 that is identical to the behavior tree 600 of FIG. 6, but where both the startup behavior tree 610 and the main loop behavior tree 625 have been expanded to illustrate the next level of children.

[0149] The startup behavior tree 610 of this embodiment provides simpler functionality than the startup behavior tree of Figure 5, playing a welcome message 705 before setting the value of the flag "IsSessionEnded" to NO at action node 710. The startup node is marked to be executed only once. Further changes to the flag can be set in other parts of the overall behavior tree 700, such as when an order is completed or an inquiry is answered and it is detected that the customer has no further requirements or questions.

[0150] The children of the main loop behavior tree 625 are three nodes—“bt_basics” 715, “bt_tasks” 720, and “bt_offer_help” 725, which are themselves behavior trees with their own functionality and their own children, not shown in FIG. 7.

[0151] The "bt_basics" tree 715 can perform the initial services required to provide service to a customer, such as verifying the customer's identity, determining the nature of the inquiry, conducting an interactive media response session, and determining the required agent skill set and agent assignment.

[0152] The main loop behavior tree node operates as a sequence node that returns running when any of its children (polled in order from left to right) return running. Thus, the main loop behavior tree node sends execution to the "bt_basics" tree, which remains in the running state until it determines that execution is complete, at which point the "bt_basics" tree no longer returns running. Thus, on the next tick, control is sent to the "bt_tasks" tree 720.

[0153] The "bt_tasks" tree 720 defines detailed interaction management for an agent or bot and can perform several potential tasks or scenarios, with the appropriate task being determined by the customer's detected intent, either through the initial call processing in the "bt_basics" tree 715, or by recognizing from further conversation that there are additional or alternative intents that need to be handled.

[0154] The "bt_offer_help" tree 725 is invoked when the conversation encounters a difficulty that causes a task in the "bt_tasks" tree to fail. Thus, for example, if the customer requests to speak to a supervisor or human agent, or if the customer's response cannot be understood, or if an intent is detected for which there is no dialogue defined in the "bt_tasks" tree 720, the "bt_tasks" tree returns failure and execution is sent to the "bt_offer_help" tree, which may use human or automated means to resolve the detected difficulty.

[0155] A catch decorator 730 is provided on the main loop behavior tree that can detect when an exception is thrown in any of the child trees where no well-behaved exception exists, and can cause the interaction to resume or return to any given point within that child node, for example, according to already established values, intent, and conversation history.

[0156] Context can be used within a behavior tree to describe the state of behavior tree execution (nodes have memory), active slots and intents, candidate slots and intents, template intents, augmenting NLU by restricting expected slots, values, and intents, sub-intents, follow-on intents, state sent to a node, etc. Context can actually include the set of slots and intents active for an interaction at any time. Knowledge and memory of previously obtained information is important for natural language descriptions. For example, System: The Grand Hotel is a 3-star hotel, priced at 99 euros per night. Customer: Is there a pool? System:..Yes, the Grand Hotel has a 25m swimming pool.

[0157] The context that the current hotel is the "Grand Hotel" allows the subsequent question to be understood, where the reference is implied by "that." Consider the following example intent and recognition phrases: Intent ask_hotel_info: -Does [Hotel:hotel_name](it) have a [HotelAttr:hotel_attr](pool) -Does [Hotel:hotel_name](that) have a [HotelAttr:hotel_attr](pool) -Does the [Hotel:hotel_name] (Hilton) have a [HotelAttr:hotel_attr] (pool)

[0158] This intent statement allows pattern recognition to focus on very specific patterns that can then be interpreted in a context-dependent manner to yield values that can resolve coreference resolution. Memory slots can also provide another example of turn-wide context. In the example below, the city is known. The date of the query has changed. However, the system retains the context that this is a weather query. Customer: What is the temperature in Paris in September? System: The average temperature in Paris in September is 22°C. Customer:...How about October? System: The average temperature in Paris in October is 17°C.

[0159] Slot values, when set, must persist across turns, and some intents must persist across turns, while others do not.

[0160] A context can be defined, for example: Context Task: intention: -ask_temperature -book_hotel -book_car

[0161] The context name is called "task" in the above example. It refers to a set of mutually exclusive intents. Figure 8 is a diagram illustrating one embodiment of the relationship between intents, contexts, and behavior trees, for example, generally designated 800. Figure 5 shows an intent associated with a named context 805 and how it is linked to a behavior tree 820 via a condition node 825 with the intent. When the NLU detects intents 810a-c on the task context (e.g., Book a car 810a, Book a hotel 810b, Inquire about the weather 810c, to name a few non-limiting examples), the dialogue engine sets context[task]="Book Car" if a value does not already exist. Thus, the assignment persists across turns because it is automatically stored. In subsequent turns, for example, if the customer provides the location of a city or asks for a price, the intent persists in context[tasks]. This is used in the behavior tree 820 by simply specifying a condition 825 for the intent. For example, condition:book_car.

[0162] The dialogue engine also keeps track of active contexts. There is a plugin (is_active) that takes a list of contexts and returns true if all contexts are active, false otherwise. If an intent is already assigned to a context and a new intent is detected from the same context, it is tracked as a context_switch and can be recognized and resolved throughout the dialogue by explicitly asking the user how they want to handle the switch, or simply by writing a policy into the behavior tree. context_switch is provided as a condition that accepts a positional argument, for example: -context_switch():#True if any context switches are found -context_switch(c1):#True if there is any context switch for context cl -context_switch(cl,il): #True if there is any context switch on cl from il

[0163] By default, all context_switches for a turn are cleared on the next event and do not affect the system state. However, behaviors can be provided to handle context switches, and the dialogue engine provides a stack representation of the intent_backlog. You can use the has_backlog condition to check if there are any backlogged intents.

[0164] The main actions for handling context switches can include: push_intent(intent), intent-pop_intent(), subsume_intent(intent_1,intent_2), set_intent(intent), clear_intent(intent), and ctx,from,to=pop_context_switch(). "push_intent(intent)" places an intent on the stack later. "intent-pop_intent()" pops an intent off the stack, if available. This fails if there are no intents on the stack. "subsume_intent(intent_1,intent_2)" pushes intent_1 on the stack and sets intent_2 to be the active intent. "set_intent(intent)" sets the intent assignment for the context. It also removes the intent assignment from the backlog. "clear_intent(intent)" clears the intent assignment for the context. The "ctx,from,to=pop_context_switch()" action pops the most recent context switch from the stack (accumulated in a single turn) and returns its parameters, which are the context, the intent to switch from the context, and the intent to switch to the context. For example, when any context switch is detected, the system pops it and performs an exchange of the current context. The new intent includes the existing one in this example. -sequence context_switch(): -action:context,from,to=pop_context_switch() -action:subsume_intent(from,to)

[0165] In another example, the system notes a particular context switch (i1 through i2) and stores it for later execution. Finally, the system may detect that there is a backlog of intents from prior context switches whose models are later stored. The following example may be executed when a backlog is detected, popping an intent from the stack and setting it: -sequence has_backlog: -action:intent=pop_intent() -action:set_intent(intent)

[0166] 9, described further below, provides one embodiment illustrating additional details regarding the processing of new intents and context switches. In one embodiment, behavior trees may be implemented for specific media channels. For example, ordering a pizza through a voice channel requires a multi-turn conversation to specify the pizza size, toppings, base, etc. Different paths and interactions may be taken depending on the channel required to achieve the same goal. This may be done by decomposing the process of ordering a pizza into specifying the pizza and paying for the pizza. If a media-rich channel (such as web chat) is used, there is the possibility of pushing an "applet" that allows the user to specify everything needed to order a pizza in an interactive way before finally submitting the request.

[0167] Within the dialogue engine, specific channels may be implemented, including chat, voice, agent desktop, and web. For example, in a chat channel, the implementation is text-based. Voice is typically phone-based, but may originate from a browser or a device like Alexa. In an agent desktop, it is used to prompt a human agent with content that may be sent to the customer (e.g., FAQ items, conversational sub-dialogues to perform customer identification and verification (ID&V), etc.). The following examples may be applicable to both voice and chat.

[0168] In one embodiment, a simple use case for capturing intent, slots and performing a successful backend lookup may be as follows: User: Hello, I would like to check the balance of phone number 016360028. (Here, the system detects the intent (balance_inquiry) and slot (phone_number). System: Balance inquiry! What are the last four digits of your account number? User:1234 System: Thank you. (The system will call a backend service to verify your phone number and account number details. The intent will be marked as "Complete" at this point. Your current balance is $42.50, and the payment is due on August 29th. Is there anything else I can help you with?) User:..Thanks.

[0169] In another embodiment, a use case is illustrated for handling a failed backend lookup: the system must re-prompt the user for some information after the backend request reveals that the information is invalid, demonstrating the need for looping in the interaction definition. User: Hello, I'd like to check my balance. (Here, the system detects the intent (balance_inquiry) and asks for the remaining slots.) System: Balance inquiry! What's your phone number? User:016360028 System: What are the last four digits of your account number? User:9999 System: Thank you. (The system calls a backend service to verify the phone number and account number details - in this case the details are invalid. It could be that the system misheard the details and did not verify them, or the user provided incorrect values initially). Sorry, those details do not match. Could you provide them again? Phone number, please. User: 016360028, account number is 1234. System: Thank you. (The system calls the same back-end service to verify your new phone number and account number details.) Your current balance is $42.50, due August 29th. Is there anything else I can help you with?

[0170] Depending on the encoding, it might look something like this in a behavior tree: #Happy Path for ID&V behavior_tree account_id_verification: -action:ask(phone_number,account_number_digits) -Action:utter_thanks -Action:account_id=get_account_details(phone_number,account_number_digits) -condition:neq(account_id,NONE):utter_thanks # SUCCESS #Reset behavior on failure behavior_tree resert_account: -action:utter_no_account_found -action:reset_slots(account_id,phone_number,account_number_digits) #Full behavior with retries and follow-ups on success behavior_tree balance_inquiry: -Condition:intent_balance_inquiry -tree retry(max_tries=3,error_handler_reset_account):account_id_verification -action:balance=lookup_balance(account_id) -action_utter_balance(account_id,balance) -action:utter_anything_else

[0171] In yet another embodiment, continuing the same previous session, the user expresses a new, related intent, the wording of which (Why is it so expensive?) only makes sense in the context of the previously completed intent (balance_inquiry). System: Your current balance is $42.50, due August 29th. Is there anything else I can help you with? User: Why is it so high? (Here, the system detects the intent (balance_why_so_high).

[0172] "Balance_inquiry" is a context and can persist across several turns. It remains the active context unless it is cleared. There may be other intents that are not maintained across turns. For example, there may be recognition phrases for the intents such as: Intention balance_why_so_high? Why is it so expensive? Why is my account balance so high?

[0173] The logic can be captured as follows: Tree balance_inquiry_2: -Condition:intent_balance_inquiry -Fallback: -Sequence: -Condition: is_not_set(balance) -tree:account_id_verification -action:balance=lookup_balance(account_id) -action:utter_balance(account_id,balance) -action:utter_anything_else -Sequence: -Condition: is_set(balance) -Condition:intent_balance_why_so_high -action:utter_dont_know_why -tree:offer_agent_escalation

[0174] The above is an example of using intent in context. Other examples may refer to a true follow-on where the system takes the initiative, such as offering loan terms or a special low-interest overdraft. This can be triggered after the initial inquiry has been processed. The balance information and account ID are still present, and a follow-on behavior in that sense can be triggered by simply invoking the subtree. This is similar to the above reference for triggering agent expansion.

[0175] In another embodiment, a decorator node may be introduced for processing validation. User: I plan to pay at the post office tomorrow. (The system detects the intent (promise_to_pay) and slot (location = post_office, date = tomorrow).) System: Your current balance is $99. How much would you like to pay? User:... the full amount. System: ...So, just to confirm, is it correct that you plan to pay the full balance of $99 at the post office tomorrow? User: Wait, actually, I'll pay $80. (Note that the confirmation prompt is slightly different because the user is no longer paying the full amount.) System: ...So, just to confirm, is it correct that you plan to pay the $80 at the post office tomorrow? User: Yes. (The system calls a webhook / script to record the "promise to pay").

[0176] It has the semantics of invoking the underlying action and, if successful, caching its execution state for the input value at that point. This encoding below illustrates how a recognition phrase contains slots, which can result in slot assignment. If a slot assignment occurs, the confirmation node checks its cache. If the input value for the underlying input changes for any reason, the confirmation needs to be done again. Intent promise_to_pay: -I plan to make a payment [date: payment_date] (tomorrow) at the [location: location] (post office) Intent inform_reparment_amount: -Repayment (full amount) -Please wait [string:repayment] (44) Tree get_promise_to_pay: -Condition: promise_to_pay -action:utter_current_balance(balance) -action:ask(payment_date,location,repayment) -action:confirm(utter_confirm_promise_to_pay,payment_date,location,repayment) -action:record_promise_to_pay(payment_date,account_id,location,repayment)

[0177] In one embodiment, by handling asynchronous actions, the system starts a backend task / script that is likely to take some time, while the user can context switch if they like. This kind of example can be processed on parallel nodes to allow both to run. For example: User: I plan to make a $100 payment at the post office tomorrow. (The system detects the intent (promise_to_pay) and slot (location=post_office,date=tomorrow,amount=$100).) System: ...So, just to confirm, is it correct that you plan to pay the $100 at the post office tomorrow? User: Yes. (The system will launch a web food / script to record the "promise to pay"). System: Please wait a moment while processing. (Time passes, where there can be full duplex communication between the customer and the dialogue engine, or the client keeps polling the dialogue engine every few seconds.) We apologize for the wait, please wait a little longer. User: Can you send me a reminder next month when my bill is due? (The system detects a potential new intent (setup_bill_reminder). System: Would you like to set up bill reminders today? You can return to payment after you've done so. (If the user says "later," that intent will be stored in the backlog so it can be suggested again when payment is complete.) User: Yes, please. (The system enters the current intent (promise_to_pay) in the backlog and sets setup_bill_reminder to the current intent.) System: Would you like to be reminded by email, SMS, or both? User: Email (system will initiate a webhook / script to set up reminder). System:... We're setting up now. Please wait a moment... (Time passes). Everything is set up now. You will receive an email and an SMS message a few days before your NetBill payment is due.

[0178] Depending on the encoding, it might look like this: tree payment_handling: -Parallel: -tree:get_promise_to_pay -Sequence -Condition:request_reminder -tree:setup_reminder

[0179] In another embodiment, the mapping from an intent with embedded slots in a subtree can be performed using a decorator. For example, -Sequence * Intent 1: -Action: Check (Intent 1) -action:ask(slot1, slot2) -Sequence * : -action:x=do_action_1(slot1) -action:y=do_action_2(slot2) -action:utter_response_23(x,y,slot1,slot2)

[0180] The tree checks the triggered intent, then performs slot filling if necessary, and then moves to action, focusing on the response. In a condensed version, there is semantics to check the triggered intent and fill in the slots that are the required inputs. -Sequence * :intent1(slot1, slot2): -action:x=do_action_1(slot1) -action:y=do_action_2(slot2) -action:utter_response_23(x,y,slot1,slot2)

[0181] In another embodiment, complex problems may exist. For example, an airline may have requirements for handling login issues, baggage issues, flight status inquiries, special meal requests, seat upgrades, and FAQ searches. The starting point for this domain is a base set of intents for each task and the entire menu structure of the root tree. Each main task is a higher-level branch. The main intents can be mapped to subtrees to handle the details. behavior_tree main: -Sequence: -tree memo():bt_startup -Fallback: -fallback catch(): -Tree:bt_basics -Tree Login_problem:bt_login_problem -Tree Lost_bags:bt_lost_bags -Tree Flight_Status:bt_flight_status -Tree Special_meal:bt_special_meal -Tree Upgrade_Request:bt_upgrade_request -Tree FAQ_Search:bt_faq -Tree Luggage_Issue:bt_luggage -sequence no_response(): #If there is no response to user input, try again -Action: say("Sorry, I didn't understand") -tree:speak_menu #Handling exceptions -Sequence: -action:reset_state -action:say("redo")

[0182] A wrapper around the main menu can also be applied. The launch behavior should only be executed once in the bot's lifetime. This is achieved using memo(). In this example, behavior_tree bt_startup: # Run this once at startup -action:say("Welcome to Airline Support") -Action: say "I can help you with various support inquiries" -Action: say("How can I help you?")

[0183] Global conversation processes can be used as part of higher level behaviors, which are re-evaluated each turn. For example: behavior_tree bt_thanks: -Conditions:thanks -Action:utter_ack_thanks behavior_tree bt_menu: -Condition: inquire_menu -tree:speak_menu #This menu appears when it can be called #In some places behavior_tree speak_menu: -Action: say("I can book flights, check flight information, and process reservation changes." -Action: say ("I also deal with baggage issues and general questions.") -action:offer_help behavior_tree bt_greet: -Condition: inform_name -Action:greet behavior_tree bt_basics: -Fallback: -Tree:bt_menu -Tree:bt_greet -Tree:bt_thanks

[0184] The main menu structure (the fallback node) is wrapped in a catch decorator. Any uncaught exceptions that rise at a lower level will trigger a failure and fallback to the error handler. Any error handling behavior that catches will reset the state and message resume. -Sequence: -action:reset_state -action:say("redo")

[0185] Subtrees can also be mapped to simple debug statements, for example: behavior_tree bt_lost_bags: -Action: say(Lost_Bags)

[0186] Below is another example of a behavior tree for handling login issues. behavior_tree bt_login_problem: -Sequence * : -action: say("I can help a customer reset their password") -Fallback retry(count=3) -action not(dont_know):ask(account_number) -Sequence * : -action: say("You can get an account from your email address") -tree:bt_lookup_by_email behavior_tree bt_lookup_by_email: -Sequence * : -Fallback: - Sequence retry (count=3, retry_message="Sorry, no email match possible"): -Action:Ask (Email) -Fallback: -action:account_number=lookup_by_email(email=email) -Sequence Failed: -action:debug(message=email) -action:clear_slot(email) -tree:bt_agent_transfer behavior_tree test_bt_lookup_by_email: -tree catch():bt_lookup_by_email

[0187] There are also several points where the option of agent transfer may be provided. The behavior tree below specifies this behavior. This may be wrapped in a retry loop. In another embodiment, the stop behavior may also be used as a fallback to close the conversation and throw an exception. The agent transfer implementation uses standard dialogue actions (intents) to capture affirmative and negative responses. These are defined in recognition phrases. Abstracting this into an intent makes it language agnostic and robust to variations in expression. behavior_tree bt_agent_transfer: -Fallback: -Sequence * Retry (count=3, retry_message="Sorry, I didn't understand"): -action:answer=ask_yes_no("Would you like to be transferred to an agent?") -Fallback: -Sequence eq(answer, yes): -Action: say("You are being transferred now. Sorry.") -action:transfer_to_agent -tree eq(answer, no): bt_abort -tree:bt_abort behavior_tree bt_abort: -Action: say("I'm sorry I couldn't be of any help this time. I apologize.") -action:throw()

[0188] Some examples of the use of behavior trees within a dialogue engine may include AI support for agents in real-time interactions with customers over voice and digital channels. An example may be providing real-time sales coaching for collections agency or churn prevention.

[0189] In one embodiment, there may be a blended self-service and agent-service interaction. A customer has a bank account. The customer recently received some money and deposited $30,000 into their checking account. Having a large amount of excess funds in their checking account presents a great opportunity for the bank to add some value and offer the customer a special savings account. This customer currently has a balance in their checking account that is more than five times (or some other threshold) their monthly payment amount, so they fit the profile of such a customer. The bank sees a flag, and the customer could be added to a promotion such as a savings account or perhaps a preferential mortgage interest rate. The customer may be sent a series of offers as part of their monthly communication from the bank. In this example, the customer does not take action from the email and logs into their account a few days after the email communication. A customer named Jack in this scenario is pushing proactive web chats that may look like this: Bot: Hi Jack, I'm your virtual assistant. We noticed that you have quite a bit of cash in your checking account. If you don't plan on using the funds right away, we might be able to help you get a better return. Interested? Jack: Maybe. What kind of return would that be? Bot: Our savings products offer returns of up to 4.1% per annum depending on the amount and duration. Jack: What do you mean by period? Bot: For example, if you commit to depositing it for at least six months, we can offer you a better rate. Is that clear? Jack: Oh, I see.

[0190] Here, there is no further response from the customer. The bot may be triggered to continue interacting with the customer after a certain time threshold has passed. Bot: I'd like to explore that further. If you'd like, I can see if one of our human colleagues is available. Jack: If I put $20,000 away for three months, how much will I get? Bot: Checking... If you commit to 3 months, I can offer you 3.8% APR. Total interest would be $156.27, which is better than the $0.23 you'd get on a checking account ;-). Interested? Jack: A human representative, please. Bot: Thank you, Jack. One of our human colleagues is checking to see if you're available... The wait time is approximately 4 minutes. Would you like to wait or would you like us to call you back? Jack: Please call me back. Bot: We have your preferred contact number at 555.555.5555. Is this the correct number? Jack: Yes. Bot: Sure. I'll call you as soon as possible. Jack: After 4:30 PM please. Bot: Okay, someone will contact you after 4:30 PM. Is there anything else we can help you with? Jack: No, thank you. Bot: Ok, have a nice day!

[0191] At this point, the self-service aspect of the interaction has ended. Three hours later, an agent named Jill at the contact center is routed the callback request. Jill has access to a transcript of the bot's conversation, as well as Jack's key customer relationship management data and a pertinent financial summary that provides the information Jill needs while respecting Jack's privacy. Jill calls Jack. The conversation looks like this: Jack: Hello. Jill: Mr. Brown? My name is Jill and I'm calling from the bank to follow up on your savings inquiry. Jack: Oh, hi. Jill: It seems like you have quite a bit of cash sitting in your checking account. Would you be interested in putting some of it to work? Jack: Yes, if you can get a good rate.

[0192] Here, the agent assistance aspect is triggered by the term "good rate." Jill is presented with coaching on her desktop to help her have a successful interaction. Jill: We have some amazing rates if you can commit to a fixed term deposit of at least six months. Your initial enquiry seems to have been for three months. Jack: I'm a bit worried about locking in for six months. What happens if I need to withdraw the money immediately?

[0193] Now, another trigger occurs for Jill with the agent-assisted aspect: "About early termination from fixed contract" appears on the desktop, which Jill can use as reference. Jill: Early withdrawal is always possible, but penalties will apply and the amount you receive will be reduced. However, you will never end up with less than the amount you initially deposited. If you think you'll need the money before the six months are up, I wouldn't recommend it. If you're just thinking about a rainy day, you do have the option to withdraw your money. Jack: Okay, OK. So what's the rate for six months?

[0194] Agent assistance now triggers a rate inquiry. Jill: The annual percentage rate is 4.1% for $10,000-$30,000 and 3.8% for over $30,000. Jack: So what about $20,000 in six months?

[0195] Agent assistance now triggers the rate inquiry again. Jill: So you'll get about $390. Interest is calculated daily, so it's probably a little less than half. What do you think? Are you getting some return on that cash? Jack: Yeah, that's a good idea. Jill: Great, I'll email you details on how to set it up. Mr. Brown, is there anything else I can help you with today? Jack: No, it's fine. Thank you. Jill: You're welcome. Have a nice day.

[0196] Jack then receives an email with details on how to apply. He then sets up his account through his internet banking institution. As a result, Jack is no longer flagged as participating in this campaign and no longer receives promotions for special savings account rates. In this example, the bot is monitoring interactions and searching for keywords. The agent is receiving candidate knowledge items that are highly relevant to the interaction within the agent's user interface at the workstation. In a self-service scenario where a customer is browsing a website but is not connected to an agent, the customer may be offered a chat. The customer is interacting directly with the bot in the discussion. The bot can draw from a repository knowledge base of Q / A pairs to direct the conversation and assist the customer.

[0197] FIG. 10, described below, provides additional details on the method for pushing knowledge base items to agents, where new input from the customer (as described above) determines a high-priority match from the knowledge base to replace or supplement earlier items already pushed to the agent.

[0198] Another example of a mixed agent-bot interaction may take the form of a bot being supervised by an agent, with the agent workstation being provided with an interface that allows the agent to monitor the conversation between the bot and the customer and control the output and responses provided by the bot. While this may be a generalized capability provided to the agent in an always-on manner (the agent acting as a bot supervisor, potentially tasked with supervising several bot instances and conversations), it may be advantageous to have the bot operate autonomously by default, with agent supervision and control triggered in certain instances.

[0199] For example, a bot can detect a trigger event from a customer interaction if a particular keyword, context, or intent is determined to be present; if an emotion / sentiment metric exceeds a threshold; if the customer is speaking loudly (detected as a change in volume or pitch); or if the bot is unable to understand the customer's input or respond satisfactorily with a sufficiently high level of confidence. Any such trigger event can cause a notification to be sent to the agent workstation, which provides a graphical interface through which the agent can monitor the interaction and review the traditional conversation history. The interface can provide the agent with insight into the bot's behavior, such as by presenting a list of potential responses described by the bot and allowing the agent to select which response is most appropriate. The bot can continue to interact autonomously as usual or with a short response delay, allowing the agent to override the next response. Alternatively, the bot can pause the interaction to await agent input (depending on the trigger event and its severity), thereby remaining fully under the agent's control until the conversation ends or the agent decides to return autonomy to the bot. Figure 1 below provides further details on how this form of blended interaction can be implemented with agent-assisted bot supervision.

[0200] In another example, behavior trees can be used to assess a student's level in registering for online classes. Consider Jack again: he may be searching for an after-school education program for his son, Junior. Jack is browsing the ABC Learning Center after-school education website. He is trying to find an appropriate program for Junior but is unsure of which level is appropriate. Using the embodiments described herein, the ABC Learning Center website can observe Jack's online activity and recognize intent and relevant subject matter. The system determines that it is an appropriate time to engage Jack in a web chat with an agent, but all agents are currently busy. Jack can, in the meantime, engage with a chatbot (a service bot). The chatbot suggests to Jack that Junior converse with another bot (a test bot) from his iPad. The test bot can assess Junior's skill level. A unique link is sent to Junior's email. Meanwhile, the service bot suggests Jack continue browsing the website until an agent becomes available. If he has any questions, he can ask the service bot. Once an agent becomes available, the test bot will finish the conversation with Junior and return the results. With all the information at hand, Jack can easily make a decision. The agent can provide some additional details and complete the registration. Jack's and Junior's information is stored for future use.

[0201] In this example, a Behavior Tree (BT) session can be created by either the application or another BT session. In the case of another BT session, the session that creates the child session is called the parent session. In the case of Jack's customer journey at the ABC Learning Center, the ABC journey session is created by the predictive engagement service running on the website. The service bot session is created by the ABC journey session, and the test bot session is created by the service bot session. The service bot session creates a test bot session in its initial context, which sends a parameter ("subject") to the child session. For example, "action:student_level=run_bt(test_bot,subject=math)". Before the test bot accomplishes (or fails) its mission, this action node returns a running state. The randomized string "session_id" is persisted in the service bot context, and the string "run_bt()" action can query the child session state (e.g., not started, 70% done, etc.) while still in the running state. The internal run_bt() is processed by the heavier engine with the test bot session Id. If the child session has not yet started, the dialogue engine immediately returns "not started". If it is already running, the system event "query_child_status" is sent to the child behavior tree to optionally get a more accurate state. "run_bt()" adds the child session state to the parent BT output.

[0202] When the child session completes its mission (the test bot finishes the skill evaluation), the session ends. The dialogue engine collects the relevant status (in case of "student_level") from the child BT context account in the run_bt() signature and generates another system event "post-child_status" to the parent BT. This leads to run_bt() returning success and setting the "student_level" slot, as well as in case of failure.

[0203] The action "run_bt()" creates a new BT session ready to be executed. The child BT "session_id" is returned to the parent BT in the output. If a new BT session needs to be run from another device, variants can also be used, e.g. "action:student_level=run_bt_from_email(test_bot,email=student_email,subject=math)". The dialogue engine service URL containing the Test Bot BT session ID will be sent to the student's email address (or in the above case the junior's email address).

[0204] In one embodiment, the dialogue engine can propagate the results (student_level_) to its closest ancestor if the child BT session has a longer lifespan than the parent BT session.

[0205] In another embodiment, the ABC Learning Center website may have information about Jack from the account he has on the website and provide pre-filled slots when creating the service bot. The service bot can also return various useful information to the journey service. The variant can be used with "-action:run_bt(service_bot,input=dict,output=dict)". The dialogue engine can map slot names between the ABC journey context and the service bot context according to the input and output dictionaries.

[0206] In another embodiment, agent assistant technology can be used for employee onboarding. For example, when an employee starts a new position in a contact center, the first few days and weeks can be mentally exhausting. There is a statistically high probability of confusion. The employee (or agent) needs to familiarize themselves with the systems and processes, and the products / services the company offers require support. Here, a bot can be used to guide the agent through the system from day one.

[0207] In another embodiment, an employee may not have time to click through an employee management system or process to make the requested adjustments. The assistant can interact with the employee management platform to understand when changes can be made, such as identifying when an employee can leave early or make up time. This can be done using pre-built rules that automatically approve changes without the need to click through a workflow. In another example of employee management, overtime can be managed by having the assistant navigate the employee directly to the need for overtime, including responding to requests and processing changes to the schedule.

[0208] In another embodiment, employee feedback may be collected. For example, the assistant may monitor an agent's interactions with a customer. These may be compared to standard interactions of a similar type. If a problem occurs, the agent may be prompted for feedback regarding that interaction type for use in predictive routing and coaching programs. The assistant may also understand where problems occurred in previous interactions and, based on employee feedback, assign coaching and development materials for the agent's improvement. These may be automatically routed to the agent after the next interaction or at a specified time.

[0209] In another embodiment, bots can also be used to automate wrap-up of employee interactions by automatically completing consistent post-interaction tasks (e.g., wrap-up codes, automatically placing employees on break codes, record notes, etc.).

[0210] In yet another embodiment, an employee may struggle to remember all campaigns or consume all information about a customer. By leveraging journey analytics, an assistant can process information faster and uncover hidden details. A bot can advise an agent on where a customer is in their journey and what the best next step is. For example, a bot might provide an agent with information about Jane, such as: "She called last week and wasn't satisfied with the results. Jane has a very low NPS, even though she's eligible for a campaign. Let's focus on that issue. Remember to remind Jane that she can access this information online here, and a link may be provided. Other information may be provided, such as, "Last week, Jane saw a new credit card on our website and remembered to talk about the 'product.' Jane was selected for a 4% discount. Also, she has a son, Rick, so you might talk to her about creating an account for him as well."

[0211] In another embodiment, the bot can be used for process compliance. For example, an employee may not be able to complete a compliance requirement during an interaction. The assistant can listen to the interaction and track its state to ensure that scripts and processes are aligned.

[0212] In yet another embodiment, the assistant can track agent performance over multiple days or periods. The assistant can prompt the employee to focus on key areas, such as "yesterday's handle time was a little longer than normal, so let's focus on that today" or "yesterday you came in third on the performance sheet."

[0213] FIG. 9 is an example flowchart 900 of an embodiment of a method for managing interactions in a contact center employing intent detection and context switching. In step 905, an interaction is initiated by a user at the contact center. The interaction may involve an automated system or workstation at the contact center and / or an agent via the agent's communications equipment, such as a voice or video telephone set. The system receives input from the interaction, sets the intent, in step 910, and manages the interaction by executing a root behavior tree in step 915, which has at least one first-level behavior tree that is executed in sequence in step 920. The behavior tree manages the interaction in step 925, such as by providing output via an automated component that generates an appropriate response to the user or causes the agent workstation to provide an appropriate prompt. Other outputs may include conferencing with another agent, supervisor, or service, switching communication to another component or service at the contact center, opening a new communication channel with the user, conducting a transaction with the user, providing media to the user, etc.

[0214] In step 930, a pattern of data is detected in the input from the dialogue that is determined to indicate a new intent, i.e., a call for the performance of an action or task not currently contemplated or required by the current execution state of the behavior tree. In another embodiment, it may be determined whether there is anything left in the backlog. If the dialogue is still progressing, the process may loop back to 910, but if no dialogue is occurring, the process may end at stop 930.

[0215] In step 935, the sequence of execution is modified in response to the newly detected intent. This can be done immediately or can be deferred, such as by recording the intent in a stack and then switching execution according to the next intent in the stack when the current task is completed. In step 940, new actions consistent with the modified execution sequence are output to a contact center component, which may be the same or different from the component to which the action was previously output, resulting in communication with the user as required by the new intent and in response thereto.

[0216] FIG. 10 is a flowchart 1000 of a method for supporting agents of a contact center system engaged in a dialogue with a user. In step 1005, the dialogue begins between a contact center user and a contact center agent. The system receives inputs from the dialogue and continually interprets the inputs by matching them to a knowledge base in step 1010. When a match is found with an entry in the knowledge base in step 1015, the match indicates that the agent can be assisted by the knowledge base entry or item. Accordingly, in step 1020, the matching entry is retrieved, and in step 1025, the entry is pushed to the agent workstation. It will be appreciated that more than one knowledge base entry may be provided to the agent station depending on how the system is implemented and depending on the number and relevance of matches found, as well as business rules governing which knowledge base entries are provided to the agent (e.g., if there are current promotions or campaigns that prioritize moving the conversation in a particular direction). Knowledge base entries may be presented in a concise form to allow the agent to easily understand the content and relevance of each, such as by showing the agent a list of knowledge base titles and perhaps snippets of entries that allow the agent to understand the context in which they have been selected for presentation.

[0217] As the conversation continues, the system continues to look for matches to knowledge base entries based on both new input and the aggregation of input in context. In step 1030, the system finds additional matches to a higher priority knowledge base entry (or entries). The higher priority entry is pushed to the agent station in step 1035. This higher priority may be determined from a priority rating built into the knowledge base, or may be determined dynamically as the conversation progresses and the priority changes with customer details. As one example, the priority of an already presented knowledge base entry may be lowered once the agent accesses it or rejects it (both indicating that the agent is not further engaged with the entry). Priorities may also be ranked according to the expected progress of a typical interaction; for example, early in a conversation, higher priority may be given to more general information describing various offers, while later in the conversation, higher priority may be given to entries that assist in closing the sale. As another example, in a PC manufacturer's technical support contact center, a suggestion to check for updates to a particular device driver may be prioritized at a very low level in the initial interaction, but its priority may gradually increase as the conversation progresses and early diagnosis steps make it more likely that the device driver is the source of the problem.

[0218] 11 is a flowchart 1100 of a method for managing interactions between a contact center system and its users. In step 1105, an interaction is initiated between a contact center user and an automated interaction engine at the contact center. The system receives input from the interaction in step 1110 and, in its normal mode of operation, autonomously provides a response to the user. The automation of the response and interpretation of the input may be implemented as described earlier in this specification or may use any other suitable system for automated interaction with contact center customers or users.

[0219] In addition to providing automated responses to the inputs, the system maintains a set of rules that define trigger events. Some non-limiting examples of trigger events include determining keywords in one or more input messages, determining sentiment in one or more input messages, determining a change in speech volume or pitch, determining that an input message cannot be properly interpreted, determining that a response message cannot be determined in response to an input message, determining that a confidence level associated with a potential response message is below a predetermined threshold, determining that one or more input messages relate to a topic defined as requiring agent intervention, determining that one or more input messages relate to a topic defined as requiring agent intervention, and determining that agent intervention has been requested by the user of the contact center. In step 1115, trigger events that match such rules are detected.

[0220] After detecting the trigger event, the system, in step 1120, pushes an alert to an agent station. This may preferably be an agent designated as a bot supervisor. An agent may have management or responsibility for several bot-customer interactions (solely or as part of a pool of bot supervisors). If there are several agents responsible for bot supervision, the alert may be pushed to a selected one or all of the agents, allowing any of them to handle the alert.

[0221] In step 1125, an agent responds to the alert by choosing to access the interaction between the bot and the customer. This may be to identify the reason for the alert's trigger (if this was not flagged in the alert itself), or more generally, to understand whether the triggering event actually requires some kind of intervention. The agent is provided with access in step 1130 and can access the interaction in real time or the interaction's history. Depending on the communication type, the agent may be able to fast-forward / rewind the interaction, and the record of the interaction itself (i.e., the actual messages sent by the customer to the bot, and vice versa) may be supplemented by metadata including timestamps, context, intent, transcription, and a record of bot processing (e.g., for each response from the bot, the agent may be able to look behind the actual response and learn why it was chosen, or perhaps see other responses that were considered but not chosen). In fact, any information deemed useful to the agent for diagnosing and correcting problems in the interaction may be suitably provided.

[0222] Following the agent accessing the alert and the dialogue, the automated dialogue engine can pause in providing the outgoing message to await input from the agent (step 1135), or it can continue to operate normally, with an autonomous response being given to the customer (step 1140). If autonomous operation is employed, this can be modified to introduce pauses that allow the agent to intervene or not, but not unnecessarily interrupt the conversation if the agent is too busy to intervene or determines that intervention is not necessary (recognizing that the same agent may be watching the conversation of several bots at the same time).

[0223] If the agent chooses to intervene after step 1140 or is forced to intervene to provide a response after step 1135, the agent's intervention is received as a command from the agent station in step 1145. Typically, this is the selection of a response from a list of possible responses suggested by the bot, the entry of a custom response, or the selection of a response from a list of "canned" responses available in the agent's interface. In some scenarios, the command may cause the conversation to be transferred from the bot to a human agent in the contact center or another automated system. However, in the context of FIG. 11 , the agent's intervention guides the bot to send an appropriate response in step 1150. The agent can choose to end supervision of the conversation at any time, for example, after directing a single response as in step 1150, without sending any control command, or the agent can remain connected to the conversation, continuing to monitor and direct the bot's responses until the conversation is finished or until a determination is made that further assistance to the bot is not required.

[0224] Computer Systems

[0225] In one embodiment, each of the various servers, controllers, switches, gateways, engines, and / or modules (collectively referred to as servers) in the illustrated figures is implemented via hardware or firmware (e.g., ASIC), as will be understood by those skilled in the art. Each of the various servers may be a process or thread running on one or more processors, executing computer program instructions in one or more computing devices (e.g., FIGS. 12A and 12B), and interacting with other system components to perform the various functions described herein. The computer program instructions are stored in memory, which may be implemented in the computing device using standard memory devices such as RAM. The computer program instructions may also be stored on other non-transitory computer-readable media, such as CD-ROMs, flash drives, etc. Those skilled in the art will recognize that a computing device may be implemented via firmware (e.g., application-specific integrated circuits), hardware, or a combination of software, firmware, and hardware. Those skilled in the art should also recognize that the functionality of various computing devices may be combined or integrated into a single computing device, or that the functionality of a particular computing device may be distributed among one or more other computing devices without departing from the scope of the exemplary embodiments of the present invention. A server may be a software module, which may also be referred to simply as a module. A set of modules in a contact center may include servers and other modules.

[0226] The various servers may be located on on-site computing devices in the same physical location as the contact center agents, or may be located off-site in a different geographic location, e.g., a remote data center connected to the contact center via a network such as the Internet. Furthermore, some of the servers may be located within on-site computing devices at the contact center, while other servers may be located within off-site computing devices, or servers providing redundant functionality may be provided via both on-site and off-site computing devices to provide greater fault tolerance. In some embodiments, functionality provided by servers located on off-site computing devices may be accessed and provided via a virtual private network (VPN) as if such servers were on-site, or functionality may be provided using software as a service (SaaS) to provide functionality over the Internet using various protocols, such as by exchanging data using extensible markup language (XML) or JavaScript Object notation (JSON) encoding.

[0227] 12A and 12B are diagrams illustrating one embodiment of a computing device, generally designated 1200, that may be employed in embodiments of the present invention. Each computing device 1200 includes a CPU 1205 and a main memory unit 1210. As illustrated in FIG. 12A, computing device 1200 may also include a storage device 1215, a removable media interface 1220, a network interface 1225, an input / output (I / O) controller 1230, one or more display devices 1235A, a keyboard 1235B, and a pointing device 1235C (e.g., a mouse). Storage device 1215 may include storage for, but is not limited to, an operating system and software. As shown in FIG. 12B, each computing device 1200 may also include additional optional elements, such as a memory port 1240, a bridge 1245, one or more additional I / O devices 1235D, 1235E, and a cache memory 1250 in communication with CPU 1205. Input / output devices 1235A, 1235B, 1235C, 1235D, and 1235E may be collectively referred to herein as 1235.

[0228] The CPU 1205 is any logic circuit that responds to and processes instructions fetched from the main memory unit 1210. For example, the CPU 1205 may be implemented in an integrated circuit in the form of a microprocessor, microcontroller, or graphics processing unit, or in a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). The main memory unit 1210 may be one or more memory chips that store data and allow any storage location to be directly accessed by the central processing unit 1205. As shown in FIG. 12A, the central processing unit 1205 communicates with the main memory 1210 via a system bus 1255. As shown in FIG. 12B, the central processing unit 1205 may also communicate directly with the main memory 1210 via a memory port 1240.

[0229] In one embodiment, CPU 1205 may include multiple processors and may provide functionality for concurrent execution of instructions or concurrent execution of a single instruction on one or more pieces of data. In one embodiment, computing device 1200 may include a parallel processor having one or more cores. In one embodiment, computing device 1200 comprises a shared-memory parallel device with multiple processors and / or multiple processor cores that access all available memory as a single global address space. In another embodiment, computing device 1200 is a distributed-memory parallel device with multiple processors, each of which accesses only local memory. Computing device 1200 may have both some memory that is shared and some memory that can only be accessed by a specific processor or subset of processors. CPU 1205 may include a multi-core microprocessor that combines two or more independent processors in a single package, e.g., on a single integrated circuit (IC). For example, computing device 1200 may include at least one CPU 1205 and at least one graphics processing unit.

[0230] In one embodiment, CPU 1205 provides single instruction multiple data (SIMD) functionality, e.g., the ability to execute a single instruction on multiple pieces of data simultaneously. In another embodiment, some processors within CPU 1205 may provide the ability to execute multiple instructions on multiple pieces of data simultaneously (MIMD). CPU 1205 may also use any combination of SIMD and MIMD cores within a single device.

[0231] 12B shows an embodiment in which the CPU 1205 communicates directly with the cache memory 1250 via a secondary bus, sometimes referred to as a backside bus. In other embodiments, the CPU 1205 communicates with the cache memory 1250 using a system bus 1255. The cache memory 1250 typically has a faster response time than the main memory 1210. As illustrated in FIG. 12A, the CPU 1205 communicates with various I / O devices 1235 via a local system bus 1255. Various buses may be used as the local system bus 1255, including, but not limited to, a Video Electronics Standards Association (VESA) local bus (VLB), an Industry Standard Architecture (ISA) bus, an Extended Industry Standard Architecture (EISA) bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI Extended (PCI-X) bus, a PCI-Express bus, or a NuBus. In embodiments where the I / O device is a display device 1235A, the CPU 1205 may communicate with the display device 1235A via an Advanced Graphics Port (AGP). FIG. 12B illustrates an embodiment of a computer 1200 in which the CPU 1205 communicates directly with an I / O device 1235E. FIG. 12B also illustrates an embodiment in which local bus and direct communication are mixed. CPU 1205 communicates with I / O device 1235D using local system bus 1255 while communicating directly with I / O device 1235E.

[0232] A wide variety of I / O devices 1235 may be present in computing device 1200. Input devices include one or more keyboards 1235B, a mouse, a trackpad, a trackball, a microphone, and a drawing board, to name a few non-limiting examples. Output devices include a video display device 1235A, speakers, and a printer. The I / O controller 1230 shown in FIG. 12A may control one or more I / O devices, such as a keyboard 1235B and a pointing device 1235C (e.g., a mouse or optical pen).

[0233] 12A , computing device 1200 may support one or more removable media interfaces 1220, such as a floppy disk drive, a CD-ROM drive, a DVD-ROM drive, tape drives of various formats, a USB port, a Secure Digital or Compact Flash™ memory card port, or any other device suitable for reading data from read-only media, or for reading data from or writing data to read-write media. I / O device 1235 may be a bridge between system bus 1255 and removable media interface 1220.

[0234] The removable media interface 1220 may be used, for example, to install software and programs. The computing device 1200 may further include a storage device 1215, such as one or more hard disk drives or a hard disk drive array, for storing an operating system and other related software, and for storing application software programs. Optionally, the removable media interface 1220 may also be used as a storage device. For example, the operating system and software may be executed from bootable media, such as a bootable CD.

[0235] In one embodiment, computing device 1200 may include or be connected to multiple display devices 1235A, each of which may be the same or different types and / or forms. Accordingly, either I / O device(s) 1235 and / or I / O controller(s) 1230 may include any type and / or form of suitable hardware, software, or combination of hardware and software to support, enable, or provide for computing device 1200 to connect to and use multiple display devices 1235A. For example, computing device 1200 may include any type and / or form of video adapter, video card, driver, and / or library for interfacing, communicating with, connecting to, or otherwise using display device(s) 1235A. In one embodiment, a video adapter may include multiple connectors for interfacing to multiple display devices 1235A. In another embodiment, computing device 1200 may include multiple video adapters, each connected to one or more of the display devices 1235A. In other embodiments, one or more of the display devices 1235A may be provided by one or more other computing devices connected to the computing device 1200, for example, via a network. These embodiments may include any type of software designed and constructed to use a display device of another computing device as a second display device 1235A for the computing device 1200. Those skilled in the art will recognize and understand the various ways and embodiments in which the computing device 1200 may be configured to have multiple display devices 1235A.

[0236] 12A and 12B may operate under the control of an operating system, which controls the scheduling of tasks and access to system resources. Computing device 1200 may run any operating system, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein.

[0237] Computing device 1200 may be any workstation, desktop computer, laptop or notebook computer, server machine, handheld computer, mobile phone or other portable telecommunications device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunications, or media device capable of communications and having sufficient processor power and memory capacity to perform the operations described herein. In some embodiments, computing device 1200 may have different processors, operating systems, and input devices consistent with the device.

[0238] In other embodiments, computing device 1200 is a mobile device. Examples may include a Java-enabled mobile phone or personal digital assistant (PDA), a smartphone, a digital audio player, or a portable media player. In one embodiment, computing device 1200 includes a combination of devices, such as a mobile phone combined with a digital audio player or portable media player.

[0239] The computing device 1200 may be one of multiple machines connected by a network or may include multiple machines so connected. A network environment may include one or more local machines, client nodes, client machines, client computers, client devices, endpoints, or endpoint nodes that communicate with one or more remote machines (which may also be generally referred to as server machines or remote machines) over one or more networks. In one embodiment, a local machine has the ability to function both as a client node seeking access to resources provided by a server machine and as a server machine providing access to hosted resources for other clients. The network may be a LAN or WAN link, a broadband connection, a wireless connection, or a combination of any or all of the above. Connections may be established using various communication protocols. In one embodiment, the computing device 1200 communicates with other computing devices 1200 through any type and / or form of gateway or tunneling protocol, such as Secure Socket Layer (SSL) or Transport Layer Security (TLS). A network interface may include a built-in network adapter, such as a network interface card, suitable for interfacing a computing device to any type of network over which it can communicate and performing the operations described herein. An I / O device may be a bridge between a system bus and an external communication bus.

[0240] In one embodiment, the network environment may be a virtual network environment in which various components of the network are virtualized. For example, various machines may be virtual machines implemented as software-based computers running on physical machines. The virtual machines may share the same operating system. In other embodiments, different operating systems may run on each virtual machine instance. In one embodiment, a "hypervisor" type of virtualization is implemented in which multiple virtual machines run on the same host physical machine, each functioning as if it had its own dedicated box. Virtual machines may also run on different host physical machines.

[0241] Other types of virtualization are also contemplated, such as, for example, the network (e.g., via Software Defined Networking (SDN)). Functions, such as the function of the Session Border Controller and other types of functions, may also be virtualized, such as, for example, via Network Functions Virtualization (NFV).

[0242] While the invention has been illustrated and described in detail in the drawings and foregoing description, it is to be considered illustrative and not restrictive in character, it being understood that only the preferred embodiment has been shown and described, and that all equivalents, changes, and modifications that come within the spirit of the invention as set forth in this specification and / or the following claims are desired to be protected.

[0243] Therefore, the appropriate scope of the present invention should be determined only by the broadest interpretation of the appended claims so as to encompass all such modifications and all equivalent relationships as illustrated in the drawings and described herein.

Claims

1. 1. A computer-implemented method for managing interactions between a contact center system and its users, comprising: hosting a dialogue over a communication channel between an automated dialogue engine of the contact center and the user thereof, the dialogue including messages sent in both directions between the automated dialogue engine and the user; b. the automated dialogue engine receiving an input message from the user and determining a response message in response to the input; c) detecting a trigger event from said messages of said interaction that matches a rule; d. in response to detecting the trigger event; i. providing a summary of said interaction to said agent station; ii. providing control of the automated dialogue engine to the agent station.

2. The method of claim 1 , wherein the summary comprises a transcript of the interaction.

3. The method of claim 1 , wherein the summary includes information obtained from multiple data sources based on the interactions.

4. The method of claim 1 , further comprising pausing the automated dialogue engine from providing a response message after detecting the trigger event.

5. 5. The method of claim 4, wherein the provision of the response message is paused until an appropriate response message is selected at the agent station.

6. 6. The method of claim 5, wherein the agent station is provided with a plurality of possible response messages by the automated dialogue engine and is permitted to select an appropriate response message from among them.

7. 6. The method of claim 5, wherein the appropriate reply message is selected by composition of the message by a user of the agent station.

8. 2. The method of claim 1, wherein after the detection of the trigger event, the automated dialogue engine continues to autonomously determine and send a response message unless a control command to pause providing the response message is received from the agent station.

9. The trigger event is a. determining keywords in one or more input messages; b. determining a sentiment in one or more input messages; c. Determining changes in speech volume or pitch; d. Determining that the input message cannot be properly interpreted; e. Determining that a response message cannot be determined in response to the input message; f. Determining that a confidence level associated with the potential response message is below a predetermined threshold; g. determining that one or more incoming messages relate to a topic defined as requiring agent intervention; h. determining that one or more incoming messages relate to a topic for which agent intervention is defined as desirable; and i. Determining that agent intervention is requested by the user of the contact center.

10. 10. The method of claim 1, further comprising the automated dialogue engine modifying the rules according to which a response message is generated in response to observing control inputs received from the agent station.

11. 1. A system for managing interactions between a contact center system and its users, comprising: a processor; a memory storing instructions that, when executed by the processor, cause the processor to: operating an automated dialogue engine system engaged in a dialogue hosted over a communication channel between the contact center and the user, the dialogue including messages transmitted in both directions between the automated dialogue engine system and the user; b. accepting an input message from the user and determining a response message in response to the input; c) detecting a trigger event from the messages of the interaction that matches a rule; d. in response to detecting the trigger event; i. providing a copy of said interactive message to an agent station; ii. providing control of said automated dialogue engine to said agent station.

12. The system of claim 11 , wherein the summary includes a transcript of the interaction.

13. The system of claim 11 , wherein the summary includes information obtained from multiple data sources based on the interaction.

14. 12. The system of claim 11, wherein the memory stores instructions that, when executed by the processor, further cause the processor to pause providing the response message by the automated dialogue engine after detecting the trigger event.

15. 15. The system of claim 14, wherein the provision of the response message is paused until an appropriate response message is selected at the agent station.

16. 16. The system of claim 15, wherein the agent station is provided with a plurality of possible response messages by the automated dialogue engine and is permitted to select an appropriate response message from among them.

17. 16. The system of claim 15, wherein the appropriate reply message is selected by creation of the message by a user of the agent station.

18. 12. The system of claim 11, wherein after the detection of the trigger event, the automated dialogue engine continues to autonomously determine and send a response message unless a control command to pause providing the response message is received from the agent station.

19. The trigger event is a. determining keywords in one or more input messages; b. determining a sentiment in one or more input messages; c. Determining changes in speech volume or pitch; d. Determining that the input message cannot be properly interpreted; e. Determining that a response message cannot be determined in response to the input message; f. Determining that a confidence level associated with the potential response message is below a predetermined threshold; g. determining that one or more incoming messages relate to a topic defined as requiring agent intervention; h. determining that one or more incoming messages relate to a topic for which agent intervention is defined as desirable; and i. Determining that agent intervention is requested by the user of the contact center.

20. 12. The system of claim 11, wherein the automated dialogue engine is capable of modifying the rules according to which response messages are generated in response to observation of control inputs received from the agent station.

Images