CN105637812A - Systems and methods for automated chat detection - Google Patents

Abstract

A system for flexible and scalable automated chat-based contact center detection and method of using such a system for automated detection of a chat-based interaction environment of a contact center and reporting of detection results, the system comprising: detecting a case management platform; "chat processing system"; a contact center manager; a chat classifier; and a desktop automation engine.

Description

Systems and methods for automated chat detection

Cross References to Related Applications

This application is and claims priority from PCT Application Serial No. 14/141,424, filed December 27, 2014, entitled "System and Method for Automated Chat Detection," which application (14/141,424 ) is a continuation of U.S. Patent Application Serial No. 13/936,186, filed July 6, 2013, entitled "System and Method for Automated Chat Detection," which application (13/936,186) was filed on December 2013 A continuation-in-part of U.S. Patent Application Serial No. 14/140,449, filed July 24, 2013, entitled "System and Method for Automated Chat Detection" Continuation of 13/936,147 for "System and Method for Automated Chat Detection," and serial number of U.S. Patent Application entitled "Integrated Detection Platform for Contact Centers," filed December 22, 2009 12/644,343, and is a continuation-in-part of U.S. Patent Application Serial, entitled "Modified and Improved Systems and Methods for Automated Speaker Authentication in the Context of Voice Biometric Recognition Systems," filed August 6, 2012 13/567,089 continuation-in-part, the specification of each application is hereby incorporated by reference in its entirety. This application also claims priority to U.S. Patent Application Serial No. 14/140,470, filed December 25, 2013, entitled "System and Method for Automated Speech Quality Detection," which application (14/140,470) was filed on Continuation of 13/936,183, filed July 6, 2013, entitled "Systems and Methods for Automated Speech Quality Detection," which was filed on December 22, 2009, and entitled Continuation-in-Part of U.S. Patent Serial No. 12/644,343 for "Integrated Detection Platform for Contact Centers," and filed on August 6, 2012, entitled "Speaker Authentication for the Context of a Voice Biometric System Modified and Improved Systems and Methods for Automation," a continuation-in-part of US Patent Application Serial No. 13/567,089, the entire specification of each application is hereby incorporated by reference in its entirety.

Background technique

technical field

The present invention relates to the field of contact center operations, and more particularly, to the field of automated detection of chat-based client interaction software systems.

current technology

In the field of contact center operations, communication between agents and customers has traditionally been conducted through voice-based systems, such as traditional telephones or Voice over Internet Protocol (VoIP) systems. However, more centers are beginning to offer additional text-based communications, such as Internet-based chat software common in the prior art, to better serve customers who may not be able or wish to utilize voice connections. A common example of this is a customer browsing through a company website's online directory. In this case, the customer may have questions about the product, and both the customer and the company would benefit from including a convenient chat interface within the web page, allowing the customer to chat with the agent while browsing the online catalog from the convenience of their computer. direct communication. This allows for more convenient and high-speed communication without the need to use a phone-based Interactive Voice Recognition (IVR) system to contact an agent or wait in long lines waiting for an agent to become available. This also allows for more flexible communications, for example, customers who may be browsing an online catalog at an Internet cafe or similar public place where they may not have access to a phone or may not want others to hear their conversations.

From this change in contact center approach, it will become apparent that chat-based systems need to be tested and evaluated to ensure reliable contact center operation and to resolve issues that may affect customer interactions, such as frozen chat sessions or text transmission delays. It should be understood that such a detection system should also accommodate various endpoints, such as a chat interface embedded in a web page, a dedicated chat software or a mobile chat application running on a personal computer, without affecting the reliability of the detection results and requiring no human interaction or modify.

Detection methods for voice communications exist in the prior art, but it should be understood that these methods do not translate well to text-based systems. Furthermore, although there are chat detection systems implemented in the current state of the art, these systems require detection agents to interact in order to function, which introduces new issues such as additional costs of time and manpower involved in detection, which may affect the reliability of the detection protocol. factors of human error and various inconsistencies associated with human operations.

There is a need for a flexible and scalable automated detection scheme for chat-based communications that can run in parallel to a production environment without affecting ongoing customer interactions and without adversely affecting detection reliability. Cases accommodate a variety of endpoint and infrastructure implementations.

Contents of the invention

Accordingly, the inventors have conceived and put into practice in a preferred embodiment of the present invention a method for automated chat detection and a preferred system for implementing such a method, said method not being dependent on a specific chat software or endpoints, and is extensible to accommodate various implementation architectures.

In accordance with a preferred embodiment of the present invention, a system for handling chat detection for contact center automation is disclosed, comprising a detection case management (TCM) platform, a "chatcruncher", a contact center manager (CCM), Chat Classifier and Desktop Automation Engine (DAE). According to an embodiment, the TCM platform may present a web-based graphical user interface for building and managing test cases and viewing result reports, as illustrated in detail in FIGS. 6 and 7 . These functions may allow the user to enter additional detection protocols, view the results of previous detections, view detections as they are run for real-time analysis, and run detection result reports (such as, for example, for backup purposes, select specific reports and export them to database or other storage media). A "chat processing system" according to an embodiment may handle the loading and execution of test cases, including (but not limited to) functions such as generating simulated customer traffic and testing various chat endpoints for customer experience (such as, for example, in web pages) embedded chat interface) and handles the automation of load detection by changing the traffic generated. A CCM system can simulate agent activity and perform contact center functions with respect to simulated customer traffic from a chat processing system and can replicate actual agent activity by directly running a chat server utilized by a contact center, thereby also including support for existing centers Detection of architecture, for example, chat server, CTI server or other internal components. It should be understood that these embodiments are not dependent on any particular existing components or configurations, thus facilitating scalability to a variety of contact center infrastructures. According to an embodiment, a chat classifier may be implemented to classify chat interactions into simulated interactions performed by the detection system or actual client-agent interactions according to their nature. In this way, chat classifiers can be used to harden the boundary between the detection environment and the production environment within a contact center, allowing detection to run concurrently without affecting center performance and customer experience. According to embodiments, a DAE system can be used to directly run the agent desktop environment, rather than directly interacting with the chat server, thereby adding the ability to monitor the agent's experience. Thus, a single exemplary detection case can be performed on internal contact center systems (such as CTI servers or chat servers as described above), agent desktop software, inbound traffic management and loading processing, and customer experience through various chat interaction endpoints and the detection of the overall routing efficiency of all executed requests, and then store the detection case result data for viewing and analysis. It will be appreciated by those skilled in the art that the preferred configurations described are exemplary and that alternative configurations are possible according to the invention and that suitable detection protocols may be implemented within the scope of the invention as the art continues to evolve new capabilities.

