A structured communication system integrating dynamic display.

Abstract

The communication system includes a processor and units executing on the processor that create and process dynamic representations of tickets, the tickets representing incoming events of supported systems supported by the communication system, the tickets further representing activity associated with the incoming events and status of multi-channel interactivity between clients and agents associated with the supported systems, the units further including a ticket subsystem that receives the incoming events, activity, and multi-channel interactivity from the communication channels and creates and updates tickets accordingly, and an inbox / feed subsystem that creates and displays a one-inbox feed of tickets for an agent.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 150,760, filed February 18, 2021, which is incorporated herein by reference.

[0002] The present invention relates to a system for providing communication and support to supported systems, and in particular to handling multi-channel interactivity. [Background technology]

[0003] Customer support systems (such as help desk systems) are known in the art. Typically, they enable a group of agents to support multiple customers through a system that tracks issues raised by calling users through tickets (also called "trouble tickets"). Such prior art systems typically track activities performed in relation to the associated issue, including agent comments and notes regarding actions taken or interactions made. Such systems often store the tickets in an underlying database and typically allow for reassignment of tickets from one agent to another, such as when a work shift ends or when a ticket is assigned to an agent with a particular required expertise.

[0004] U.S. Patent Publication No. 2014 / 0278646, published Sep. 18, 2014 and entitled "Work Assignment Queue Purging," describes a method for purging a work assignment queue using an ordered list of ticket assignment rules. Summary of the Invention

[0005] Thus, according to a preferred embodiment of the present invention, there is provided a communication system and a method implemented thereon, the system including a processor and a unit executing on the processor for creating and processing a dynamic representation of at least one ticket, the at least one ticket representing incoming events of a supported system supported by the communication system, the at least one ticket further representing activities related to the incoming events and a status of multi-channel interactivity between at least one client and at least one agent associated with the supported system, the unit including a ticket subsystem for receiving the incoming events, activities, and multi-channel interactivity from at least one communication channel and creating and updating at least one ticket accordingly, and an inbox / feed subsystem for creating and displaying a one-inbox feed of at least one ticket for at least one agent.

[0006] Furthermore, in accordance with a preferred embodiment of the present invention, the communications system is integrated with the supported systems.

[0007] Furthermore, in accordance with a preferred embodiment of the present invention, the system also includes a channel transformer that adapts a user interface of the communication system for communication with at least one client device belonging to at least one agent.

[0008] Further, in accordance with a preferred embodiment of the present invention, the system includes a repository that stores at least ticket information and parameters, agent profiles, administrative data, and predefined rules; a Data Collection, Recording, and Analysis (DGRA) subsystem that provides data collection and analysis of collected information for the ticket subsystem and the inbox / feed subsystem; a knowledge base (KB) creator and editor that creates and edits knowledge base content used by the ticket subsystem; a bot agent operator that integrates bot agents into the functionality of at least one agent; and a rules engine that provides rules, artificial intelligence, and machine learning support to the ticket subsystem, the inbox / feed subsystem, the DGRA subsystem, the KB creator and editor, and the bot agent operator.

[0009] Additionally, in accordance with a preferred embodiment of the present invention, the ticket subsystem includes at least one of a ticket handler for receiving incoming events, a ticket creator for creating tickets for incoming events, a ticket updater for updating tickets for incoming events according to changing interactivity and activity, a remote access handler for remotely accessing at least one client device and interacting with secondary devices connected to the device, a remote software handler for handling communications related to at least one of software installations, upgrades, and configuration changes to the device, a ticket input form builder for collecting tickets and inputting relevant information, a ticket displayer for preparing a representation of multiple concurrent activities and interactions of the ticket for display, and an association manager for handling associations between tickets, at least one client, and at least one agent.

[0010] Further, in accordance with a preferred embodiment of the present invention, the association manager includes a privilege / role manager that assigns rules and privileges to at least one agent of the communication system, and an agent set handler that handles the association of at least one agent with at least one ticket.

[0011] Further, in accordance with a preferred embodiment of the present invention, the inbox / feed subsystem includes an inbox generator for generating and updating a feed of at least one ticket for at least one agent, a feed displayer for dynamically generating user interface (UI) elements for displaying the feed, and a dynamic view constructor for constructing at least one view for displaying a list of agents registered with the communication system and their associated activity information.

[0012] Furthermore, in accordance with a preferred embodiment of the present invention, the inbox generator includes a feed constructor for constructing a feed, a feed updater for updating the feed according to activity information and requirements of at least one agent, a feed manager for managing a plurality of feeds, a query receiver and executor for instructing the feed constructor according to results of a query issued by at least one agent, and an information deriver for instructing the feed constructor according to information derived from at least one ticket.

[0013] Additionally, in accordance with a preferred embodiment of the present invention, the DGRA subsystem includes at least one of a data collector that collects and records information related to tickets, ticket interactions, and at least one agent activity, and a data analyzer that analyzes the information and generates automated actions for the ticket subsystem and the inbox / feed subsystem accordingly.

[0014] Further, in accordance with a preferred embodiment of the present invention, the data analyzer includes at least one of an agent activity manager that analyzes and evaluates agent activity of at least one agent, a recommender that makes ticket assignment recommendations to a manager of the at least one agent, a best practices analyzer that recognizes and highlights best practices of the at least one agent, an insight generator that generates insights according to pattern or trend analysis of the information, a notification generator that generates alerts and notifications for predefined situations, an auto-configurator that generates configuration changes to the communication system, an internal content generator that generates content for KB creators and editors, a ticket prioritizer and tagger that provides priority and tag information for at least one ticket, a BI (Business Information) analyzer that integrates business information from supported systems, and an automation trigger generator that triggers automation actions according to predefined rules.

[0015] Further, in accordance with a preferred embodiment of the present invention, the KB creator and editor includes at least one of a KB editor that provides authoring and design tools for creating embedded training materials and courseware for at least one agent and at least one client; a KB collection creator that creates collections of knowledge base articles for use by users of the supported system; a KB widget creator that creates widgets that are embedded in websites to display the knowledge base articles; and a KB processing engine that automatically selects, recommends, creates, modifies, or adapts knowledge base content according to collected information.

[0016] Furthermore, in accordance with a preferred embodiment of the present invention, the at least one ticket includes at least one of the following: a status of an interaction between at least one agent and at least one client, a start event, an end event, display forms and surveys, at least one agent's notes, ticket metadata, links to related tickets, knowledge base content, and ticket association information.

[0017] Additionally, according to a preferred embodiment of the present invention, the at least one communication channel is at least one of a social network, email, a shared virtual space, a web service, an organized communication system, an online forum, an online chat room, and a messaging system.

[0018] Furthermore, in accordance with a preferred embodiment of the present invention, the feed display creates a composite user interface that shows different levels of multiple channels of interactivity with incoming events.

[0019] Further in accordance with a preferred embodiment of the present invention, the ticket display displays a single ticket view representing activity and multiple channel interactivity.

[0020] Still further, in accordance with a preferred embodiment of the present invention, the ticket display displays a summarized version of the multi-channel interactivity according to analysis of the stored communication data by a rules engine.

