Method and apparatus for automatically taking action based on the content of call center communications

Abstract

A method and system for automatically executing an action within a call center environment. Data is aggregated from multiple data sources into a combined data stream. One of the data sources is a source of data corresponding to at least one communication processed by the call center one of the data sources can be a source of external data representing activity that is external to the call center. The combined data stream is processed into successive batches of data corresponding to one or more communications between a call center agent and a communicating party received by the call center. A sensor data structure specifying at least one rule is applied to the batches of data. The at least one rule can include a machine learning model and a configuration data structure based on historical data from the multiple data sources. When it is determined that at least one of the batches satisfies the at least one rule, a notification message relating to the one or more communications is generated. The call center executes an action specified by the sensor data structure based on the notification message. The action can address a situation corresponding the at least one communication. The actions can be various actions such as notifying a specified party, generating an API call, or the like.

Claims

1. A method for executing actions related to communications received in a call center, the method comprising: aggregating data from multiple data sources into a combined data stream, at least a first data source of the multiple data sources being a source of data corresponding to at least one communication processed by the call center and at least a second data source of the multiple data sources being a source of external data, wherein the external data is data representing activity that is external to the call center; processing the combined data stream into successive batches of data corresponding to one or more communications between a call center agent and a communicating party received by the call center; applying a sensor data structure defining at least one rule to the batches of data, wherein the at least one rule includes a machine learning model and a configuration data structure based on historical data from the multiple data sources; determining that at least one of the batches satisfies the at least one rule and generating a notification message relating to the one or more communications in response to the determining; and the call center executing an action based on the notification message, wherein the action addresses a situation corresponding the at least one communication.

2. The method of claim 1, wherein the configuration data structure is updated multiple times during the communication and the configuration data structure is a delta table.

3. The method of claim 2, wherein the configuration data structure includes a keyword, a frequency designation, a time range, and a flag threshold value indicator for each of the successive batches of data.

4. The method of claim 2, wherein applying at least one rule includes: comparing the batch of utterance data with the keyword and frequency designation; and generating a flag if the batch of utterance data satisfies criteria, the criteria including the batch of data containing the keyword at a frequency specified by the frequency designation.

5. The method of claim 4, wherein the configuration data structure further includes a speaker indicator and the criteria further includes that the keyword is uttered by a speaker specified by the speaker indicator.

6. The method of claim 1, wherein the action based on the notification message is at least one of: sending a notification to an agent; generating an API call; sending a notification to an agent supervisor; adding a party to an email campaign; and/or sending data to an external system.

7. The method of claim 1, wherein the first data source includes a source of voice and/or text data relating to communications processed by the call center.

8. The method of claim 1, wherein the second data source includes at least one of: a source of events occurring external to the call center; a web server; and/or at least one loT device.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the appended drawings various illustrative embodiments. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings:

(2) FIG. 1 is an architectural diagram of a conventional cloud based contact center computing environment.

(3) FIG. 2 is a diagram of pipeline data processing in accordance with disclosed implementations.

(4) FIG. 3 is a diagram of structured streaming processing modes in accordance with disclosed implementations.

(5) FIG. 4 is a diagram illustrating a stream join use case in accordance with disclosed implementations.

(6) FIG. 5 is a block diagram of a process for creating an action in accordance with disclosed implementations.

(7) FIG. 6 illustrates a more detailed computing architecture for providing automated actions within a call center in accordance with disclosed implementations.

(8) FIGS. 7A-7E illustrate a user interface in accordance with disclosed implementations.

(9) FIG. 8 illustrates method 800 of automatically executing an action within a call center environment in accordance with the disclosed implementations.

DETAILED DESCRIPTION

(10) FIG. 2 illustrates a data pipeline 200 of a disclosed implementation. The pipeline 200 of this example processes two types of datasets: utterance data 202 and “sensor” configuration data 204. Utterance data 202 is derived from communications between agents and customers, as described in more detail below. Sensor configuration data represents conditions under which events (also referred to as “hits” herein) should be generated, also as described in greater detail below. Pipeline 200 can use a Machine Learning model, from the Spark NLP library for example, to compute a sentiment for communications. The sentiment can be included in the utterance data. Additionally, the pipeline can generate timestamps for the generation of hit and notification events. The term “sensor” as used herein includes data structures and processing models that can be applied to data streams and which set forth rules for generating an event.