According to another preferred embodiment of the present invention, a method for automated chat detection is disclosed. According to an embodiment, in an initial step the detection of cases is started. This can be performed as an automated task, for example, as part of a scheduled event or a routine that runs periodically or when certain conditions are met. This can also optionally be triggered by human interaction through the TCM platform to build and execute customizations that may be required to detect specific features or processes or to perform a "trial run" of a new detection case before it is set up to run automatically Detection case. When performing detection cases, multiple virtual clients and agents are established, which are used as endpoints for chat detection. This method implicitly detects every system involved in detecting runtime chat. Results created by virtual customers and agents may be stored in an inspection database or similar data store, which may be located locally as part of the contact center infrastructure or may be on any of a variety of remote storage media, For example, cloud storage located remotely from the contact center and accessed through the Internet or other data network. The stored data can then be used to generate a detailed report for viewing inspection results, which can then also be stored for subsequent retrieval. Next, depending on the specific detection case being performed, one or more virtual clients initiate a chat session. Such session initiation requests may be sent over the Internet or other data network and processed similarly to actual inbound requests from clients. To enforce boundaries within a contact center and prevent detection cases from impacting operations, a chat classifier can be implemented to analyze chat requests traversing the center and "flag" them as relevant to a detection case as appropriate. In this way, the sensed data can follow a similar path to the actual customer interaction without interfering with contact center operations (eg, sending a virtual customer's request to a real agent or displaying the sensed data to the customer). Those skilled in the art will appreciate that this step may be optional, as it is not always necessary to run detection in parallel with normal central operations—for example, when an automated system notifying customers of uptime is processing inbound traffic and no traffic is passing through When using a hub, it is possible to run tests outside of the hub's runtime. Again, the resulting data from this step can be recorded in a data store for use in reporting. After the session has been initiated and optionally triaged, a virtual agent response and appropriate chat session can begin based on the detection cases being run (the methods described herein do not employ specific scripts, it being understood that these detection cases may vary greatly different). The customer and agent exchange chat messages based on the detection, the results are recorded accordingly, and optionally the CCM platform can interact with the agent's desktop in order to monitor the agent experience and monitor the operation of the contact center software. This proxy desktop can be a physical computer workstation running the proxy desktop environment software, or it can be a virtual desktop running within the detection system where no physical computer exists. The results from the agent's desktop interaction (if any) are recorded, and eventually all recorded data is collated into the results report upon completion of the detection case. The resulting reports can be stored for later retrieval and made visible from the TCM platform for user analysis. In this way, the results from the previous inspection are available so that the user can optimize any future inspections from the graphical interface of the TCM platform.

According to another preferred embodiment of the present invention, a system for automatically detecting and scoring audio connection quality is disclosed, and the system includes a plurality of endpoint simulators and a call engine. Depending on the embodiment, system elements can be implemented with existing contact center architecture such as, for example, a web server that can run a web interface or browser for call simulation setup, a gateway to direct calls or other data within the contact center ( For example, a router or a SIP server) or a data network (for example, the Internet or other network). According to an embodiment, a web server can be connected to the call engine to create a call simulation that can utilize existing audio samples (hereinafter referred to as "reference audio") for detection purposes - this process can be run manually or automatically. The call engine can then simulate a customer generating an inbound call request to the contact center, sending audio or other data over the public switched telephone network (PSTN) or the Internet or other data network that may be suitable for simulating a Voice over Internet Protocol (VoIP) call interaction. In a contact center, an endpoint manager can similarly be connected to a web server for building a call simulation with reference audio to simulate the agent's participation in a customer interaction. Endpoint simulators can similarly be connected to existing components of the contact center architecture, including (but not limited to) elements that, for example, can direct calls to their appropriate destinations (e.g., enhance boundaries so that simulated interactions do not differ from actual overlapping contact center activities that would otherwise have a potentially adverse impact on contact center performance or customer experience), databases or other storage media that may store audio detection results or other data from simulations, or call classifiers that classify calls An analyzer can examine audio or other traffic traversing the contact center and determine whether that data is of a real or simulated nature, again facilitating hardening boundaries so that simulation does not overlap with contact center operations. Those of ordinary skill in the art should understand that such a system has design flexibility and can be adapted to any of various existing contact center architectures according to the present invention, because such a system does not rely on contact information other than the claimed one. Specific contact center components other than the central component.

In another preferred embodiment of the present invention, a method for automatic detection or scoring of audio quality is disclosed. According to an embodiment, a call simulation can be set up within an endpoint emulator through a web interface with reference audio for simulating a contact center agent receiving an interaction from a customer. A similar call simulation with reference audio can be built within the call engine through a web interface for simulating a caller using the contact center to initiate a call to interact with an agent. It should be understood that, in accordance with the present invention, such a call simulation setup process may be a manual or automatic process or some combination of both (eg, manually setup a call simulation and then set it to run at scheduled intervals). Reference audio for caller simulation can then be sent from the call engine to the contact center environment over an existing channel (eg, PSTN or data network, such as the Internet in the case of VoIP call simulation). Within a contact center, routers or gateways can be implemented to properly distribute incoming calls and ensure that simulated calls from call engines are sent to the appropriate endpoints, i.e. not to actual contact center agents who may be waiting to receive calls from actual customers . When the endpoint emulator receives incoming audio routed from the call engine, the endpoint emulator can then measure the quality of the incoming audio and generate a score or rating accordingly, simulating the audio quality that a contact center agent receiving the call could perceive. This score can be stored in a database or other storage medium within the contact center for review and further action. The endpoint emulator can then respond with reference audio, optionally sent back to the call engine via an existing channel (eg, router or PSTN or Internet or other network) as described above. When the audio reaches the call engine, the quality can be similarly measured and scored, properly simulating the audio quality a customer can perceive during an interaction with a contact center agent. The call simulation can optionally continue in a manner such that reference audio samples are further sent between the call engine and the endpoint emulator and measured or scored for corresponding quality, until the call simulation is ended intentionally or due to an error or malfunction such as a dropped call ) (which can then be further recorded in a database or other storage medium for detection and analysis purposes) to end the call simulation.

According to further embodiments of the present invention, a system for automated audio quality detection is disclosed, the system further comprising a plurality of audio generating devices. According to an embodiment, multiple audio generating devices may be implemented within a contact center as elements of an automated audio detection system, which may then be connected to an agent device, such as a handset or headset. During the previously described audio detection simulation, when a reference audio is to be sent from the endpoint emulator in response to the audio received from the call engine, the reference audio can be played by the audio generation device into the agent's device so that in addition to detecting the contact center architecture In addition to the audio quality on the monitor, it also facilitates the detection of agent hardware (for example, it may facilitate determining any loss of audio quality due to low quality or defective agent headphones). It should be understood that the nature of this configuration may be variable, and if multiple audio generating devices are implemented, they may be connected to various agent hardware, e.g., handsets, headphones, or other devices in any combination . In this way, such a system can be easily adapted to a variety of existing contact center architectures as well as agent hardware technology, and the system can be easily adapted to this architecture, or the technology can change (for example, when the contact center integrates the agent's when the headset is upgraded to a different model). It should be further understood that the implementation of the audio generating device does not require the use of actual agent workstations, and that, according to embodiments, the agent hardware and audio generating device may be connected to the contact center architecture in any configuration, for example, the contact center may utilize various Such agent hardware or similar computing hardware suitable for simulating agent workstations can dedicate a specific room to agent hardware testing so that the environment of actual agent workstations can be unaffected by the testing. In this way, detection equipment can be operated without interfering with contact center operations and without reducing the number of physical agent workstations available for use.

According to further embodiments of the present invention, a system for automated audio quality detection is disclosed, the system further comprising a plurality of head and torso simulator (HATS) devices. According to an embodiment, a HATS device may be a replica or "dummy" torso designed to simulate the physical makeup and/or acoustic properties of the human body. Such a device may be used in conjunction with the system for automated audio quality detection as previously described, and may include integration with a HATS device as previously described in order to generate and/or receive audio in a manner very similar to an actual agent Or an audio generating device detachably secured to a HATS device. In this configuration, when the endpoint emulator receives the reference audio, the reference audio can be transmitted through the agent hardware (e.g., a headset) and can then be provided by the HATS device either integrally or detachably attached to the HATS device. Received by the audio sensor on the headset, this headset can be placed on the HATS device. The audio quality can then be scored in the manner previously described, and new reference audio can then be transmitted through an audio generation device integral to or detachably attached to the HATS device to simulate the agent vocalizing, and the agent hardware The agent utterance may be received (eg, a handset or headset) for transmission back to the call engine as previously described. In this way, audio testing can now include testing of agent hardware based on actual usage by human agents, thereby facilitating more thorough and accurate testing of agent hardware and customer experience and more closely simulating actual contact center operations. It should be understood that this configuration does not require the use of physical agent workstations, and that the HATS device can be used with other elements in any configuration to allow for a flexible configuration that can be easily adapted to any contact center architecture, and to suit the conditions that may occur with such an architecture. Variety. In this way, detection with HATS devices can be performed without impacting contact center operations or reducing the number of physical agent workstations available.