[0021] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of this specification, however the invention, both as to its organization and method of operation, together with its objects, features, and advantages, may best be understood by reference to the following detailed description taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0022] [Figure 1A]1 is a schematic diagram of a communications system associated with a supported system constructed and operative in accordance with the present invention; [Figure 1B] 1 is a schematic diagram of a communications system associated with a supported system constructed and operative in accordance with the present invention; [Diagram 2] 1 is a schematic diagram of a typical representation of a prior art website building system; [Diagram 3] 1B is a schematic diagram of the communication system of FIG. 1B integrated with a website building system and constructed and operative in accordance with the present invention; [Figure 4] FIG. 2 is a schematic diagram of a multiple channel communication system used by the communication system of FIGS. 1A and 1B, constructed and operative in accordance with the present invention; [Diagram 5] FIG. 2 is a schematic diagram of sub-elements of the communications system of FIGS. 1A and 1B, constructed and operative in accordance with the present invention; [Figure 6] 1 is a schematic diagram of an example ticket constructed and operative in accordance with the present invention; [Figure 7] 1C is an example screenshot of an agent's work screen operating in the communications system of FIGS. 1A and 1B, constructed and operative in accordance with the present invention; [Figure 8] 1 is an example screenshot of an agent display showing an example ticket with attempted client communication, constructed and operative in accordance with the present invention; [Figure 9] 6 is a schematic diagram of elements of the ticket subsystem of FIG. 5 constructed and operative in accordance with the present invention; [Figure 10] 1 is a schematic diagram illustrating an exemplary user interface of an inbox feed, including active and inactive sections, constructed and operative in accordance with the present invention; [Figure 11] 6 is a schematic diagram of elements of the inbox / feed subsystem of FIG. 5, constructed and operative in accordance with the present invention. [Figure 12] 1A and 1B, constructed and operative in accordance with the present invention, is a schematic diagram of an exemplary user interface illustrating the status of an agent in the communication system of FIGS. [Figure 13] 6 is a schematic diagram of sub-elements of the Knowledge Base (KB) Creator and Editor of FIG. 5 with an exemplary UI showing a list of agents, constructed and operative in accordance with the present invention; [Figure 14] FIG. 6 is a schematic diagram of sub-elements of the data acquisition, recording and analysis (DGRA) subsystem of FIG. 5, constructed and operative in accordance with the present invention. [Figure 15] 1 is a schematic diagram of an example trigger activation scenario constructed and operative in accordance with the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

[0024] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments of the present invention.

[0025] Applicant has recognized that in order to efficiently serve customers, the described prior art systems require options for advanced communication between groups of people within the same organization who can work together to collaborate, interact, or support people outside the organization. Such communication may occur via the web or other Internet environments, via virtual / augmented reality environments, or via other non-web platforms and environments. These outsiders are typically referred to as clients (but may also be referred to as users or end users).

[0026] A client may be external to the organization that operates the system (herein "the organization"), such as a client who is an end user of a company's services. A client may also be internal to the organization, such as an office worker who calls an internal help desk.

[0027] Applicant further recognized that such a system should be a multi-channel structured communication system that integrates dynamic display of communication channels with multiple levels of interactivity. Such a system should provide structured processing and management of such channels along with collection and analysis of underlying data along with a level of automation based on the collected data. Applicant also recognized that such a system may be standalone or may be used in conjunction with an underlying supported system, such as in an embodiment involving customer support.

[0028] Examples of such supported systems are website building systems (WBS) and electronic commerce systems. In the case of a website building system, the users of the website building system, i.e. the designers or the end users of the designed websites, are potential clients who contact the agents (who work for the website system vendor via a communication system).

[0029] Applicant also recognized that the system can support novel features such as the generation of a one-in-box display generated from different interactivity of multiple channels to be processed according to interactivity. The system should also be able to display activities with different levels of interactivity, combine instantaneous and long-term communication, combine synchronous and asynchronous communication, and combine non-communication activities. These may include non-communication activities such as the intervention of a user's client device. Intervention may include installation, upgrades, updates, configuration, etc.

[0030] Applicant also recognized that prior art systems typically involve rigid assignment and routing of tickets rather than allowing agents the ability to monitor feeds and manually select and participate in specific tickets or be assigned based on agent performance parameters.

[0031] The system also needs to combine inbound and outbound communications, and one-way and two-way communications.

[0032] Applicant has further recognized that the system of the present invention must have at least two levels of involvement with tickets. For example, one level may be the ticket owner or subscriber and another level may be a participant in a particular activity such as a conference call. The system should allow sorting and selection by interactivity level of composite tickets and additional criteria. Tickets are described in more detail below.

[0033] The ticket user interface should also display dynamic interactivity based on content and communication analysis (e.g., long chat sessions where nothing happens), the ticket display should include multiple activities and interactions, and allow tracking and participation in multiple interactions with various levels of interactivity. The system should also allow the use of a miniplayer for interaction display.

[0034] Other functionality should include generating inbox views of tickets from a particular perspective, for example showing what a particular agent sees (with or without agent selection / sorting criteria) and the ability to transform channels according to how the agent is connected.

[0035] The system should further support data analysis using a rules engine (employing artificial intelligence (AI) and machine learning (ML) techniques) including best practice recognition, insights, system configuration changes, article generation, and bot integration, which should include human-to-bot and bot-to-human transitions.

[0036] 1A and 1B, there are shown two different embodiments of an implementation of a communication system 80 including a supported system 100, according to one embodiment of the present invention. Figure 1A shows a stand-alone or separate system 80 in communication with a supported system 100, while Figure 1B shows an integrated version.

[0037] It will be appreciated that the communications system 80 can handle communications between agents (of the supported system 100) and clients, as well as communications involving multiple agents and / or multiple clients. The latter case may arise in a multi-level client situation, such as a support issue involving a product company, an outside distributor who sold and installed the product, and the actual end user who purchased the product. Another case is providing support for the system 100, whose operation requires the cooperation of multiple users / clients. Thus, users of the system 80 may be clients and agents.

[0038] As discussed herein above, the supported system 100 may be a website building system (WBS). A WBS typically handles the creation and editing of visually designed applications (such as websites) that are composed of pages, containers, and components. Pages are represented individually and may contain components. Components may include atomic components as well as containers. Reference is now made to FIG. 2, which is a schematic block diagram of a website building system (WBS) 2 that may be used to build a website 3, according to some exemplary embodiments of the present invention. The WBS 2 may be used to build, create, edit, and / or generate a website 3 that may include pages 4 that may include components 6 (e.g., text, images, videos).

[0039] Typical site creation can be based on a number of models, including a visual editing model (where a user edits a previously created site) and an automated site generation model, or a combination thereof, as shown in FIG. 3, reference being made here to U.S. Pat. No. 10,073,923, entitled “System and Method for the Creation and Update of Hierarchical Websites Based on Collected Business Knowledge,” issued on September 11, 2018, which is co-owned by the applicant and incorporated herein by reference.

[0040] 3 illustrates an integrated system 200 according to one embodiment of the present invention. The integrated system 200 includes a typical WBS 2 in communication with client systems operated by WBS vendor staff 61, site designers 62 (i.e., users), site users 63 (i.e., users of users), and external systems 70. The WBS 2 may further include a WBS Site Manager 10, an object marketplace 15, a WBS RT (runtime) server 20, a WBS editor 30, a site generation system 40, a WBS content management system (CMS) 50, and a communication system 80. It will be appreciated that the user and site information stored in the CMS 50 may be used for analysis (as described in more detail herein below).

[0041] Thus, there may be two-way integration between communication system 80 and supported system 100, which may include two-way data access, use of communication channels, and possible integration of the UI (user interface) of system 80 hosted within the supported system UI. This may be different from a typical third-party integration where one system primarily provides services to the other system.

[0042] It will be understood that the following description refers to people (e.g., members, employees, or consultants) of a single organization, however, communication system 80 may be deployed for use by a collaborating set of people from multiple organizations.

[0043] It will further be appreciated that communications system 80 may support not only fully automated nodes (e.g., bots or other computerized elements communicating with communications system 80), but also semi-automated nodes (e.g., people communicating via communications system 80 who are assisted in their communications by automated means), as described in more detail below.

[0044] It will also be appreciated that communication can be initiated by either the client (e.g., a client calling a customer support line) or the supported system 100 (e.g., a sales organization making an outbound call to a potential client). Initiated communication can be synchronous (e.g., video conferencing), asynchronous (email correspondence), or both. Communication may also be capable of switching both modes and / or directions. For example, an outgoing video call may be initiated by an incoming email from a customer.

[0045] In the following description, the communications system 80 is described in the context of a customer support system, but it is applicable to multiple application areas, such as sales centers (inbound and outbound), brokerage firms, order centers, telemedicine call centers, IT help desks, internal communications (structured communications), and building and leveraging internal knowledge bases.

[0046] Communicating members of an organization or supported system 100 may be referred to as "agents" (e.g., support agents) even though they may not be actual agents. For example, in the case of an embodiment of communication system 80 within a customer support center operated by a software company, interactions may involve actual support agents (known as customer-facing agents) as well as other employees of the organization (such as employees in the quality assurance (QA) department, product, documentation, or engineering teams). Also, in other situations (other than customer support), "agents" may take on entirely different roles within the organization. It will be understood that there are actual organizational roles for agents that are not roles within communication system 80 (as will be described in more detail below).