(11) Sensor configuration data 202 includes conditions under which an event is to be generated, such as key words, sentiment, frequency of key words, and the like. Sensor configuration data can also include an account identification or other identification data of the customer, entity, and/or call center. Sensor configuration data can also include a sensor name, applicable time ranges, and a time stamp. An example schema for sensor data is set forth below.

(12) SensorConfigurations( account_id: String, active: Boolean, configured_hits: Integer, filter: ( keywords: Array[String], sentiment: String

(13) ), frequency: String, sensor_id: String, sensor_name: String, time_range: String timestamp: Timestamp,

(14) )

(15) Utterance data 204 is collected and derived from the content of communications between customers and agents. For example, a transcription of the communication (a phone call for example) can be created by recording the communication and using known speech to text processing. The text can then be parsed to identify keywords and/or keyphrases (referred to collectively herein as “keywords”). The utterance data can also include sentiment data of a communication and other identifying metadata, as described further below. An example schema for sensor data is set forth below.

(16) Utterance( account_id: String, agent_id: String, channel_id: String, id: String, interaction_id: String, text: String, timestamp: Timestamp, ‘type’: String, timestamp: Timestamp

(17) )

(18) Sensor configuration data 204 is delivered into pipeline 200 as a stream and can be stored in a Delta Table, such as a Databricks delta table created in Delta Lake. A delta table maintains an entry for each “sensor” describing the state of the sensor, including whether it is active or inactive. Pipeline 200 continuously receives utterance information, such as transcriptions of communications, as data streams, as they are generated, by a speech-to-text service for example. Transcriptions can be processed in Spark Structured Streaming micro batches. In each batch, the sensor configuration table retrieves the configurations for active sensors. Active configurations are then joined with the transcription stream at 206 in FIG. 2.

(19) Pipeline 200 matches a transcription and a configuration, at 208, when the transcription data contains at least one word specified as a key word in the sensor configuration. Additional filters can also be defined in the sensor. For example the filters can include: a sentiment filter which selects only transcriptions with the sentiment—computed as described in the added sentiment metadata—specified in the sensor configuration; and/or a speaker filter which selects only transcriptions of utterances from the speaker specified in the sensor configuration

(20) This matching process yields a stream of transcription-configuration matches or hits at 210. These hits can be published to a Kafka topic, enabling a hit count of the sensor. The pipeline also keeps, for each active configuration, a count of the hits that fall within a user-defined time window, at 212, to trigger a notification event when hits fall within a user-defined maximum frequency. This count can be kept using a Spark state store functionality on top of a RocksDB, using the flatMapGroups. Pipeline 200 can publish a notification event to Kafka when the hit count for a sensor is greater or equal to the value set in the sensor's configuration within the intended time window (time_range), when the maximum frequency (frequency) is not violated, enabling a notification to the user or any other event/signal to be generated in order to take a desired action.

(21) The pipeline outputs, hit events and notification events can be published to Kafka in json format with the following data structures:

(22) SensorHits account_id: String, interaction_id: String, sensor_id: String, sensor_name: String, speaker: String, utterance_id: String, utterance_started: Timestamp, timestamp: Timestamp

(23) )

(24) SensorNotification account_id: String, sensor_id: String, sensor_name: String, time_range: String, count: Integer, timestamp: Timestamp

(25) )

(26) The disclosed implementations can leverage Spark Structured Streaming, the Apache Spark API that allows expression of computation on streaming data in the same way and in batch computation on static data. The data is treated as never ending tables on which queries or other processing can be performed. Queries and other processes can be performed on the tables continuously on new data as it arrives. Stateful transformations are also possible. This allows an SQL Engine to operate on data streams with a high throughput, high fault-tolerance, and high scalability. Each new record in a data stream can be stored as a new row in the corresponding table.

(27) FIG. 3 illustrates micro-batch and continuous processing modes of a structured streaming architecture. Architecture 300 include input streams 302 and input tables 304.