According to another embodiment of the present invention, chat-based software front ends can be instrumented for stress detection, functionality, reliability, response time, or other useful instrumentation metrics such that specific front end applications can be instrumented prior to implementation in actual contact center operations. According to an embodiment, the detection method may allow the use of various third-party or external front-end software, so that a single detection system can be utilized with any front-end software as desired. In this way, new or alternative front ends can be tested for feasibility in real or simulated conditions to verify their functionality prior to deployment. Depending on the embodiment, features inherent to Internet-based or similar Internet Protocol (IP) networks may be exploited to facilitate system operation, for example, using HTTP headers (a key characteristic of data packets sent over such communications networks) to identify Chat behavior or parameters, or the use of well-crafted URLs to identify the chat server used in the detection (i.e., the chat frontend could request a specific URL in order to interact with the detection server, rather than connecting to a phone number). By utilizing headers in this way, decisions can be made to handle interactions based on information received in headers (such as how to route chat requests), without adding special space in the front end itself. This functionality can be exploited to enable detection for various networks by exploiting fundamental technical features inherent to all IP-based communications, without requiring utilization of a specific detection network for proper functionality. In this way, detection can utilize external connections, such as remotely located contact center agents or software elements acting as agents or customers, and can utilize the same network (i.e., the Internet) through which customers can communicate with the contact center interaction (as opposed to detection on the internal network within the contact center). It should be appreciated that by using this approach, detection can utilize the same technical elements as actual customers, thereby closely replicating the actual operating conditions of contact center chat interactions.

As an extension of the ease of operation using existing communication technologies, the detection system can operate across external connections (eg, interacting with remote chat front-ends via the Internet or similar data communication networks). This way, the detection system can leverage actual network connections, physical hardware, or locations that actual customers might utilize, increasing the relevance of detection results. Furthermore, this capability allows the use of distributed contact center agents running through the cloud or remote head-ends, as is common in the art for cloud or distributed contact center operations, and can communicate with Central detection system interaction. In this way, remote agents can utilize their existing hardware or similar chat front ends while utilizing the full functionality of the end-to-end inspection system. Additionally, distributed agents can participate in automated detection, e.g. scheduled chat detection interactions, for example, can be used for load detection to ensure specific connections, or front-ends robust enough to handle actual operational interaction traffic levels. Additional uses could be periodic or random testing of agents and their front ends, which could be initiated by a testing system simulating customer interactions, for example to perform periodic testing and ensure consistent operation of contact centers, as well as Or to ensure continuous operation (as appropriate) when changes occur within the detection system (e.g. batch detection can be initiated to ensure operation when a configuration is changed).

Additionally, depending on the embodiment, the chat interaction may utilize a variety of communication technologies (e.g., a physical connection, a cable or fiber-based Internet connection, a cellular communication network, or other communication technology) at any point along the connection or at any point during the interaction. . These techniques can be utilized simultaneously or sequentially or according to a random or configurable pattern. In this way, any communication technology that can be utilized during the interaction can be detected, thereby ensuring that detection can fully encompass any feasible scenario of the client-agent interaction.

In addition to running test cases on actual technologies or networks as described above, these test cases should detect and measure key metrics or test functions to accurately represent actual client-agent interactions. For example, a detection case may measure the time to connect to a chat server or a second chat participant (e.g., a contact center agent), the time spent waiting for an agent to "pick up" and join the interaction (i.e., the "hold time" metric, since It involves chat-based interactions), time waiting to receive a text or waiting to send a response (e.g., for simulating a customer entering a question, or an agent looking up information to formulate a response), selecting a response string to return to the customer (or simulating client) or other features that can be detected without relying on any particular front end. Furthermore, since customers or other participants may use different front-end applications with different processes or functions, the underlying software elements inherent in the inspection system should be able to process requests from the front-end and process outputs to be sent to the front-end in a compatible manner, regardless of the particular software application being used. In this way, the detection scheme can be extended to a large variety of front-end chat programs without weakening the functionality.

In addition, the detection system may utilize the "activity" function, for example, to select or configure the detection process for execution, e.g., select what script to run, what string to send, the values of these variables as latency and possibly desired storage for future reference or Other configurations used. Additionally, when a detection campaign is run, results may be reported or logged regarding a particular campaign so that when the detection results are reviewed, the configuration of the campaign may be available along with previous execution results of that campaign. In this way, it is possible to configure both the scheduling or periodicity of detection ("when" the detection runs), as well as the configuration parameters that control specific detection runs, such as variable wait times, networks to be detected, agents to send detection interactions to who, detection error or other operating parameters bounds, or how detection results are reported (the detection "how" to run). In this way, various detections and detection types can be configured and the configuration changed or maintained by editing stored campaigns rather than manually configuring individual detections. Additionally, activities can be chained to provide a layered detection approach - for example, if "Detection Activity A" returns results within certain boundaries, then "Detection Activity B" is run, but if "A" returns results outside of those boundaries , then run "Detect Activity C". In this way, a fully autonomous detection regime can be configured to be applicable to its own operations and only require human intervention to change the active configuration when routine operations are configured to proceed unsupervised. It should be appreciated that this approach can also make interactive reporting (e.g. activities compiling and sending results to appropriate parties (e.g. alerting IT staff if a hardware failure is detected)) pending and that these reports can Link to campaigns or even perform specific detections to increase the relevance and usability of reported content. It should be further understood that by combining these reporting activities with the previously described detection methods (e.g., utilizing HTTP headers or other embedded data in communications), reports can show not only system operation, but also a "client's eye" view of interactions – that is, what the customer sees or experiences during the interaction, for example, slow response times form agents. This way, inspections can be even more relevant and can find issues that may not have arisen in traditional inspection runs - continuing the above example, customers may have experienced slowness when the inspection system exhibited quick responses from real or simulated agents during interactions response time. This can be used to find, for example, connectivity or hardware issues during the communication path between the client and the agent, facilitating more accurate system diagnostics and overall efficiency of operation.

Description of drawings

The drawings illustrate several embodiments of the invention and together with the description explain principles of the invention according to the embodiments. Those skilled in the art will appreciate that the specific embodiments illustrated in the figures are exemplary only and are not intended to limit the scope of the invention.

Figure 1 is a block diagram illustrating an exemplary hardware architecture of a computing device used in embodiments of the present invention.

Figure 2 is a block diagram illustrating an exemplary logical architecture for a client device according to an embodiment of the present invention.

Fig. 3 is a block diagram illustrating an exemplary architectural arrangement of a client, a server and an external service according to an embodiment of the present invention.

4 is a block diagram illustrating an exemplary system architecture for automated chat detection integrated with traditional contact center components according to a preferred embodiment of the present invention.

FIG. 5 is a block diagram of a method for automated chat detection according to a preferred embodiment of the present invention.

Fig. 6 is an illustration of a detection case creation interface according to a preferred embodiment of the present invention.

Fig. 7 is an illustration of a test result summary interface according to a preferred embodiment of the present invention.

FIG. 8 is a block diagram illustrating an exemplary system for automated speech quality detection according to a preferred embodiment of the present invention.

Fig. 9 is a block diagram of a method for automated speech quality detection according to a preferred embodiment of the present invention.

FIG. 10 is a block diagram illustrating a system for automated speech quality detection including a speech generating device according to an embodiment of the present invention.

Figure 11 is an illustration of a HATS device and its use according to an embodiment of the present invention.

FIG. 12 is a block diagram illustrating an exemplary method for scalable peer-to-peer chat detection according to an embodiment of the present invention.

FIG. 13 is a block diagram illustrating an exemplary method for activity-based detection according to an embodiment of the present invention.

detailed description

The inventors have conceived and put into practice an automated system and method for chat-based contact center interaction detection, including a flexible and scalable architecture and method to facilitate reliable automated detection and improve contact center operations.