[0047] It will also be appreciated that some embodiments of communication system 80 may require tighter integration with supported system 100. For example, supported system 100 may display different variations of a "call support" widget or UI element that can be used by a user to initiate support while providing the inventive system with context and data specific to the supported system area for which support is being invoked.

[0048] The system 80, agents and clients can communicate through different channels with different levels of interactivity, where interactivity is defined based on the expectation of rapid response as well as the level of engagement of the communicating parties.

[0049] Reference is now made to Figure 4, which illustrates a communication system 80 in two-way communication using different examples of communication channels. It will be understood that this can be implemented using any suitable interface. The channels include, but are not limited to, telephone / VOIP (Voice Over Internet Protocol), live chat, video conferencing / chat, shared virtual spaces (virtual reality / augmented reality based), and direct online communication such as messaging systems such as WhatsApp (commercially available from Meta Platforms, Inc.), Telegram (commercially available from Telegram.ORG), or SMS (Short Messaging System).

[0050] Channels may also include organizational communication systems such as Slack (commercially available from Salesforce) or social networks such as Facebook (commercially available from Meta Platforms, Inc.) or Twitter (commercially available from Twitter, Inc.), and typically include multiple means of communication within them (e.g., post / reply, direct messaging, embedded chat, etc.).

[0051] Other communication channels may be via inbound communications such as email, online forums or chat rooms, contact forms, information collected in an IVR (Interactive Voice Response), inbound fax, or fax-to-email. Such communications may continue through other (mainly online) channels.

[0052] Web services and other inter-process or inter-system communication methods may also allow automated communication sources to participate. Such sources may be initiators (e.g., automatically making sales calls, sending email invitations, calling support to report system issues, etc.) as well as responders (e.g., support agent bots, described in more detail below). Another form of communication channel is any type of shared virtual space, such as collaboratively edited documents, spreadsheets, whiteboards, drawing spaces (2D or 3D), virtual environments, or other shared spaces.

[0053] It will be appreciated that many of these channels may involve multi-party communications (where applicable), including, for example, multiple agents and / or multiple clients.

[0054] It will be further understood that some of these channels may have different states at different times. For example, a chat session between an agent and a client may be silent for some time, or may be in a "typing..." state, i.e., one of the parties is about to send a message. Such states may be associated with a level of interactivity of the channel. For example, an active chat session is considered more interactive than one that has not been active for some time. States may also be associated with delivery status, such as whether a message has been sent, seen, read or unread, etc.

[0055] It will also be appreciated that the interactivity state definitions for a given channel type need not form a separate set: some channels may provide a continuous (or semi-continuous) indication of interactivity levels based (for example) on the time since the last interaction.

[0056] Reference is now made to FIG. 5, which illustrates different elements of a communications system 80.

[0057] The communication system 80 may include a channel transformer 81, a ticket subsystem 82, an inbox / feed subsystem 83, a rules engine 84, a repository 85, a knowledge base (KB) creator and editor 86, a DGRA (data collection, recording and analysis) subsystem 87, and a bot agent operator 88. The rules engine 84 may further include an AI (artificial intelligence) / ML (machine learning) engine 841. The bot agent operator 88 may further include an interaction assistant 881. The functionality of these elements is described in more detail below in this specification.

[0058] The repository 85 may store information and parameters about both open and closed tickets (live or archived), including ticket history, interaction and communication data. The repository 85 may also store data used for analysis, automation, reporting, visualization, management and other purposes along with the rules of the rules engine 84, as described in more detail below. The repository 85 may also store agent profile and management data, as described in more detail below.

[0059] The channel transformer 81 can allow agents to connect to the system 80 in multiple ways (e.g., phone, regular display, VR, etc.) by adapting the UI of the communication system 80 to the agent's preferred method of communication. It will be appreciated that the channel transformer can do this using information provided to the server, through code execution on the client, or through a portion of the channel transformer 81 running on the client itself. The channel transformer 81 can also adapt the communication itself. For example, for an agent providing support through a small screen smartphone, the channel transformer 81 can use downscaled video instead of the full-scale video used for a desktop-connected agent.

[0060] The channel transformer 81 may implement some of the envisioned channels in a number of ways, such as internally (implementing its own video conferencing client or server infrastructure), by integrating with an external system that implements the relevant communication channel (e.g., integrating with the Zoom video conferencing system by Zoom Video Communication Inc. to provide a video conferencing channel), or through integration with the supported system 100. For example, in this integration scenario, a website building system (WBS) supported system may provide a "call support" widget or other UI element that can be integrated with a site built using the WBS.

[0061] It will be appreciated that all activity in the communication system 80 may be organized around tickets, and further, while the terminology of tickets is common in the art related to customer support, it will be appreciated that the communication system 80 may be used in other applications as discussed above in this specification.

[0062] Reference is now made to Figure 6, which illustrates a typical ticket 5 for use within a communications system 80. Tickets are created in response to incoming events or concerns and can include many elements, it being understood that no two tickets are the same. The ticket 5 may include elements (not all shown) such as activity (interactions, communication records, status / interactivity level) (a), start event / interaction (b), end event / interaction (c), display forms and surveys (initial form, in-ticket form, post-contact form) (d), representative activity display, agent association information, links to related tickets, agent notes (c), attachments, ticket metadata (f), external / internal links (g) (internal links / URLs, related information, external links to elements of the supported system 100, linked knowledge base articles), analysis results (h), event records, ticket labels / text, ticket status (information / events from the supported system 100, extracted information, support / interaction related information), and system additional information (analysis results and recommendations, and extracted / derived information).

[0063] 7, an example of an agent's work screen is shown, including a list of views, a list of active and inactive tickets, and a specific ticket display, including WhatsApp chat interactions and call notes.

[0064] With reference also to FIG. 8, an agent display showing an example ticket on which a client communication was attempted is shown.

[0065] As described herein above, the rules engine 84 may include an AI / ML engine 841 that may use AI and ML techniques to provide services to the elements and sub-elements of the system 80. It will be understood that any ML model used may be any model suitable for the relevant task or activity. Machine learning models are known in the art and are typically some form of neural network. The term refers to the ability of a system to recognize patterns and provide solution concepts based on existing algorithms and data sets. The more it is trained, the more knowledge is developed. It will be understood that the AI / ML engine 841 may also train models using data external to the system 80 (i.e., not stored in the repository 85).

[0066] The ML model used may be a learning model (supervised or unsupervised), as described in more detail below. By way of example, such algorithms may be prediction (e.g., linear regression) algorithms, classification (e.g., decision trees, k-nearest neighbors) algorithms, time series prediction (e.g., regression-based) algorithms, association algorithms, clustering algorithms (e.g., K-means clustering, Gaussian mixture models, DBscan), or Bayesian methods (e.g., Naive Bayes, Bayesian model averaging, Bayesian adaptive trials), image-to-image models (e.g., FCN, PSPNet, U-Net), sequence-to-sequence models (e.g., RNN, LSTM, BERT, autoencoders) or generative models (e.g., GAN).

[0067] Alternatively, the ML models used may implement statistical algorithms such as dimensionality reduction, hypothesis testing, one-way analysis of variance (ANOVA) testing, principal component analysis, conjoint analysis, neural networks, support vector machines, decision trees (including random forests), ensemble techniques, and other techniques. Other ML models 317 may be generative models (such as generative adversarial networks or autoencoders) for generating solution elements (such as website building system elements and media objects).

[0068] In most embodiments, the ML models used undergo a training or learning phase before being released into production or into the runtime phase, or can begin working with models from existing systems or models. During the training or learning phase, the ML models can be tuned to focus on specific variables, reduce error margins, or optimize performance.

[0069] ML models can be implemented in rule-based systems, such as expert systems or hybrid intelligent systems that incorporate multiple AI techniques, as described in the Wikipedia articles titled "Rule-Based System" and "Hybrid Intelligent System" at en.wikipedia.com.

[0070] The ticket subsystem 82 may be responsible for creating, processing, and implementing tickets. Reference is now made to FIG. 9, which illustrates elements of the ticket subsystem 82. The ticket subsystem 82 may include a ticket handler 821, a ticket creator 822, a ticket updater 823, a remote access handler 824, a remote software handler 825, a ticket input form builder 826, a ticket displayer 827, and an association manager 828. It will be appreciated that the ticket subsystem 82 may also incorporate the output of a KB (knowledge base) creator and editor 86 and a DGRA subsystem 87 into the ticket, as described in more detail below.