(28) FIG. 4 illustrates an example 400 of joining data streams. In this example, data streams 402 and 404 are joined. As an example, data stream 402 could represent keywords and data stream 404 could represent sentiment. Each data stream is buffered to handle late/delayed data because corresponding events in data streams 402 and 404 could arrive out of order with arbitrary delays between them. Buffer size can be managed by dropping delayed data beyond a certain threshold. A joint time range condition is used to limit the time range of other events that each event can join against.

(29) FIG. 5 illustrates a more specific example of a process 500 for generating an action within a call center in accordance with disclosed implementations. At 502, disparate data streams from within and outside of the contact center are combined. It this example, the data streams include: voice, text (e.g., chat/sms/chatbot), arbitrary events, web events, IOT events, and stored historical data. At 504, a sensor is applied to the combined data streams. The sensor can be configured to define conditions to make a decision based on any of the metrics calculated, intents detected, keywords matched, or conditions recognized in the data streams. Intent data can be produced using known intent engines applied to the utterance data.

(30) Predictive models can be used to predict a trigger condition based on past data. For example, if a customer was browsing kidney disease on a website for re predetermined time or number of visits over a period of time, has an overdue kidney prescription, and just called with intent matched “insurance bill”, it can be predicted that there will be a sudden increase in medical payments for the customer (the “supervised event”). Once sensor conditions are triggered, then an action can be taken at 506. For example, the action can include a notification to an appropriate person or a call to a specified API. As an example, the API call could cause the customer to be adder to a “call immediately” list.

(31) FIG. 6 illustrates and example of the overall architecture 600 of a system for automatically generating actions in a call center environment.

(32) FIG. 7A illustrates a user interface for configuring and managing sensors. The various sensors, defined as the data structures described above, are displayed by name at column 702. Column 704 shows the total number of hits corresponding to the sensor. Column 706 shows the channels which the sensor is active. Column 708 shows a category of the sensor which can be used to organize and manage sensors. Column 710 indicates whether notifications for the sensor are currently activated (on) or not activated (off). Column 714 provides a selection tool for editing the corresponding sensor. FIG. 7B shows the popup user interface 711 of the UI when Notifications are selected. As shown, notifications can be turned on or off and persons, groups of persons, or APIs can be designated for receiving notifications.

(33) FIG. 7C illustrates the Create Sensor popup user interface 720. As illustrated in FIG. 7C, popup user interface 720 allows a user to enter a sensor name, a sensor category, a sentiment label, channels for which the sensor applies, speakers for which the sensor applies, ring groups for which the sensor applies, and agents for which the sensor applies. All of this data can be stored in the sensor data structure described above. FIG. 7D illustrates a Checkout popup user interface 722 which allows additional data to be specified and stored in the sensor data structure. User interface 722 allows entry of the number of hits in the sensor that will trigger a notification, the time range for the number of hits specified, time frequency of notifications for the sensor, a notification manner/channel (e.g., through a notification center of the call center, through email, etc.), available integrations, and data triggers specifying data outputs, such as email reports, API, calls and other data that results in desired actions. After entering all data/parameters, a selection of the Create button will cause the sensor to be created. FIG. 7E shows sensor notification report popup 724 which allows a user to view and manage sensor notifications.

(34) FIG. 8 illustrates method 800 of automatically executing an action within a call center environment in accordance with the disclosed implementations. Method 800 can be accomplished by the systems described above. At 802, data is aggregated from multiple data sources into a combined data stream. One of the data sources is a source of data corresponding to at least one communication processed by the call center one of the data sources can be a source of external data representing activity that is external to the call center. At 804, the combined data stream is processed into successive batches of data corresponding to one or more communications between a call center agent and a communicating party received by the call center. At 806, a sensor data structure specifying at least one rule is applied to the batches of data. The at least one rule can include a machine learning model and a configuration data structure based on historical data from the multiple data sources. At 808 it is determined that at least one of the batches satisfies the at least one rule and a notification message relating to the one or more communications is generated. At 810, the call center executes an action specified by the sensor data structure based on the notification message. The action can address a situation corresponding the at least one communication. As noted above, the actions can be various actions such as notifying a specified party, generating an API call, or the like.

(35) It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular implementations disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.