One or more different inventions may be described in this application. Additionally, numerous alternative embodiments may be described for one or more of the inventions described herein; it should be understood that these embodiments are presented for illustration purposes only. The examples are by no means intended to be limiting. One or more inventions may apply broadly to numerous embodiments, as is apparent from this disclosure. Generally, these embodiments are described in sufficient detail to enable those skilled in the art to practice the invention or inventions, and it is to be understood that other embodiments may be utilized and that other embodiments may be made without departing from the scope of the specific inventions. Structural, logical, software, electronic and other modifications. Accordingly, those skilled in the art will recognize that one or more inventions may be practiced with various modifications and alterations. Specific features of one or more inventions may be described with reference to one or more specific embodiments or the accompanying drawings, which form a part of this disclosure, and the drawings show by way of illustration one or more specific embodiments of the invention. It should be understood, however, that the features are not limited to the one or more particular embodiments or figures with reference to which the description is made. This disclosure is neither a literal description of all embodiments of one or more inventions nor is it an enumeration of features of one or more inventions that must be present in all embodiments.

The section headings and titles of this patent application are provided in this patent application for convenience only and should not be construed as limiting the disclosure in any way.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly indicated otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries (logical or physical).

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, various optional components may be described to illustrate a wide variety of possible embodiments of one or more inventions and to more fully describe one or more aspects of the invention. Similarly, although process steps, method steps, algorithms, etc. may be described in a sequential order, these processes, methods and algorithms can generally be configured to operate in an alternative order unless specifically stated to the contrary. In other words, any sequence or order of steps described in this patent application does not in itself imply a requirement that the steps be performed in that order. The steps of the described processes may be performed in any order practical. Additionally, although some steps are described or implied as occurring non-concurrently (for example, because one step is described after another), these steps may also be performed concurrently. Furthermore, the depiction of a process by the drawing does not imply that the illustrated process does not include other changes and modifications, does not imply that the illustrated process or any step thereof is essential to one or more inventions, and does not It is implied that the illustrated process is preferred. Additionally, each embodiment generally describes these steps once, but this does not mean that they must occur once, or that they can only occur once each time a process, method, or algorithm is executed or run. Some steps may be omitted in some embodiments or in some situations, or some steps may be performed more than once in a given embodiment or situation.

Where a single device or item is described, it should be readily understood that more than one device or item may be used in place of a single device or item. Similarly, where more than one device or item is described, it should be readily understood that a single device or item may be used instead of more than one device or item.

Functions or features of a device may instead be performed by one or more other devices not expressly described as having such functions or features. Accordingly, other embodiments of one or more inventions need not include the device itself.

For purposes of clarity, techniques and mechanisms described or referenced herein will sometimes be described in the singular. It should be noted, however, that specific embodiments include multiple repetitions of techniques or multiple instances of mechanisms unless otherwise noted. Process descriptions or blocks in the figures should be understood as representing modules, segments or partial codes including one or more executable instructions for implementing specific logical functions or steps in the process. Those of ordinary skill in the art will appreciate that alternative implementations are also within the scope of the embodiments of the present invention, in which, for example, functions may be performed out of the order shown or discussed, including substantially simultaneously or in reverse, depending on the functions involved. order of.

definition

A "chat processing system" as used herein is a software or hardware based system designed to receive input of test case information and generate chat based output for carrying out the test case. Thus, a chat processing system can be used to simulate chat-based interactions by generating predetermined chat messages to initiate an interaction, or responding to input received during an interaction, by replicating a chat-based communication system with another individual user interaction effect.

A "chat classifier" as used herein is a software or hardware-based system designed to receive a stream of chat-based interaction data and analyze it to determine whether it is part of a detection case or part of an actual customer interaction. The chat classifier can then determine how to route chat data, such as sending interactive chat data to contact center agents for processing, while sending detection case data to other detection systems. This way, chat classifiers can take care of boundary enforcement, preventing any detection data from overlapping or interfering with actual contact center operations.

A "Desktop Automation Engine", abbreviated DAE, as used herein, is a software-based system designed to simulate the interaction of a contact center agent with elements of an agent's desktop software for the purpose of detecting those elements, the agent Desktop software elements function as they would in an agent's desktop environment during contact center operations. In this way, the desktop automation engine can be deployed on existing agent desktops to interact with standard elements of the desktop environment, without requiring dedicated or dedicated desktops to be specially configured for detection purposes.

As used herein, "reference audio" refers to pre-recorded audio samples that represent elements of a customer and contact center agent interaction (eg, greeting, question, or response). The reference audio can be of various properties, such as bitrate, length or other audio qualities with respect to audio quality, and it should be understood that using audio samples with different qualities may be beneficial for detection, as actual interactions do not necessarily fall into "ideal" operating conditions Inside.

As used herein, "Head and Torso Simulator", the acronym HATS, refers to a mechanical replica of a human torso designed to serve as a stand-in for an actual human operator during testing for Examples include detecting the audio quality of hardware that includes an agent (eg, a phone headset or headset), or detecting the purpose of audio transmissions through a microphone. Thus, according to the method of the present invention, each point of the customer-agent interaction process can be monitored and recorded, thereby removing undetected variables that may be detrimental to the operation of the contact center.

hardware architecture

In general, the techniques disclosed herein can be implemented on hardware or a combination of software and hardware. For example, they may be in the runtime kernel, in a separate user process, in a library package bundled into a network application, on a specially constructed machine, on an application-specific integrated circuit (ASIC), or on a network interface card implement.

Hybrid software/hardware implementations of at least some of the embodiments disclosed herein may be implemented on programmable network-resident machines (should be understood to include intermittently connected network-aware machines) powered by a computer stored in memory Programs are selectively activated or reconfigured. These network devices may have multiple network interfaces that can be configured or designed to utilize different types of network communication protocols. A general architecture for some of these machines may be disclosed herein in order to illustrate one or more exemplary means by which a given functional unit can be implemented. Depending on the particular implementation, at least some of the features or functionality of the various embodiments disclosed herein can be implemented on one or more general-purpose computers in connection with one or more networks, e.g., end-user computer systems, client computers, network Servers or other server systems, mobile computing devices (e.g., tablet computing devices, mobile phones, smartphones, laptops, etc.), consumer electronics devices, music players or any other suitable electronic devices, routers, switches, etc., or combinations thereof . In at least some embodiments, at least some of the features or functions of the various embodiments disclosed herein can be implemented in one or more virtualized computing environments (e.g., networked computing clouds, virtual machines hosted on one or more physical computers) etc.) are implemented.

Referring now to FIG. 1 , there is shown a block diagram depicting an example computing device 100 suitable for implementing at least some of the features or functions disclosed herein. Computing device 100 may be, for example, any of the computing machines listed in the preceding paragraph, or indeed any other electronic device capable of executing software- or hardware-based instructions according to one or more programs stored in memory. Computing device 100 may be adapted to communicate with multiple other computing devices (e.g., client terminal or server) to communicate (whether wireless or wired).

In one embodiment, computing device 100 includes one or more central processing units (CPUs) 102, one or more interfaces 110, and one or more buses 106 (eg, Peripheral Component Interconnect (PCI) buses). When run under the control of appropriate software or firmware, CPU 102 may be responsible for implementing specific functions related to the functions of a specially configured computing device or machine. For example, in at least one embodiment, computing device 100 may be configured or designed to function as a server system utilizing CPU 102 , local memory 101 and/or remote memory 120 and interface 110 . In at least one embodiment, CPU 102 can be caused to perform one or more different types of functions and/or operations under the control of software modules or components, which can include, for example, a runtime system and any suitable application software , drive, etc.

CPU 102 may include one or more processors 103, such as, for example, a processor from one of the Intel, ARM, Qualcomm and AMD microprocessor families. In some embodiments, processor 103 may include specially designed hardware for controlling the operation of computing device 100, such as an application specific integrated circuit (ASIC), electrically erasable programmable read-only memory (EEPROM), field programmable Gate Array (FPGA), etc. In particular embodiments, local memory 101 , such as non-volatile Random Access Memory (RAM) and/or Read Only Memory (ROM), including, for example, one or more registered cache memories, may also form part of CPU 102 . However, memory can also be coupled to system 100 in many different ways. Memory 101 may be used for various purposes such as, for example, caching and/or storing data, programming instructions, and the like.