[0071] As described herein above, a single ticket 5 can include a series of activities. The primary activity type can be the interaction between agent(s) and client(s) regarding a single event or concern.

[0072] It will be further understood that the ticket 5 can include various time-related elements, which may be instantaneous or occur over a period of time. Such elements may include (for example), interaction activities (such as emails or video conferences), non-interaction activities (such as remote access to a user's machine or filling out an online feedback form), agent association activities (such as agents or agent groups joining or leaving the ticket), and additional information such as internal notes, attachments, links to other tickets or data. Further elements may include system additional information such as results of business information (BI) analysis, recommendations made by the KB creators and editors 86 and the DGRA subsystem 87, extracted or derived information (such as call transcripts or client speech / sentiment analysis). The ticket 5 may also include non-time-related elements, such as metadata and ticket parameters.

[0073] The ticket handler 821 can receive a particular opening event or interaction (e.g., a client calls in via phone or video chat, or sends a support request email) and can instruct the ticket creator 822 to create a ticket 5. In alternative embodiments, the ticket 5 may be explicitly created. It will be appreciated that the ticket 5 may also have a closing event (e.g., the ticket is closed by an agent after the issue is resolved), which may result from a trigger rule as described above ("close pending tickets after 72 hours"). More details are provided below.

[0074] The ticket updater 823 can update the ticket in response to changing activity, status, and collected information (e.g., as the ticket accumulates additional information relevant to the problem description and resolution). The ticket updater 823 can also include recommendations provided by the DGRA subsystem 87, as described in more detail below.

[0075] The remote access handler 824 can remotely access the client's machine (or another client device, such as a smartphone), for example, through a conventional remote access platform or through specific functionality integrated into the supported system 100.

[0076] The remote access handler 824 may also interact with secondary devices connected to the client device, such as industrial or other equipment connected to the client device (e.g., to support an industrial facility) or medical sensors or other equipment connected to the client device (e.g., to support telemedicine applications).

[0077] It will be appreciated that tickets 5 may also include activities that are not interactions or other communications over one of the channels. Remote software handler 825 may handle activities that cause an intervention in which an agent initiates a software upgrade, installation, or reconfiguration on a client site or server (or other subsystem) associated with the supported system. While such activities are not interpersonal communications, they may still be substantial events. Such activities may or may not be instantaneous (e.g., a large software upgrade may take hours to complete).

[0078] A ticket entry form builder 826 can collect and fill in the required ticket information, as described in more detail below.

[0079] The ticket display 827 may provide a single ticket display (e.g., displaying various activities within a ticket). This may be a separate area within a complete display (generated by the inbox / feed subsystem 83) or may be integrated with a feed or inbox display (e.g., displaying a list of tickets that include several elements of a single ticket display). It will be appreciated that the display of the ticket 5 may include any combination of immediate and long-term communication, any combination of synchronous and asynchronous communication, and any combination of non-communication activities such as client intervention (as described above in this specification). It will be appreciated that the display of the ticket 5 by the ticket display 827 may include a representation of multiple concurrent activities and interactions (some of which may be "open" at the same time). For example, the reply area (or "reply box") is typically at the bottom, and the system 80 may enable a single reply to the area to provide multiple communication channels (e.g., chat, email, SMS, social media, etc.), with the agent specifying which of the open channels they wish to respond to (based on the available channels).

[0080] The ticket display 827 can display long interactions (e.g., phone calls) as parallel activities (as shown in FIG. 7, which is also referred to herein). Alternatively, it can display start / end markers of related long interactions (with shorter or intersecting activities having their own markers at the appropriate points). The ticket display 827 can further display processed versions of long interactions, e.g., frames extracted from a long video call or screen sharing session, extracted audio segments, or stages extracted from a remote intervention session (such as the various stages of a software upgrade performed remotely on a client's machine). To do this, the ticket display 827 can extract the relevant stored communication data, analyze it (possibly using the AI / ML engine 841), and summarize it to create a summarized version of the relevant parts of the long interaction. The analysis function can provide further training material to the AI / ML engine 841 (described later herein) based on the agent's actual usage or feedback provided by the agent regarding the quality of the extraction, analysis, and summarization.

[0081] It will be appreciated that multiple agents may be associated with a single ticket 5 and may join or leave the association, and thus the ticket 5 does not "move" between agents (the original agent loses visibility to the ticket and its activity), rather each ticket 5 may have a changing set of agents over time.

[0082] The association manager 828 can handle associations between tickets, agents, and clients, and can grow or shrink associations as needed. The association manager 828 can further include a privilege / role manager 8281 and an agent set handler 8282.

[0083] It will be appreciated that the association manager 828 can associate tickets using additional association information beyond just the assigned agent identification. For example, the agent set handler 8282 can include agent contact information (e.g., communication channel ID (identifier) ​​or credentials) and can support multiple such sets of information per agent. Thus, for example, a client may contact an agent via a work smartphone and the agent may want to switch to another smartphone and continue the interaction. Similarly, an agent may want to switch one agent's email to another email. The agent set handler 8282 can support these changes in assignments and "sub-assignments," as well as continuity of the interaction.

[0084] It will be appreciated that agents associated with a ticket 5 may generally be considered equivalent to one another. However, the agent set handler 8282 may designate a primary owner who is the primary owner associated with the ticket. This may be determined according to the agent who opened the ticket (or the first responder if opened automatically and assigned to multiple agents), the agents involved in the primary interactions (as defined above), or may be determined automatically based on an analysis of the interactions (including type, amount, and content).

[0085] The agent set handler 8282 may also change owners over time (possibly independently of the ticket assigned agent set).

[0086] The privilege / role manager 8281 can assign specific roles to specific agents, for example the agent responsible for ensuring that the ticket is closed (who may be different from the initial agent who receives the call). These may be generic roles (team member, administrator, etc.) or custom defined roles.

[0087] Users of different communication systems 80 may have certain privileges related to their agent assignments, such as a manager or administrator having certain privileges within a group of agents that they manage.

[0088] The privilege / role manager 8281 can define specific privileges related to the use of or access to system resources. For example, some finance related knowledge base articles may only be exposed to certain agents. Similarly, users of system resources (including the ability to interact with them) may be restricted. For example, only certain agents may contact senior technical developers within an organization to be involved in client tickets.

[0089] The Privilege / Role Manager 8281 may also allow a manager (i.e., with appropriate privileges) to add or remove agents from a given ticket, or move tickets from one agent to another, and may also allow agents other than managers to "invite" other agents to participate based on specific agent identifiers or agent attributes ("find me an agent who is knowledgeable about product X"). It may also allow agents to disassociate themselves from a particular ticket, and may limit this to prevent tickets from becoming "orphaned."

[0090] It will be appreciated that system 80 can support the association of agent groups rather than single agents. For example, a client may complain about performance issues with supported system 100. In such a case, the agent can invite (or command) the association of a "System Performance" agent group to ticket 5. Thus, further communications within ticket 5 may be routed to, or rather reassigned to (or involve) all members of the "System Performance" group, a particular agent in that group (e.g., assigned by a group manager or by the system based on assignment rules).

[0091] The Agent Set Handler 8282 may allow for the association of agents (or groups) at the ticket level and at the activity level separately. Thus, a ticket may be associated with multiple agents (all agents may track the ticket and include it in their inbox view), but only a subset of agents may participate in a particular activity (such as a video conference with a client). Such subsets may differ for each activity.

[0092] As described herein above, a ticket 5 may include a series of interactions between one (or more) agents and one (or more) clients regarding a single issue to be addressed, such as handling a particular problem encountered by the client. At the simplest level, a ticket 5 may include a single interaction. However, a ticket 5 may also include multiple interactions as well as other activities.

[0093] The ticket 5 may also include interactions between the communication system 80 and the client that are not mediated by an agent. For example, the system 80 may display forms and surveys, such as an initial form (or another web page or visual application page or widget) that provides the user with a pre-questionnaire (or other guidelines) to aid in problem solving or information gathering. Another interaction may be a live form within the ticket, which can be invoked by an agent to allow the client to provide information to the system 80. An example of this would be providing the necessary data at one stage without significant agent involvement ("fill out form X and we'll get back to you with the appropriate solution"). This supports issue triage, routing, and reassociation with the system 80.

[0094] A further such interaction may be a post-contact survey to collect feedback regarding the support provided (or other contacts or services), which may support the conduct of research or data collection.

[0095] It will be appreciated that such forms and surveys may be visually based or may use other techniques. They may include forms designed using the ticket input form builder 826 as well as forms designed and / or hosted by third party form providers. The ticket input form builder 826 may be used to define the fields, flows, and rules that control the rules engine 84 (e.g., validation rules, when / where to send information, and other form behavior definitions and rules). The ticket input form builder 826 may further include a visual IVR designer 8261 that provides a design environment for IVR development that allows for the definition and updating of IVR interactions for users.

[0096] It will be appreciated that the ticket subsystem 82 can also support reopening of tickets. The ticket handler 821 can either reopen an existing closed ticket or create a new ticket linked to one or more previous tickets (e.g., based on interactions with the same client).

[0097] It will be appreciated that the ticket 5 may include a communication channel associated with an interaction, which may be instantaneous (e.g., the arrival of a submitted form) or of duration (e.g., a phone call or video conference).

[0098] Ticket 5 may also contain records of internal communications. For example, a phone call with a client may be followed by an internal video conference (e.g., between a customer-facing agent and an internal engineering team). Recordings of such video conferences may be part of Ticket 5.

[0099] It will be appreciated that the ticket 5 may also include agent notes, e.g., call summaries, attached documents or other files, and ticket 5 metadata, e.g., a top level description, problem severity, priority, client importance (e.g., do we have a VIP support contract?), description, client details, start time, etc. Ticket metadata may also include custom fields, ticket specific fields, company fields (for the company operating the system), user fields, fields related to the supported system, high level topic definitions (ML (machine learning) generated or manual), BI (business intelligence), and hints (potentially selected from a tag cloud).

[0100] Other ticket 5 elements may also be external or internal links, such as links to Internet URLs, external records describing particular sub-elements of the supported system 100 related to the ticket 5, knowledge base articles, and the results of analysis of other elements of the ticket. For example, the DGRA subsystem 87 may analyze voice or video interactions to generate transcripts related to these calls.

[0101] Ticket 5 may also contain a record of events related to the ticket, the ticket label / text, and any statuses, including custom statuses.

[0102] It will be appreciated that the ticket 5 may also include information received from the supported system 100 via the ticket updater 823, which may update the relevant elements of the ticket 5 accordingly. For example, the system 80 may be used to support users of the WBS (as described above in this specification). Such WBS users may be (for example) site designers, site operators, or site users. The ticket subsystem 82 may add events to the ticket timeline that represent information extracted from the underlying WBS. Such information may include user profile details, website details, collected WBS BI data, WBS editing history and site usage history, the site's underlying business data, etc., as stored in the CMS 50 of FIG. 3, also referenced herein. These events may also include events that occur as a result of support interactions, so that agents can receive accurate information from the supported system 100 rather than relying on client descriptions of what is happening in the supported system 100.

[0103] It will be further appreciated that a ticket 5 can have multiple interactions taking place, either sequentially or in parallel, for example, one agent may be engaged in an extended video conference call with a client while another agent exchanges a series of emails (on the same ticket) with the client and / or an internal team assisting the support agent.

[0104] Ticket 5 can represent either or both of the current "primary" activities, which may be the current most interactive communication activity between agent(s) and client(s). So in the above example (multiple emails and simultaneous agent-client video chats), the ticket would be represented by the (current) video chat. Ticket 5 could also be represented by the activity of opening the ticket, or the last (or most recent) interaction with the user.

[0105] Thus, ticket 5 can be called (for example) a "video conference ticket" or a "text chat ticket" (based on this primary activity interaction type), even though ticket 5 has additional activities (interactions or not) and elements. This primary interaction type may also indicate the level of interactivity of ticket 5 (which may change over time based on different interactions).

[0106] In another embodiment, a ticket 5 may be represented by a subset of the active interactions within the ticket. For example, a complex ticket may include two ongoing video conferences (e.g., between an agent and a client and an associated internal engineering meeting) as well as a live chat (e.g., between another agent and another client employee related to the issue). Such a ticket may be represented by these three active interactions and displayed (in the ticket's listing) with three icons representing these three simultaneous interactions.

[0107] A ticket is initially associated with an open external client (or possibly multiple such clients), after which the ticket may be acquired by a given agent or assigned to an agent (e.g., by a system or manager) as described herein above.

[0108] The ticket display 827 provides an interface that shows the current status of a particular ticket and may provide a single feed for viewing. Examples of feeds may include a feed used by an agent to view tickets they are associated with, or a feed used by a manager to view tickets that are pending in the system or being handled by a particular agent or group of agents. Reference is now made to FIG. 10, which shows details of an example UI for a ticket list (inbox / feed), including active and inactive sections.

[0109] Reference is now made to FIG. 11, which illustrates elements of the inbox / feed subsystem 83. The inbox / feed subsystem 83 can create a feed of tickets 5 and its display. It will be appreciated that the inbox / feed subsystem 83 is the primary interface between the system 80 and its users. The inbox / feed subsystem 83 may further include an inbox generator 831, a feed displayer 832, and a dynamic view constructor 833. The inbox generator 831 may further include a feed constructor 8311, a feed update data 8312, a feed manager 8313, and a query receiver and executor 8314. The feed displayer 832 may further include a mini player 8321 and a preset definer 8322.

[0110] 7, 8, and 10, also referenced herein, the inbox / feed subsystem 83 can include tickets having different levels of interactivity and using different channels. Thus, the inbox / feed subsystem 83 can reflect ongoing interactive communications (e.g., an ongoing messenger chat or video conference), as well as tickets that are not currently interactive (e.g., a ticket based on an email exchange). It will be appreciated that tickets 5 can have a general level of interactivity (e.g., email is low, video conference is high) as well as a current activity level (e.g., a chat may be inactive for an extended period of time).

[0111] The feed indicator 832 can display one or more indicators for either or both levels of interactivity on a combined UI (e.g., a general inbox with current tickets as shown in FIG. 7, also referenced herein). Such indicators may include, for example, a current status indicator (e.g., active, inactive, typing, etc.). The indicators may also include an indication of the time since interaction has occurred on this ticket (e.g., a timer, a symbol, a scale, etc.).

[0112] The inbox generator 831 can generate and update multiple ticket feeds for agents, the feed constructor 8311 can build a feed according to requests, the feed updater 8312 can update a feed according to activity and agent requirements, the feed manager 8313 can manage multiple feeds, the query receiver and executor 8314 can process feeds based on queries, and the information deriver 8315 can process feeds based on information derived from ticket activity.

[0113] It will be appreciated that the feed displayer 832 can select, sort, prioritize, and group tickets according to information and metadata associated with the tickets, as described herein above, and the sorting and prioritization of tickets can be dynamically changed based on the interactivity status of each ticket.

[0114] The feed displayer 832 can dynamically generate UI elements to display tickets in the feed regardless of the type of ticket (e.g., interactive and non-interactive, and different interaction types). Tickets in the feed can be dynamically modified as the nature of the ticket changes (e.g., a ticket that started with a non-interactive submission form can become a highly interactive ticket reflecting the current video conference).

[0115] Agents can also build feeds based on association information, such as tickets associated with a particular agent or group, or tickets that are actually being handled by a particular agent. Such feeds can be used by (for example) managers with appropriate permissions to track the activity of specific agents or groups of agents (for example, based on the definition of agent groups managed by that manager).

[0116] A feed may also be based on agent activity, query-based, or association-based. It will be appreciated that the query receiver and executor 8314 can receive a query and instruct the feed constructor 8311 to create a feed accordingly. This may include, for example, allowing a manager to view a particular agent's activity (i.e., replicate the query used to form a view of a particular agent). Another example may be "view all chat sessions involving agents who answer criteria X."

[0117] The query receiver and executor 8314 may also direct the creation of a feed based on the contents of the ticket (including the communication history of the ticket), for example, displaying all tickets in which X has been mentioned (in chat, video conference, email, etc.).

[0118] The information deriver 8315 can create a feed for display based on information derived from ticket activity (e.g., a feed showing all users in geography X who mentioned product Y and conveyed a sense of urgency about product Y with ratings above Z%).

[0119] The information deriver 8315 may also create feeds based on criteria related to the supported system 100, such as "view all tickets related to supported system feature X." Such criteria may be based on internal elements of the supported system, including its internal structure or collected data. For example, if the supported system is a WBS, the criteria may reference the WBS's BI (e.g., "show all tickets related to website users with more than X users in country Y"), structure and edit history (e.g., "show all tickets related to sites with site component X added in the last month"), etc.

[0120] It will be appreciated that the feed display 832 can display a built / updated feed of tickets and can also receive ticket display instructions from the ticket display 827. It will be further appreciated that a user can use the UI of the feed display 832 to adjust settings such as preferred display.

[0121] The ticket display in the feed may represent the ongoing interaction(s) in the ticket using a miniplayer. The miniplayer 321 may reflect various types of information related to the current interaction ongoing in the ticket, such as the current status (inactive, active, typing, etc.). The miniplayer 8321 may also reflect information in the current or recent interaction (e.g., the last email message, the last chat message, a scaled-down version of a shared screen interaction between an agent and a client, etc.) and information derived from the current or recent interaction, such as recognized text based on an analysis of the voice-based interaction, or other metrics derived from the voice or video-based interaction (e.g., indicators of stress, urgency, or other relevant emotions). Such derived or analyzed information may also be used as input to the DGRA subsystem 87 and rules engine 84 modules, as described below.

[0122] It will also be appreciated that an agent can set (via view options in the feed displayer 832 UI) the desired type of display (generally and for a given ticket). A general display can use (for example) a table view, a list view, etc. A user can define multiple user-defined views (or display modes), including the use of queries, which are described in more detail below. In this scenario, the feed constructor 8311 can receive the desired display and construct it accordingly.

[0123] Agents can also build feeds based on association information, such as tickets associated with a particular agent or group, or tickets that are actually being handled by a particular agent. Such feeds can be used by (for example) managers with appropriate permissions to track the activity of specific agents or groups of agents (for example, based on the definition of agent groups managed by that manager).

[0124] As described above in this specification, a ticket 5 may have multiple (and simultaneous) interactions or activities and therefore may simultaneously display multiple mini-players reflecting the status of some or all of the ticket's underlying interactions (or other related activities).

[0125] It will be appreciated that an agent can construct multiple such feeds (or inboxes) based on multiple criteria and combinations thereof, such as ticket type, communication channel type, level of interactivity (including current interactivity), priority, or other ticket or activity parameters and attributes. The feed constructor 8311 can also function automatically (in push mode) rather than at the direction of an agent.

[0126] As described herein above, the inbox generator 831 can build a feed based on queries that select and order tickets. Such queries may relate to activity within a ticket, where there may be multiple such activities (historically or simultaneously) within a ticket. For example, an agent may request a feed that shows all active chat calls, and some tickets may contain multiple active chat calls. The feed displayer 832 can use, for example, a regular display (displaying each ticket as an entry in the feed), a split feed (displaying multiple entries for each ticket that contains multiple chats), or a hierarchical feed (allowing some "ticket with chat" entries to be opened to show multiple active chats).

[0127] The preset definer 8322 can divide the feed into multiple sections, such as an active section and an inactive section. The preset definer 8322 can also allow an agent to define multiple presets, which can include the definition of an inbox feed, including its selection and sorting criteria.

[0128] The dynamic view constructor 833 can build a view that shows a list of agents rather than a list of tickets, as shown in FIG. 12, referenced herein. An example would be to show all agents working with a given client, client group (e.g., by profile attributes), product, etc. As described above in this specification, the inbox / feed subsystem 83 can use information derived from activity, including dynamically extracted information. The list of agents derived from activity information can also be used by the system 80 (and by an agent manager using it) to monitor agents, understand their workload, and adjust where agents are assigned based on this information.

[0129] As discussed above, the communication system 80 may include a repository 85. The repository 85 may also store content known as a knowledge base. Knowledge base content may typically include interrelated articles. However, knowledge base content may also include elements such as other media types (such as training, support, or how-to videos), applications and software elements (such as interactive training applications), and elements related to the supported system 100. For example, if the supported system 100 is a WBS, the knowledge base content may include links to templates or component libraries for use with the underlying WBS. These may be provided to users to assist with site design efforts.

[0130] Knowledge base content may also include content snippets, reusable elements of knowledge base articles, and articles that contain repeating elements. The system 80 may support the use of inheritance between such elements and articles, enabling the construction of articles and article sections (possibly with local modifications) that reuse previously defined material.

[0131] Other knowledge base content may include add-on software, plug-ins, data or configuration information (files or otherwise) that is installed on a client machine or system, or on a server machine associated with the client. This may include, for example, add-on code or data / configurations / settings for use with the underlying supported system 100.

[0132] The KB creator and editor 86 may support the creation and editing of all knowledge base content used by elements of the system 80. Reference is now made to FIG. 13, which illustrates elements of the KB creator and editor 86. The KB creator and editor 86 may include a KB editor 861, a KB collection creator 862, a KB widget creator 863, and a KB processing engine 864. The KB processing engine 864 may further include an article translator 8641, a media converter 8642, a content handler 8643, and a KB article generator 8645.

[0133] The KB editor 861 can provide authoring and design tools for creating embedded training materials and courseware, as described herein above. Such materials can be targeted to both agents and clients.

[0134] It will be appreciated that such knowledge base articles or other content may be used in a variety of ways: they may be automatically provided to an incoming client (based on parameters of the initial interaction), provided to an agent for delivery to the client, provided to an agent for internal use, or installed as add-on software, configuration or data on the client's machine or system.

[0135] A KB collection creator 862 can use knowledge base articles and content to generate collections that are made available to customers on the Internet (eg, through a specific website or branded help center).

[0136] The KB widget creator 863 can generate widgets that present knowledge base articles that can be embedded in any website (based on a WBS supported system, another WBS, or a non-WBS website).

[0137] The KB processing engine 864 can automatically select, recommend, create, modify, or adapt knowledge base content according to collected information (e.g., from input forms and surveys as described herein above) and context (e.g., information about the agent(s), client(s), and problem covered by the ticket). Content modification or adaptation may also include automatic translation.

[0138] Article Translator 8641 can automatically translate any content into another language as predefined.

[0139] The media converter 8642 can provide media conversion of content, such as text to audio.

[0140] The content handler 8643 may provide a summary or selection of content. Such a summary or selection may depend, for example, on UI space allocation or dynamic decisions based on (for example) the content of the ticket and the communications contained in the ticket. Thus, if the ticket and its communications focus on problem A, and a KB article describes solutions related to A, B, and C, the content handler 8643 may summarize or remove less relevant portions of the KB article.

[0141] The content handler 8643 can also adapt the content (using the rules engine 84) to a particular client situation. For example, a knowledge base article can contain instructions for an agent (such as an engagement script for the agent to follow), and the content handler 8643 can modify the article based on known agent parameters (such as skills and language proficiency).

[0142] The content handler 8643 may also adapt the knowledge base portion of the repository 85 itself, for example by unpublishing or hiding KB articles that have not been used for a long time or that have received negative feedback from agents or clients.

[0143] The KB article generator 8645 can create knowledge base articles (eg, using the rules engine 84 and generative machine learning (ML) models described in detail above).

[0144] The DGRA subsystem 87 may include a set of data collection and analysis systems to support the system 80. Reference is now made to FIG. 14, which illustrates elements of the DGRA subsystem 87. The DGRA subsystem 87 may further include a data collector 871 and a data analyzer 872. The data analyzer 872 may further include an agent activity manager 8721, a recommender 8722, a best practice analyzer 8723, a notification generator 8724, an insight generator 8725, an auto-configurator 8726, an internal content generator 8727, a ticket prioritizer and tagger 8728, a BI (Business Information) analyzer 8729, and an automation trigger generator 8730.

[0145] It will be appreciated that elements of the DGRA subsystem 87 may affect the operation of the system 80 using an AI and ML engine 841 having AI and ML models, as described in more detail below. It will be further appreciated that the AI / ML engine 841 may train the AI / ML models using collected data collected by the data collector 871 as described above in this specification. It will also be appreciated that forms and other feedback provided by clients or agents may have higher value in training as it directly reflects client satisfaction. The DGRA subsystem 87 may further drive automated processes, as described in more detail below.

[0146] The data collector 871 may collect and record some or all information related to tickets, their interactions, and agent activity. This may include data collected from all system objects reflecting activity from session start to session end and feedback (as well as post-session activity). Such collection and analysis may be performed in real-time or offline.

[0147] Data collector 871 may also collect derived information. Such derived information may include (for example) recognized text based on analysis of voice-based interactions, or information derived from voice or video-based interactions (e.g., indicators of stress, urgency, or other relevant emotions).

[0148] The data analyzer 872 can then perform higher level analysis on the data collected by the data collector 871 to generate results and automated actions.

[0149] The agent activity manager 8721 can analyze and evaluate agent activity. The agent activity manager 8721 can do this by reviewing and understanding the activity of each agent in the system 80 based on collected parameters and known metrics regarding agent activity. This information can be used for management reporting, detection of tickets that require additional agent involvement, classification of ticket elements (such as for regulatory reporting in some industries such as the financial consulting industry and medical applications), and detection of situations where intervention is required. It will be appreciated that the agent's evaluation can be used to drive association of tickets with other agents as needed. For example, a ticket may be delegated to an agent who has difficulty handling the ticket themselves.

[0150] The agent activity manager 8721 can also analyze ticket reassignment (based on agent load, ticket-agent matching, and handling success), which may include automatic routing based on additional criteria, including user-defined criteria.

[0151] The agent activity manager 8721 may further review engagement and reward modules for agents. Such modules may increase agent involvement in the system 80 and provide an incentive system for agents. The agent activity manager 8721 may facilitate merit / points awarding for agents. The agent activity manager 8721 may further analyze system performance against SLA (Service Level Agreement) requirements.

[0152] The recommender 8722 can make ticket assignment recommendations to the agent's manager. In particular, the DGRA subsystem 87 can perform initial routing of incoming tickets based on the collected information, and also follow-up routing (e.g., if an agent needs an expert on a given subject). It will be appreciated that the system 80 can be considered to be feed-oriented (as opposed to routing-oriented). For example, an agent can monitor (multiple) feeds and can request to participate in and handle multiple tickets.

[0153] The recommender 8722 can suggest knowledge base articles for a particular situation, as well as find similar tickets (or specific interactions within tickets) based on content, issues handled, or other parameters. The recommender 8722 can provide links to these tickets, allowing agents to review the progress of the linked tickets and infer the best course of action / practice.

[0154] The recommender 8722 may also suggest specific (non-knowledge-based) answers or other content, and may suggest specific contacts, such as which agents (or others) might be able to help the agent in a given situation.

[0155] The best practices analyzer 8723 can recognize and highlight best practices of agents. For example, the best practices analyzer 8723 can continually analyze tickets related to similar issues, review the actions used to resolve these tickets, rate those actions, and create a set of "best practices."

[0156] The created sets of best practices can be used to create more nuanced action recommendations for agents, such as multiple possible courses of action for a given situation, or to create work packages for knowledge base article authors. These packages can later be used to create additional articles for KB creators and editors 86. These sets can also be used to automatically create knowledge base articles through the rules engine 84.

[0157] The notification generator 8724 can generate alerts and notifications in certain situations, such as alerts due to negative interactions occurring within a ticket or alerts related to cross-ticket issues and problems. For example, the insight generator 8725 can detect that a particular issue (such as a response time or downtime issue with the supported system 100) is related and reported through multiple channels by multiple different clients.

[0158] The insight generator 8725 can generate insights (including reports and alerts) based on pattern or trend analysis involving wide-area or long-term analysis. This may include detecting system-wide trends or recurring series of events (e.g., a particular type of complaint following a previous complaint of another type). This may also include generating user-defined reports on system metrics and analytical measurements (e.g., number of calls per agent, average time to answer, etc.).

[0159] The auto-configurator 8726 can generate system configuration changes, which can include, for example, changes to IVR scripts and configurations, or changes to load balancing parameters (based on forecasted ticket and interaction volumes).

[0160] The internal content generator 8727 can generate content for the KB article generator 8645 or to complete or complement an agent's written, audio, video, or other communication. This can be done using the AI / ML engine 841 and a generative ML model (such as GPT-3) that can complete the text using an initial response text entered by the agent. Unlike regular generative models, such models can also take into account inputs related to the client being supported and the problem being handled. The system 80 can allow the agent to edit or reject the proposed completion text.

[0161] The ticket prioritizer and tagger 8728 can provide priority and tag information for tickets. Such information can then be used to select and order information in the inbox (feed). In this way, (for example) all client calls related to a particular tagged issue (based on tags derived from analysis of the ticket content and information) can be included in the feed, even if the issue is not directly mentioned in the ticket text, audio, or video information.

[0162] The BI analyzer 8729 may also use and integrate BI events and other information from the BI subsystem of the supported system 100 (e.g., the WBS). The BI analyzer 8729 may interact with the BI system underlying the WBS to integrate WBS BI events and other information. An example would be the detection of a particular WBS event (e.g., a configuration change, database event, or other event) that may result in a set of complaints (represented by client calls or opened tickets) within X minutes later.

[0163] The automation trigger generator 8730 can trigger additional automation actions based on various scenarios. The automation trigger generator 8730 can generate triggers that (in certain scenarios) trigger an automation engine. This automation engine can operate different parts and functions of the system 80, thereby reducing the agent / operator's manual work and the performance of repetitive actions. In an alternative embodiment, the system 80 can provide an automation definition editor, allowing agents to design their own automation scripts. The system 80 can also provide a repository of automation script templates (either separately from the repository 85 or as part of the repository 85) that can be used as the basis for an agent's automation scripts.

[0164] Reference is now made to FIG. 15, which illustrates example scenarios in which the automation trigger generator 8730 can initiate an automation trigger.

[0165] The above description has focused on human agents using system 80. However, users of system 80 may include semi-automated nodes (e.g., people who communicate through system 80 who are assisted in their communications by automated means) as well as fully automated nodes (e.g., bots or other computerized elements that communicate with system 80).

[0166] Bots can also participate in the role of an agent and be assigned to handle tickets. A Bot Agent Operator 88 can handle all bot operations and can perform initial interactions with clients, for example to perform initial diagnosis that may affect the follow-up assignment of an agent(s) to the ticket. The Bot Agent Operator can further include an Interaction Assistant 881.

[0167] The bot agent operator 88 may also operate the bot to guide the client through a particular procedure that requires multiple steps. In this scenario, the agent may (for example) hand off an interaction to the bot to guide the client, monitor the bot's interaction with the client, and return to the interaction once the particular procedure is completed. It will be appreciated that sub-elements of the system 80 may treat bots similarly to human agents, and the bot agent operator 88 may coordinate with other elements of the system 80 to provide this functionality.

[0168] The bot agent operator 88 can also operate the bot to work with the client when a human agent is unavailable or overloaded (as determined by the rules engine 84). The bot can act as a real agent and interact with the client. The system 80 can keep monitoring the agent's workload and match the ticket with an appropriate human (based on load and suitability). At this point, the human agent can take over the interaction (and the ticket). The bot agent operator 88 can also escalate the ticket to a human agent if the bot determines that a certain action or decision needs to be taken that requires human interaction or approval (e.g., because they have a substantial effect).

[0169] Thus, bot-related parameters (e.g., bot or not, length of automated interaction) can be used as parameters for inbox / queue display selection in the ticket subsystem 82 and inbox / feed subsystem 83 and DGRA subsystem 87, as described above in this specification.

[0170] The system 80 may also enable agents to view and join tickets handled by the bot (including possibly "silently" viewing interactions before joining the ticket). Agents can (for example) review segments of bot interactions and join or remove interactions from the bot as needed.

[0171] The interaction assistant 881 may provide automated agent assistance that does not completely replace the agent. Such automated assistance may include enhancing, completing, or otherwise completing the assisted interaction. This assistance may also include suggesting courses of action or related materials or links, as described in the rules engine recommendation functionality above.

[0172] Thus, a communications system integrated with supported systems can provide communications using channels of different interactivity that can be processed according to interactivity. The system generates a unified view that tracks multiple types of interactions and allows sorting and selection of composite tickets by interactivity level. The system can also generate ticket views that include multiple activities and interactions and allow tracking and participation in multiple interactions with different interactivity levels.

[0173] The system can also generate inbox views from a particular perspective, for example showing what a particular agent is looking at (with or without the use of agent selection / sorting criteria).

[0174] Unless otherwise indicated, and as will be apparent from the preceding discussion, discussions throughout this specification using terms such as "processing," "computing," "calculating," "determining," and the like, are understood to refer to actions and / or processes of any type of general purpose computer, such as a client / server system, mobile computing device, smart appliance, cloud computing unit, or similar electronic computing device that manipulates and / or transforms data in the registers and / or memory of the computing system into other data in the memory, registers, or other similar information storage, transmission, or display device of the computing system.

[0175] An embodiment of the present invention may include an apparatus for performing the operations herein. The apparatus may be specially constructed for the desired purpose or may include a computing device or system, typically having at least one hardware processor and at least one memory, selectively activated or reconfigured by a computer program stored in the computer. The resulting apparatus, when instructed by software, can transform a general-purpose computer into the inventive elements described herein. The instructions can define an apparatus of the present invention that operates on a desired computer platform. Such a computer program can be stored on a computer-readable storage medium, such as, but not limited to, any type of disk, including optical disks, magneto-optical disks, read-only memory (ROM), volatile and non-volatile memory, random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, disk-on-key, or other type of medium suitable for storing electronic instructions and that can be connected to a computer system bus. The computer-readable storage medium may be implemented in cloud storage.

[0176] Some general purpose computers may include at least one communication element to enable communication with data networks and / or mobile communication networks.

[0177] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the desired methods. The desired structure for a variety of these systems will appear from the description that follows. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings of the present invention as described herein.

[0178] While certain features of the invention have been illustrated and described herein, numerous modifications, substitutions, changes, and equivalents will occur to those skilled in the art, and it is to be understood, therefore, that it is the intention to cover all such modifications and changes as fall within the true spirit of the invention.

Claims

1. 1. A communication system comprising: A processor; A unit executing on the processor, the unit for creating and processing a dynamic representation of at least one ticket, the at least one ticket representing an incoming event of a supported system supported by the communication system, the at least one ticket further representing activity related to the incoming event and a status of multiple channels of interactivity between at least one client and at least one agent associated with the supported system, the unit comprising: a ticket subsystem that receives the incoming events, the activities, and the multiple channel interactivity from at least one communication channel and creates and updates the at least one ticket accordingly; an inbox / feed subsystem that creates and displays a one-inbox feed of the at least one ticket for the at least one agent; The unit includes: The communication system comprising:

2. The communication system of claim 1 , wherein the communication system is integrated with the supported system.

3. The communication system of claim 1 , further comprising a channel transformer adapted to adapt a user interface of the communication system for communication with at least one client device belonging to the at least one agent.

4. a repository for storing at least ticket information and parameters, agent profiles, administrative data, and predefined rules; a Data Collection, Recording and Analysis (DGRA) subsystem that provides data collection and analysis of collected information for the ticket subsystem and the inbox / feed subsystem; a knowledge base (KB) creator and editor for creating and editing knowledge base content used by the ticket subsystem; a bot agent operator for integrating a bot agent with the functionality of said at least one agent; a rules engine that provides rules, artificial intelligence, and machine learning support to the ticket subsystem, the inbox / feed subsystem, the DGRA subsystem, the KB creators and editors, and the bot agent operators; The communication system of claim 1 , further comprising at least one of:

5. The ticket subsystem: a ticket handler for receiving the incoming event; a ticket creator that creates a ticket for the incoming event; a ticket updater for updating the ticket for the incoming event according to changing interactivity and activity; a remote access handler for remotely accessing said at least one client device and interacting with secondary devices connected to said device; a remote software handler for handling communications related to at least one of installing, upgrading, and changing configuration of software on the device; A ticket entry form builder to collect tickets and fill in relevant information; a ticket displayer that prepares a representation of multiple concurrent activities and interactions of the ticket for display; an association manager for managing associations between the ticket, the at least one client, and the at least one agent; The communication system of claim 4 , comprising at least one of:

6. said inbox / feed subsystem comprising: an inbox generator for generating and updating a feed of at least one ticket for the at least one agent; a feed displayer that dynamically generates user interface (UI) elements for displaying the feed; a dynamic view constructor for constructing at least one view for displaying a list of agents registered with the communication system and their associated activity information; The communication system of claim 4 , comprising:

7. The inbox generator: a feed constructor for constructing said feed; feed update data for updating the feed according to activity information and requirements of the at least one agent; A feed manager for managing multiple feeds, a query receiver and executor for directing the feed constructor according to the results of a query issued by the at least one agent; an information deriver for directing the feed constructor according to information derived from the at least one ticket; The communication system of claim 6 , comprising:

8. 2. The communication system of claim 1, wherein at least one ticket includes at least one of the following: the status of an interaction between the at least one agent and the at least one client, a start event, an end event, display forms and surveys, notes of the at least one agent, ticket metadata, links to related tickets, knowledge base content, and ticket association information.

9. 2. The communication system of claim 1, wherein the at least one communication channel is at least one of a social network, email, a shared virtual space, a web service, an organized communication system, an online forum, an online chat room, and a messaging system.

10. 1. A method comprising: and creating and processing a dynamic representation of at least one ticket, the at least one ticket representing an incoming event of a supported system supported by a communication system, the at least one ticket further representing activity related to the incoming event and a status of multiple channels of interactivity between at least one client and at least one agent associated with the supported system, the creating and processing of the dynamic representation comprising: receiving the incoming events, the activities, and the multiple channel interactivity from at least one communication channel and creating and updating the at least one ticket accordingly; creating and displaying a one-inbox feed of the at least one ticket for the at least one agent; said creating and displaying including: The method comprising:

11. The method of claim 10 , wherein the communication system is integrated with the supported system.

12. The method of claim 10, further comprising adapting a user interface of the communication system to communicate with at least one client device belonging to the at least one agent.

13. storing at least ticket information and parameters, agent profiles, administrative data, and predefined rules in a repository; providing data collection and analysis of collected information for the creation and updating of said at least one ticket and said creation and display of a one-inbox feed; creating and editing knowledge base content for use by said creating and updating said at least one ticket; Integrating a bot agent into the functionality of said at least one agent; providing rules, artificial intelligence and machine learning support for the creating and updating the at least one ticket, the creating and displaying a one-in-box feed, providing data collection and analysis, the creating and editing knowledge base content, and the integrating bot agents; The method of claim 10 , further comprising at least one of:

14. said creating and updating said at least one ticket receiving the incoming event; creating a ticket for the incoming event; updating the ticket for the incoming event according to changing interactivity and the activity; remotely accessing said at least one client device and interacting with a secondary device connected to said device; Processing communications relating to at least one of software installations, upgrades, and configuration changes to the device; Collecting said tickets and filling in relevant information; preparing a representation of the multiple concurrent activities and interactions of the ticket for display; processing an association between the ticket, the at least one client, and the at least one agent; The method of claim 13 , comprising at least one of:

15. said creating and displaying a one-in-box feed; generating and updating a feed of at least one ticket for the at least one agent; dynamically generating user interface (UI) elements for displaying the feed; constructing at least one view for displaying a list of agents registered with the communication system and their associated activity information; The method of claim 13, comprising:

16. said generating and updating a feed constructing said feed; updating said feed according to activity information and requirements of said at least one agent; Managing multiple feeds; directing said constructing of said feed according to results of queries issued by said at least one agent; directing said constructing of said feed according to information derived from said at least one ticket; 16. The method of claim 15, comprising:

17. 11. The method of claim 10, wherein at least one ticket includes at least one of the following: a status of an interaction between the at least one agent and the at least one client, a start event, an end event, display forms and surveys, notes of the at least one agent, ticket metadata, links to related tickets, knowledge base content, and ticket association information.

18. 11. The method of claim 10, wherein the at least one communication channel is at least one of a social network, email, a shared virtual space, a web service, an organized communication system, an online forum, an online chat room, and a messaging system.

Images