As used herein, the term "processor" is not limited to those integrated circuits known in the art as processors, mobile processors or microprocessors, but broadly refers to microcontrollers, microcomputers, programmable logic control devices, ASICs, and any other programmable circuits.

In one embodiment, interface 110 is configured as a network interface card (NIC). In general, the NIC controls the sending and receiving of data packets over the computer network; other types of interface 110 may, for example, support other peripheral devices for use with computing device 100 . The interfaces that can be provided are Ethernet interface, frame relay interface, cable interface, DSL interface, token ring interface, graphic interface and so on. Furthermore, various types of interfaces may be provided such as, for example, Universal Serial Bus (USB), Serial, Ethernet, FIREWIRE ^™ , PCI, Parallel, Radio Frequency (RF), Bluetooth (BLUETOOTH) ^™ , Near Field Communication (e.g. , using near-field magnetic), 802.11 (WiFi), Frame Relay, TCP/IP, ISDN, Fast Ethernet interface, Gigabit Ethernet interface, Asynchronous Transfer Mode (ATM) interface, High Speed Serial Interface (HSSI) interface, Point of Sale (POS) interfaces, Fiber Data Distributed Interfaces (FDDIs), etc. In general, such interface 110 may include ports adapted to communicate with a suitable medium. In some cases, they may also include a separate processor, and in some cases, volatile and/or non-volatile memory (eg, RAM).

While the system shown in FIG. 1 illustrates one specific architecture for a computing device 100 for implementing one or more of the inventions described herein, this is by no means the only one in which at least a portion of the features and techniques described herein may be implemented. device architecture. For example, an architecture with one or any number of processors 103 may be used, and such processors 103 may be present in a single device or distributed among any number of devices. In one embodiment, a single processor 103 handles communications as well as routing calculations, while in other embodiments a separate dedicated communications processor may be provided. In various embodiments, different types of features or functions may be implemented in systems according to the invention, including client devices (e.g., tablet devices or smartphones running client software) and server systems (e.g., server system described in more detail below).

Regardless of the configuration of the network devices, the system of the present invention may employ one or more memory or storage modules (such as, for example, remote memory block 120 and local memory 101) configured to store data for general network operation program instructions or other information related to the functionality of the embodiments described herein (or any combination of the foregoing). Program instructions may control, for example, execute the execution system and/or one or more applications or include the execution system and/or one or more applications. Memory 120 or memory 101, 120 may also be configured to store data structures, configuration data, encrypted data, historical system operating information, or any other non-programmatic information, specific or general, as described herein.

Because such information and program instructions may be employed to implement one or more of the systems or methods described herein, at least some network device embodiments may include a non-transitory machine-readable storage medium that may, for example, be configured as Or designed to store program instructions, status information, etc. for performing the various operations described herein. Examples of such non-transitory machine-readable storage media include, but are not limited to, magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media, such as CD-ROM disks; magneto-optical media, such as optical disks, and specially configured A hardware device that stores and executes program instructions, such as read-only memory (ROM), flash memory, solid-state drive, memristive memory, random access memory (RAM), and the like. Examples of program instructions include, for example, object code that can be generated by a compiler, such as machine code that can be generated by a compiler or a linker, such as can be generated by, for example, a JAVA ^™ compiler and can be executed by using a Java virtual machine or equivalent. Byte code, or a file containing high-level code (such as a script written in Python, Perl, Ruby, Groovy, or any other scripting language) that can be executed by a computer using an interpreter.

In some embodiments, a system according to the present invention may be implemented on a stand-alone computing system. Referring now to FIG. 2 , there is shown a block diagram depicting a typical exemplary architecture of one or more embodiments, or components thereof, on a stand-alone computing system. Computing device 200 includes a processor 210 that can execute software that performs one or more functions or applications of embodiments of the invention, such as, for example, client application 230 . The processor 210 may execute computing instructions under the control of an operating system 220 (eg, Microsoft's WINDOWS ^™ operating system, Apple's MacOS/X or iOS operating system, some variants of the Linux operating system, Google's ANDROID ^™ operating system, etc.). In many cases, one or more shared services 225 can run in system 200 and can be used to provide common services to client applications 230 . The service 225 may be, for example, a WINDOWS ^™ service, a user-space common service in a Linux environment, or any other type of common service framework used with the runtime system 210 . Input device 270 may be of any type suitable for receiving user input including, for example, a keyboard, touch screen, microphone (eg, for voice input), mouse, touch pad, trackball, or any combination thereof. Output devices 260 may be of any type suitable for providing output to one or more users, whether remote or local to system 200, and may include, for example, one or more screens for visual output, speakers, printers or any combination of them. The memory 240 may be random access memory having any structure or architecture known in the art for use by the processor 210, eg, for running software. Storage device 250 may be any magnetic, optical, mechanical, memristive, or electrical storage device for storing data in digital form. Examples of storage device 250 include flash memory, magnetic hard drives, CD-ROMs, and the like.

In some embodiments, the system of the present invention can be implemented on a distributed computing network (eg, a computing network with any number of clients and/or servers). Referring now to FIG. 3 , there is shown a block diagram depicting an exemplary architecture for implementing at least a portion of a system according to an embodiment of the present invention over a distributed computing network. Depending on the embodiment, any number of clients 330 may be provided. Each client 330 may run software for implementing the client-side portion of the invention; a client may include, for example, the system 200 shown in FIG. 2 . Additionally, any number of servers 320 may be provided for processing requests received from one or more clients 330 . Client 330 and server 320 may communicate with each other over one or more electronic networks 310, which in many embodiments may be the Internet, a wide area network, a mobile phone network, a wireless network (e.g., WiFi, Wimax, etc.), or a local area network (or Virtually any network topology known in the art; the present invention does not prefer any one of them. Network 310 may be implemented using any known network protocols including, for example, wired and/or wireless protocols.

Additionally, in some embodiments, server 320 may call external service 370 to obtain additional information, or refer to additional data about a particular call, if desired. Communication with external services 370 may occur, for example, over one or more networks 310 . In various embodiments, external services 370 may include network-available services or functions associated with or installed on the hardware device itself. For example, in an embodiment where the client application 230 is implemented on a smart phone or other electronic device, the client application 230 may obtain information stored in the server system 320 in the cloud or be deployed on a server system related to one or more specific enterprises or users. Information on external services 370 in the building.

In some embodiments of the invention, client 330 or server 320 (or both) may utilize one or more dedicated services or applications that can be deployed locally or remotely across one or more networks 310 . For example, one or more databases 340 may be used or referenced by one or more embodiments of the invention. Those of ordinary skill in the art will appreciate that the database 340 can be arranged in a variety of architectures and using a variety of data access and execution devices. For example, in various embodiments, one or more databases 340 may comprise a relational database system using Structured Query Language (SQL), while other databases may comprise alternative data storage techniques, such as are known in the art as "SQL" NoSQL" (for example, Hadoop Cassandra, Google BigTable, etc.) data storage technology. In some embodiments, deformed database architectures may be used in accordance with the present invention, such as column-oriented databases, in-memory databases, clustered databases, distributed databases, or even flat-file data stores. Those of ordinary skill in the art will understand that any combination of known or future database technologies may be used as appropriate, unless a specific database technology and a specific arrangement of components is specified for a specific embodiment herein. Furthermore, it should be understood that the term "database" as used herein may refer to a physical database machine, a cluster of machines acting as a single database system, or a logical database located within an overall database management system. Unless a specific meaning is indicated for a given use of the term "database", "database" should be understood to refer to any of these meanings of the word, and those of ordinary skill in the art should understand all of these meanings to mean the term "database". The simple meaning of ".

Similarly, most embodiments of the invention may utilize one or more of security system 360 and configuration system 350 . Security and configuration management are common information technology (IT) and network functions, and each technology is typically associated with any IT or network system to some extent. Those of ordinary skill in the art will appreciate that any configuration or security subsystem known in the art, now or in the future, may be used in conjunction with embodiments of the present invention without limitation, unless the description of any particular embodiment specifically requires specific security 360 or configuration system 350 or method.

In various embodiments, the functionality used to implement the systems or methods of the present invention may be distributed among any number of client and/or server components. For example, various software modules can be implemented to perform various functions related to the present invention, and these modules can be implemented in various ways to run on server and/or client components.

conceptual framework

Figure 4 is a block diagram of a preferred embodiment of the present invention illustrating a system for automated chat detection comprising common contact center elements and running in parallel with actual contact center operations. As shown, the contact center 400 can implement a TCM platform 401 that can be used to detect the initiation or initiation of a case. The TCM platform 401 can run automatically, or optionally receive human interaction through a graphical user interface for running test cases and viewing test result reports, which can be stored in the test database 402 . When running a test, the TCM platform 401 utilizes the chat processing system 403 and the CCM platform 410 to initiate a test case, and then both the chat processing system 403 and the CCM platform 410 can start their respective automated testing processes. The chat processing system 403 can emulate a plurality of virtual clients 405 running through a web server 404 to send and receive data via the Internet or other data communication network 406, while the CCM platform 410 can similarly emulate a virtual contact center agent 411, which Virtual contact center agents can receive and respond to data requests. Data requests sent by simulated clients 405 over data network 406 may be received and processed by router 407, which may forward requests from clients to interaction servers 408 and from agents to clients over data network 407. The interaction server 408 can validate the data request using a chat classifier 409, which can identify the request as part of a test case or actual contact center operation to determine a handling protocol. If the request is determined to be part of a test case, the interaction server 408 may continue with test case processing. If the request is inbound from router 407, the request can be forwarded to CCM platform 410 for processing by virtual agent 411, or if the request is an outbound request from virtual agent 411, the request can be sent to router 407 for processing by Data network 406 delivers to virtual guest 405 . Depending on the specific attributes of the test case, the virtual agent 411 may operate by interacting directly with the interaction server 408 or automatically interacting with a real or simulated agent desktop environment. During and/or after execution of a test case, data may be stored in database 402 by CCM platform 410 or chat processing system 403 for building test reports to be stored for subsequent viewing by users through TCM platform 401 . As such, it should be understood that the flow of data requests within a test case is bi-directional, i.e., requests can be sent continuously and asynchronously from the simulated client 405 to the simulated broker 411 and vice versa without requiring a strict data flow pattern or Rhythm. It should be appreciated that this enables the simulation of a customer sending multiple chat requests while the agent is waiting to send a response, or an agent sending multiple requests while the customer is waiting. Such situations are actually commonplace, and as such, test cases can more accurately simulate actual contact center operations, resulting in more relevant and reliable test data.

As shown, normal operations within the contact center 400 may continue without interruption while a test case is being executed, according to an embodiment. The customer 420 can continue to run the chat interface 421 normally, and send a chat request to the contact center agent 422 according to the illustrated flow, and the detection case has no impact on the customer experience. Chat requests may be sent from chat interface 421 over data network 406, and may then be received and processed by router 407 within the contact center. Router 407 may then send the requests to interaction server 408, which may then validate the requests with chat classifier 409 to determine their nature as legitimate customer interactions. The request may then be sent to the agent 421 and returned along the reverse path through the interaction server 408, the router 407, and then out through the data network 406 from the contact center 400 to the customer's chat interface 421. As such, it should be understood that normal contact center operations can run in parallel with detection cases without any impact on customer experience.

FIG. 8 is a block diagram of a preferred embodiment of the present invention, illustrating a system for automated audio quality detection within a contact center 800 . As shown, web server 801 may send reference audio 802 (ie, audio samples simulating a customer's interaction with a contact center agent) to call engine 803 . Similarly, web server 807 may be used to send reference audio 808 to endpoint emulator 806 representing audio samples of contact center agents engaging in interactions. The call engine 803 can then initiate a simulated call over a PSTN 804 or similar network (eg, the Internet or similar data network in the case of a VoIP call) to which a router 805 within the contact center 800 can connect. Router 805 may then determine to send a call simulation to endpoint simulator 806, which may use previously received reference audio 808 to simulate a contact center agent's response to the call. As shown, a two-way call flow can be established between the call engine 803 and the endpoint emulator 807, facilitating continuous call simulation of persistent interactions as appropriate. Each time the call engine 803 or endpoint emulator 807 receives audio, it can be scored based on the quality of the audio and this score optionally stored in a database 809 or similar storage medium for later retrieval for inspection or analysis . In this way, automated testing of the audio quality of a system in a contact center is facilitated, and the results of such testing are stored for use in any of a variety of further applications, such as, for example, generating a report or analysis detailing the testing results Previous inspection results are used to optimize future inspections or contact center operations. It should be understood that the illustrated configurations are exemplary and that various additional or alternative elements may be utilized in accordance with the present invention, thereby enabling such systems to be flexible in nature and readily adaptable to various contact center architectures.

Detailed Description of Exemplary Embodiments

Figure 5 is a method diagram of a preferred embodiment of the present invention illustrating the general flow for handling automated chat detection within a contact center. In a start step 501, a detection case starts. Such detection cases may be automatically triggered as part of a scheduled event or routine, or may be manually triggered through user interaction with the TCM platform 401 as described above. In a second step 502, virtual agents and virtual clients are created within the detection system, and their creation results can be recorded during a recording step 507 in the detection database 402 or other storage medium. Then in step 503 the virtual customer initiates a chat session and in recording step 507 the results can be recorded again. Then in step 503, the chat classifier classifies this chat session as part of a detection case to ensure boundary hardening so that detection data does not overlap or otherwise interfere with production environment data during contact center operations. Upon receiving the detect chat request, the virtual agent may respond in step 504 and record the result of this response in recording step 505 . Depending on the detection case, in step 506 the CCM platform 410 may interact with real or virtual agent desktops to monitor agent experience and further evaluate contact center operations, and may record the results of this interaction in recording step 507 . Finally, in the reporting step 508, the information recorded from the previous steps of the detection case can be summarized and formulated into a result report, which can be further stored in the database 402 or similar storage medium for subsequent retrieval. It should be understood that this method scheme is exemplary, and that while the inventors believe that the illustrated scheme is an ideal solution, alternative implementations are possible in accordance with the invention. It should be further understood that test cases may contain alternative or additional components, and that the illustrated flow should not be construed as limiting the scope of the test process to only the illustrated elements, as a key feature of the present invention is scalability and therefore the present invention A wide variety of contact center architectures implemented as additional steps inserted into the detection process as shown can be easily adapted.

FIG. 6 is an illustration of an exemplary graphical user interface 600 for creating users and modifying detection cases within the TCM platform, according to a preferred embodiment of the present invention. As shown, the interface 600 may include a number of components, such as an interactive button or similar element 601 for creating a new test step, a number of text fields describing elements of an existing test step, such as a step description 602, Text string to wait 603, text to send 604, criteria 605 for pause length between steps, clickable or interactive element 606 for deleting a step or clickable or Interactive element 609, clickable or interactive element to reorder steps 607, clickable or interactive element 608 to edit an existing step, or to run a selected step Clickable or interactive elements 610 of , for example (as shown) delete multiple steps in a single run.

When creating a step, the user can provide various information to identify and control the behavior of the detection step. For example, as shown, a description column 602 may be implemented to identify steps for easy understanding of previously established test cases. The behavior control field as shown may include a text string 603 that the detection agent or client must wait to receive before processing, or a similar text string 604 that should be sent when a step is initiated. This way, each step can emulate a "send-receive" pattern to simulate a client-agent interaction, or a step can include only one of the two domains in order to simulate an asymmetric interaction, where one party may send multiple chat messages before receiving a response . As further illustrated, numerical behavioral control elements may be implemented, for example, to specify wait times 605 between steps, thereby controlling the pace of detection cases. This can be implemented to facilitate "stress detection" of contact centers under high traffic, or to pace detection to distribute system load to avoid load-based Fault.

FIG. 7 is an illustration of an exemplary graphical user interface 700 for viewing a test result report in accordance with a preferred embodiment of the present invention. As shown, interface 700 may include various elements designed to convey information contained in a stored log of previously run or currently run test cases as previously described, these elements optionally including clickable or interactive Buttons 701 and 707, text display fields 702, text entry fields 706, graphical or text-based tables or charts 703, 704, and 705, or any of a variety of other user interface elements commonly known in the art. The elements shown are exemplary, and it should be understood that various configurations utilizing alternative, additional or fewer elements are possible in accordance with the invention, however, the illustrated configurations are presented as the inventor's preferred Efficient way to display desired content.

As shown, a clickable or user-interactive element, such as a button or drop-down menu 701, may display and allow the user to select a result report for viewing, selected from those available in a storage medium (e.g., database 402). Various reports. A user can select a report from these elements, which can then dynamically update the display of interface 700 to reflect relevant data from the selected report. The text display field 702 can be implemented to present non-interactive data to the user, i.e., recorded information related to a previous test case that the user should not need or be able to run, as this information may be needed to prevent errors due to human tampering or error. Inconsistent or unreliable data. The information so presented may include, but is not limited to, detection case or detection activity names, counts of the amount of chat sessions or requests performed during the detection case, and timestamp data, such as the date and time the detection was run or the chat was initiated. It should be understood that this information may vary greatly depending on the specific nature of the detection case and depending on the particular implementation of the invention within the contact center, and that such information as shown is exemplary and that, in accordance with the invention, alternative, SUBSTITUTE OR ADDITIONAL INFORMATION.

Interface 700 may also include (as shown) a number of graphical or text-based tables or charts 703, 704, and 705 for presenting formulated or otherwise organized data to a user. A graphical table 703 is referred to, for example, circles representing relative percentages of passed or failed detections, or possibly other statistics presented graphically, such as duration or number. Such graphics may be clickable or user-interactive, which optionally allows the user to modify the information presented within the graphics and optionally dynamically update the display as selections are made. In this way, a user can concisely view multiple statistics for a given report without cluttering the interface 700 with numerous graphics, and the user is able to view only the data of interest without having to browse through irrelevant or unnecessary information, thereby Reduce user time and frustration, and increase the reliability of your analysis by reducing the risk of misinterpreting data. A text-based table or chart 704 can be implemented to display these data as details on individual interactions within a detection case, such as (as shown) the name or type of chat interaction initiated as part of the detection, the number of interactions, or Other numerical measures and ratios of successes and failures in the displayed interactions. It should be understood that such information as shown is exemplary and that additional or alternative information may be presented according to specific reports or implementations within the contact center in accordance with the present invention.

A text-based table or graph 705 may be displayed presenting details recorded from the interactions within the detection case. Such information may include (but is not limited to) the number and name of the interaction, the location where recorded information for the interaction is stored, the time or duration of the interaction, the results of the execution of the interaction with an optionally variable level of detail (e.g., a simple pass/fail or detailed error reports) or clickable or user-interactive elements, such as hyperlinks or buttons, as can be used (as shown) to display a visual record of the interaction when clicked. It should be understood that this information is exemplary and may vary broadly depending on the specific report or implementation within the contact center, furthermore, the user may select what data to display in any particular field, row or column of the chart or table from Define these to view only the data of interest as described above. Thus, the data displayed in a chart or table can be controlled using clickable or user-interactive elements, for example, a text entry field 706 where the user can enter a specific interaction name or quantity to view in more detail, enabling the user to select from an optional A clickable drop-down menu-style field 707 for efficient navigation to select from sorted or presented data selections in a sorted manner. It should be understood that these elements are exemplary and that the nature and function of all illustrated elements may vary in accordance with the invention and that new methods and configurations of user interface elements are available in the art and may be implemented in accordance with the invention. use.

Figure 9 is a method diagram of a preferred embodiment of the present invention illustrating the general flow for handling automated audio quality detection that may be utilized within a contact center according to the system described above (see Figure 8). As shown, in an initial step 901, call simulation begins. This can be initiated through a web interface (as previously illustrated, see Figure 8) or other means of interacting with the detection system, and can be performed as part of a manual or automated process. In a next step 910, reference audio is sent to an endpoint simulator for use in simulating a contact center agent's response to an inbound interaction from a customer. In parallel step 920, similar reference audio may be sent to the call engine for use in simulating an inbound interaction of a customer with a contact center agent. In a next step 921, the reference audio for the customer simulation may be sent to the contact center via the inbound call processing means (e.g. via the PSTN or similar telephone network or via the Internet or other data network for VoIP call interactions), And can be handled within the contact center according to standard call handling for inbound interactions. In a next step 922, the reference audio may be routed within the contact center to an endpoint simulator for simulated agent processing. In a next step 911, the endpoint emulator can score the received audio according to quality, and can then respond to the incoming reference audio with the reference audio received in the previous step 910, thereby simulating the agent's response to the customer interaction. In a next step 930, audio may be sent from the endpoint emulator back to the call engine through the outbound processing means, simulating the agent's response received by the customer. The call engine can then score the audio based on quality, and in a final step 931, the call simulation can optionally proceed to exchange reference audio between the call engine and the endpoint simulator, thereby simulating a persistent interaction between the customer and the contact center agent. interaction. In optional step 932, the scoring data from previous steps 911 and 930 may be stored for future use in a database or similar data storage medium, which may be internal or external to the contact center (e.g., at Remote cloud storage services on the Internet or other data networks). It should be understood that the illustrated steps are exemplary and that additional steps may be implemented in accordance with the present invention and may be suitable depending on the particular contact center arrangement, such as those including additional software or hardware elements not unique to the exemplary system additional steps.

FIG. 10 is a block diagram of an embodiment of the present invention illustrating a system for automated audio quality detection within a contact center 800 . As illustrated and previously described, web server 801 may send reference audio 802 , ie, an audio sample simulating a customer's interaction with a contact center agent, to call engine 803 . According to an embodiment, multiple audio generation devices 1001 may be implemented to generate reference audio 808 for simulating agent responses to inbound audio interactions. The reference audio may be transmitted through agent hardware 1002 (eg, a telephone handset or headset), or through audio software on an agent workstation for use in detecting VoIP call interactions. The audio can then be sent through the call manager 1003, which can be used to handle call interactions and responses between simulated agents and customers. Call engine 803 may initiate an analog call over PSTN 804 or similar network (eg, the Internet or similar data network in the case of a VoIP call) to which router 805 within contact center 800 may be connected. Router 805 may then determine to send a call simulation to call manager 1003, which may use previously received reference audio 808 to simulate a contact center agent's response to the call. As shown, a two-way call flow can be established between call engine 803 and call manager 1003, facilitating continuous call simulation of persistent interactions as appropriate. Each time the call engine 803 or call manager 1003 receives audio, it may be scored based on the quality of the audio and this score is optionally stored in a database 809 or similar storage medium for later retrieval for review or analysis. In this way, the automated detection of the audio quality of the contact center's systems is facilitated, and the results of such detections are stored for use in any of a variety of further applications, such as, for example, generating reports detailing the detection results or Analyze previous inspection results to optimize future inspection or contact center operations. It should be understood that the illustrated configuration is exemplary and that various additional or alternative elements may be utilized in accordance with the present invention, thereby enabling the system to be flexible in nature and readily adaptable to various contact center architectures.

FIG. 11 is a diagram of an exemplary HATS device 1100 for simulating a contact center agent incorporating the physical and acoustic characteristics of a human torso. As shown, the HATS device 1100 may have the general physical shape and form of a human torso, and may be constructed in such a manner and with these materials to replicate the density or other properties of the human body for acoustic accuracy. As shown, the HATS device 1100 may include an integral fixedly or removably attached audio generating device 1001 that may be used to transmit reference audio samples to properly simulate a speaking agent as a hardware, e.g., telephone head A headset microphone 1103. The HATS device 1100 may further include a plurality of integrally or removably attachable audio receivers 1102, which may be designed and positioned in such a manner as to simulate the ears of a human agent for receiving transmitted audio (e.g., from phone headset speaker 1104). As shown, the HATS device 1100 can be used in such a way as to emulate agents utilizing their workstation devices (such as (as shown) telephone headsets or other devices) so that when interacting with customers More accurately emulate the audio nature of human agents interacting with their devices. It should be understood that the configuration shown is exemplary in nature and that alternative or additional agent hardware may be utilized in accordance with the present invention, including but not limited to telephone headsets, handsets, speakerphone system or other device, and the HATS device 1100 can be easily adapted for such use.

FIG. 12 is a block diagram illustrating an exemplary method 1200 of operation for scalable peer-to-peer chat detection according to an embodiment of the invention. According to an embodiment, detection may utilize existing elements of Internet communication standards, such as HTTP headers, to perform basic functions, such as routing or configuration functions, without relying on a specific chat front end. In this way, a specific detection system can interact with various front ends in a meaningful way, and new or replacement front ends can be implemented without requiring changes to the detection system itself.

In an initial step 1201, a chat front end (eg, such as a web-based chat application or a dedicated mobile chat application on a mobile electronic device) may request an interaction. Such a request may be initiated by the user attempting to chat (by clicking a "Chat with Agent" button or similar interactive user interface interaction), or may be an automated process (such as in automated detection using simulated chat participants) part of the . This way, detection cases need not be based on the specific mechanism initiated, as this mechanism may vary according to changes in the front end exploited during any specific interaction.

In a next step 1202, data sent to the detection system (e.g., a "chat processing system" or other system element previously described) can be processed to interpret embedded information, such as HTTP files used during the detection run head. For example, an interaction may request a specific detection server, or request processing according to detection criteria (described above) for a specific detection campaign. In this way, detection can be ensured to run regardless of the front end being exploited, as the run information is inherent to the interaction data being communicated rather than relying on any form of normalization between front ends.

In a next step 1203, a detection interaction configuration (eg the requested configuration determined in the previous step) may be loaded to configure the detection execution. In this way, the test can configure itself to run to increase efficiency and help avoid user-introduced errors that could reduce the reliability of test results (eg, agents choosing invalid configuration arrangements or making typographical errors that affect functionality). In addition, loaded configurations can leverage this run as a communication technology, enabling detection cases to run across network technologies as needed for comprehensive detection without requiring a front-end to explicitly Operate (e.g., route a detection case from an Internet-based chat application over a cellular or fiber optic network, regardless of the actual physical connection to the computing device operating on the front end. It will be understood that by operating in this manner, the detection case Can test for "real world" operating conditions that may exist in actual operations between a customer and an agent, rather than within a testing facility or contact center without taking into account external factors (for example, a customer's specific network connection or computer hardware) Controlled environment for testing.

In a next step 1204, the detection communication may optionally be over an alternative or additional web technology, for example, to detect a reliable connection to the customer by using other connections to the chat (e.g., via a web browser or smartphone or other App chat on cellular-enabled mobile devices). In this way, a single detection case can be used to detect multiple connections, thereby collecting as much detection data as possible in each interaction to speed up the detection process.

In a final step 1205, the inspection may draw conclusions and record or submit the results as appropriate (eg, store or send the results according to the configuration loaded in the previous step). It should be understood that while the described detection runs may involve agents and detection systems, the functionality provided by the present invention is equally applicable and useful for alternative arrangements, for example, between multiple automated "chatbots" or similar simulated participants or Detection interactions between multiple agents. As such, inspection runs can include a variety of physical or virtual arrangements and provide a comprehensive inspection of all conditions or interactions that may be experienced during actual contact center operations.

FIG. 13 is a method diagram illustrating an example method 1300 for activity-based detection operations. According to this arrangement, multiple detection cases can be configured and initiated from a single "activity" that can describe the various specific detections to be performed, and as such, multiple detections can be easily configured, executed and reported. In addition, campaigns can be considered to run autonomously given the correct configuration, for example, configuring specific detection runs on specific schedules or configuring specific detection runs to respond to specified conditions (e.g., within a contact center). hardware or software updates). In addition, multiple activities can interact with each other to perform logic-based adaptive detection, for example, using the results of one activity to configure another activity or to determine a specific activity to run the next activity.

Activities can be created or managed in various ways, for example, from a remote or web-based management software interface or application (e.g., suitable for an administrator to manage activities away from the office) or through a detection interface as previously described (see Figure 6) to create or manage activities so that they are accessible when needed, regardless of the administrator's location or available hardware. Furthermore, by integrating this functionality with existing detection creation elements (i.e., centrally distributed hardware or software system elements to which other elements such as the administrator Specific administrator devices are updated and existing detection systems can be easily used to allow activity-based functionality.

In an initial step 1301, activities may be configured, for example, by a contact center administrator or other authorized user. Such configurations may be of varying nature and granularity as appropriate to suit the desired assay run. As such, campaigns can be used to enforce specific detection parameters or conditions, or to perform basic detection only at scheduled intervals, or in response to specific triggers or any other such configurable operation that may be required.

In a next step 1302, an activity may be initiated according to configured parameters (eg, triggered by an event or initiated according to a set schedule). Additionally, campaigns can be triggered internally (from within the contact center, initiating an interaction with an external real or virtual user outbound) or externally (an external user initiating an interaction with the contact center inbound), as may be appropriate for a specific campaign run And depending on the nature of the detection to be performed. For example, an external user may choose to initiate an interaction and trigger an activity to verify functionality after making a hardware change to their computer workstation, or a contact center may initiate an outbound interaction as part of a schedule to maintain a "health check" on operations .

In a next step 1303, the interactions may be run according to the activity configuration, eg one or more interactions run according to individual specific parameters and potentially run. In this way, activities can be used to control various assay run parameters and perform multiple assays that may or may not be similar in nature, thereby providing a unified method for rapidly configuring runs.

In a final step 1304, as the tests are completed, their individual results may be received and stored or reported as appropriate, and when the campaign is fully completed, a final "campaign report" may be generated to provide an overview of the campaign run. In this way, individual assays can be examined for specific results, while the overall run of the campaign can be viewed for a quick "overview", which may be appropriate, for example, in situations where specific features or systems may not have been closely scrutinized Under the periodic "health check" type detection.

The skilled person will be aware of a range of possible modifications to the various embodiments described above. Accordingly, the invention is defined by the claims and their equivalents.

Claims (10)

1. for a system for the Aulomatizeted Detect of the interactive environment based on chat, comprising:

Detection case management platform;

Chat processes system; And

Liaison centre's manager;

Wherein said detection case management platform allows user that the operation of described system is configured;

Wherein said chat processes system and runs multiple virtual clients;

And wherein said liaison centre manager runs multiple virtual protocol persons to participate in the chat sessions with virtual client.

2. system according to claim 1, it farther includes chat grader;

Wherein said chat grader is classified to described alternately according to mutual character, with the border between detection and the liaison centre's environment being currently running that strengthening is currently running.

3. system according to claim 1, it farther includes desktop automated system;

Wherein said desktop automated system is run real or simulation succedaneum's desktop and is used for detecting succedaneum's experience and software function.

4. system according to claim 1, it farther includes data base;

Data in described data base are conducted interviews and store data in described data base by the parts of wherein said system.

5. system according to claim 4, wherein said detection case management platform can show the report that the data from storage produce.

6. the method for running the automated detection system of the interactive environment based on chat, it comprises the following steps:

A () starts to perform detection case;

B () creates virtual protocol person and virtual client in described system; And

C () initiates chat sessions between virtual client and virtual protocol person.

7. method according to claim 6, it further includes steps of

(a) chat sessions is classified with by its property identification for detect case a part.

8. method according to claim 6, it further includes steps of

A () interacts with real or simulation succedaneum's desktop and carries out additional detected for succedaneum's experience and software function.

9. method according to claim 6, it further includes steps of

A output data from step before this be recorded in data base or other storage mediums by ().

10. method according to claim 7, it further includes steps of

A () reports from the output data genaration of record.