Systems and methods for search based call routing

A computerized method of routing calls includes the following steps performed by a server computing device: receiving a set of call attributes associated with an incoming call; identifying a document containing call routing instructions corresponding to the call attributes by querying a search index in electronic communication with the server computing device; identifying, based on the document, a set of suitable agents having a skill and a suitable proficiency in the skill by querying an agent skills database in electronic communication with the server computing device; identifying a set of available agents in the set of suitable agents by querying an agent status database in electronic communication with the server computing device; and routing the incoming call to a target agent in the set of available agents, if there is at least one available agent; or a customer waiting queue, if there is no suitable agent.

TECHNICAL FIELD

The invention relates generally to methods and systems, including computer programs, for routing customer calls to agents (e.g., in call centers). More specifically, the invention relates to methods and systems for selecting agents to answer customer queries based at least in part on agent proficiency in one or more relevant skill areas.

BACKGROUND

Call centers help companies resolve a wide variety of their customers' service needs. Today, most call centers use an automated computer interface, such as an interactive voice response (IVR) system, to conduct at least initial interactions with customers, e.g., by playing pre-recorded messages and receiving spoken answers or touch tone phone selections back from customers, prior to determining whether to route a call to a human agent. This approach can reduce the need to utilize human agent time, such as by answering easy or frequently asked questions with automated responses, and can help efficiently collect basic information about the call to assist the agent in resolving the customer's issue, if an agent is in fact needed. In such a case, the call is placed into a wait queue and is eventually routed to an available agent.

Skills-based call routing is used in contact centers to assign incoming calls to the most appropriately skilled agent to service the call, instead of simply choosing the next available agent or assigning the call to a queue. This strategy allows contact centers to designate agents as specialists in certain products or services by indicating an agent's proficiency in each skill. The need for skills-based routing has arisen as contact centers offer more specialized services and provide higher levels of service to high-value callers. With skills-based routing, the skill and proficiency needed to service a particular call can be determined by call-associated data, including the dialed telephone number, the caller's identity, caller attributes, and selections made during the IVR intake process to understand caller's intent. The call associated data is typically referred to as “Key Value Pairs” (KVPs) with values that are associated with specific call variables. A skills-based routing system can include a set of routing rules that utilizes the KVPs to attempt to match the call to a suitably trained agent in an available state before expanding the routing to less optimally skilled agents.

However, such call routing technology has developed largely without any standards for interoperability. Today, most solutions are vendor-specific and can involve thousands of custom-designed routing rules. This state of affairs can lead to high integration costs, particularly if a change in vendors is desired after a complex rules-based scheme is already developed within one proprietary solution. It would therefore be desirable to provide a technology that reduces or eliminates such costs and provides a simple and effective multi-vendor skills-based routing solution.

SUMMARY

The invention includes methods and systems that can dynamically and intelligently route calls (e.g., within a call center). A search function (e.g., Amazon Web Services (AWS) Elastic Search) can be used to match attributes of incoming calls to a database of documents (e.g., JSON documents) including comparable call attributes and target agent skills. A routing solution can be built by using a word matching algorithm within a search function (e.g., AWS Elastic Search or another Lucene-based search) to return agent skills corresponding to documents having the best matching scores according to pre-specified criteria.

In one exemplary AWS implementation, the invention has been built for the Genesys Engage premise solution and the Amazon Connect cloud-based contact center. Several (e.g., hundreds of) JSON documents can be formulated to include call associated data values (e.g., KVPs), target agent skills, and/or required proficiency levels in each skill. The JSON documents can be loaded into an Elastic Search (ES) index. AWS lambda functions can be used to query ES with call associated data (as can, for example REST APIs from Genesys). One lambda function can be called from a Connect call flow to query ES with a given set of call attributes. The resulting agent skill can be returned. The agent skill can be searched against one or more databases including agent skills, proficiencies and statuses. An agent in a ready status having a desired proficiency (e.g., a high proficiency for a premium customer, or a lower proficiency for a core customer) can then be targeted with the call, with the call placed directly to that agent or designated to that agent's queue.

In some embodiments, each inbound call and its associated KVPs can be sent to ES to return a list of agent skills to target with a corresponding relevance score. Each call can then be routed to the skill with the highest relevance score. In this manner, instead of calls being serviced strictly in the order of their arrival, calls can be serviced as agents with appropriate skills become available. The ES domain can be hosted on AWS, which itself can be accessible via secure REST APIs. Since these rules can be exposed via secure REST APIs, any contact center solution can use ES, making it vendor-agnostic and allowing users to build their own JSON-based routing strategies. In this way, a routing strategy can be executed in ES, and the results can be returned to the proprietary contact center solution, which can then direct the call to the selected agent.

In one aspect, there is a system for routing calls. The system includes a server computing device comprising a memory to store computer-executable instructions and a processor that executes the computer-executable instructions. The server computing device receives, from a contact center, a set of attributes for an incoming call. The server computing device searches, using an elastic search function and word matching criteria, an elastic search index to find a match (e.g., the best match) of the call attributes as compared with the attributes included in the elastic search index (e.g., contained in JSON documents). A conditional search may be used, which can include “must” and/or “should” match conditions applied to each attribute. The server computing device receives, from the elastic search database, a document (e.g., a JSON document) that meets (e.g., best meets) the word matching criteria for the set of attributes presented. The server computing device searches an agent skills database, in electronic communication with the server computing device, to identify a set of agents having the skill and a suitable proficiency in the skill (e.g., as specified in the JSON document) returned from the elastic search function. The server computing device searches an agent status database to identify an agent status (e.g., ready or occupied). If one or more agents are identified, the server computing device: (i) selects a target agent based on length of availability, (ii) sets a status of the target agent to busy, and (iii) routes the call to the target agent (e.g., to a queue of the target agent). If no agents are identified, the server computing device (i) checks to see if any agents are staffed; (ii) writes call attributes to the call attribute (or KVP) database; (iii) returns a call treatment rule to Connect call flow; and (iv) routes the call to a customer waiting queue.

In another aspect, there is a computerized method of routing calls. The method can include the following steps. First, a server computing device receives, from a contact center, a set of attributes for an incoming call. Second, the server computing device searches, using an elastic search function and word matching criteria, an elastic search index to find a match (e.g., the best match) of the call attributes as compared with the attributes included in the elastic search index (e.g., contained in JSON documents). A conditional search may be used, which can include “must” and/or “should” match conditions applied to each attribute. Third, the server computing device receives, from the elastic search database, a document (e.g., a JSON document) that meets (e.g., best meets) the word matching criteria for the set of attributes presented. Fourth, the server computing device searches an agent skills database, in electronic communication with the server computing device, to identify a set of agents having the skill and a suitable proficiency in the skill (e.g., as specified in the JSON document) returned from the elastic search function. Fifth, the server computing device searches an agent status database to identify an agent status (e.g., ready or occupied). If one or more agents are identified, the server computing device: (i) selects a target agent based on length of availability, (ii) sets a status of the target agent to busy, and (iii) routes the call to the target agent (e.g., to a queue of the target agent). If no agents are identified, the server computing device (i) checks to see if any agents are staffed; (ii) writes call attributes to the call attribute (or KVP) database; (iii) returns a call treatment rule to Connect call flow; and (iv) routes the call to a customer waiting queue.

In one aspect, the invention features a computerized method of routing calls. A server computing device receives a set of call attributes associated with an incoming call. The server computing device identifies a call routing instruction document corresponding to the call attributes by querying, using a text-based first matching criteria, a search index in electronic communication with the server computing device. The server computing device identifies, based on the returned document, a set of suitable agents having a skill and a suitable proficiency in the skill by querying, using second matching criteria, an agent skills database in electronic communication with the server computing device. The server computing device identifies a set of available agents in the set of suitable agents by querying, using third matching criteria, an agent status database in electronic communication with the server computing device. The server computing device routes the incoming call to: (i) a target agent in the set of available agents, if there is at least one available agent; or (ii) or a customer waiting queue, if there is no suitable agent in the set of available agents.

The above aspect can include one or more of the following features. In some embodiments, if one or more suitable agents are identified: the server computing device selects a target agent based at least in part on a on length of availability; sets a status of the target agent to busy; and routes the call to the target agent; or if no agents are identified: the server computing device determines whether any agents are staffed; writes call attributes to a call attribute database in electronic communication with the server computing device; and returns a call treatment rule for treating the incoming call while in the customer waiting queue.

In some embodiments, the first matching criteria include at least one required condition or at least one preferred condition. In some embodiments, identifying the document includes scoring the available documents in the search index and selecting the document having the highest relevance score. In some embodiments, the call attributes include at least a dialed phone number, and one or more caller selections made during an IVR selection process, customer originating phone number (ANI) and call arrival time. In some embodiments, the call attributes include at least a unique identifier of the caller, a skill, a skill level, a target expansion rule, a call queue time, and a call priority.

In some embodiments, the document is a JSON document. In some embodiments, the document includes at least an agent target rule and a call treatment rule. In some embodiments, the agent target rule includes a desired agent skill, an initial desired agent proficiency, and an optional target expansion rule. In some embodiments, the target expansion rule includes (i) searching a skill level above/below a first proficiency target for a first period of time, and (ii) if no agent becomes available during the first period of time, searching a skill level above/below a second proficiency target for a second period of time, wherein the second proficiency target is lower/higher than the first proficiency target. In some embodiments, the call treatment rule includes a prompt or a recording to present to a customer in the customer waiting queue.

In some embodiments, routing the incoming call further includes selecting a routing rule based on pre-specified ranking criteria in the event that there are no agents logged in to take calls with the highest ranking routing rules. In some embodiments, the documents include one or more call associated data values. In some embodiments, the incoming call has one or more associated key value pairs (KVPs) that the server computing device is configured to send to the search index to determine a set of agent skills to target. In some embodiments, each agent skill in the set of routing rule documents has a relevance score. In some embodiments, the incoming call is routed to the agent having the desired proficiency in the skill having the highest relevance score.

In some embodiments, the search index is accessible via one or more secure representational state transfer (REST) application programming interfaces (APIs). In some embodiments, the search index is accessible by more than one contact center or vendor. In some embodiments, the server computing device (i) performs a speech-to-text operation on speech received during the incoming call, thereby generating a text file, and (ii), generates, based on the text file, one or more key value pairs (KVPs) associated with the incoming call.

In some embodiments, when an agent enters a ready state, the server computing device queries a call attribute database to determine whether any calls in the customer waiting queue match the newly available agent's skills. In some embodiments, if more than one call in the customer waiting queue are returned, targeting the call that has the highest priority, or as a secondary measure, has been in the customer waiting queue for the longest time.

The invention, in another aspect, features a system for routing calls. The system comprises a server computing device comprising a memory to store computer-executable instructions and a processor that executes the computer-executable instructions. The server computing device receives a set of call attributes associated with an incoming call. The server computing device identifies a document corresponding to the call attributes by querying, using text based first matching criteria, a search index in electronic communication with the server computing device. The server computing device identifies, based on the returned document, a set of suitable agents having a skill and a suitable proficiency in the skill by querying, using second matching criteria, an agent skills database in electronic communication with the server computing device. The server computing device identifies a set of available agents in the set of suitable agents by querying, using third matching criteria, an agent status database in electronic communication with the server computing device. The server computing device routes the incoming call to: (i) a target agent in the set of available agents, if there is at least one available agent; or (ii) or a customer waiting queue, if there is no suitable agent in the set of available agents.

The above aspect can include one or more of the following features. In some embodiments, the system includes a contact center in electronic communication with the server computing device. In some embodiments, the system includes a representational state transfer (REST) application programming interface (API) in electronic communication with the server computing device. In some embodiments, the system includes a call attribute database in electronic communication with the server computing device, an agent skills database in electronic communication with the server computing device, and an agent status database in electronic communication with the server computing device.

In some embodiments, the server computing device includes a contact center call flow function. In some embodiments, the server computing device includes a text-based search function. In some embodiments, the server computing device includes a document database for storing documents representing call routing rules. In some embodiments, the server computing device includes a real-time data processing function configured to monitor when agents become available. In some embodiments, the server computing device includes multiple software application functions for looking up key value pair (KVP) values in the search index, selecting an agent, storing KVPs, selecting a call, and targeting a call.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a system100for routing calls, according to an illustrative embodiment of the invention. The system100includes a contact center102(such as Genesys or Connect) with a call flow function, a REST API104to expose the computing service, a network106(e.g., an electronic communications network), a server computing device108, a call attribute (e.g., key value pair (KVP)) database110, an agent skills database112, and an agent status database114. The server computing device108includes a search function118(e.g., Amazon Elastic Search), a document database120for storing documents representing call routing rules (e.g., an AWS managed Elastic Search domain leveraging EC2 for storing JSON documents), a real-time data processing function122(e.g., AWS Kinesis), and five software application functions (e.g., AWS lambda functions),124A,124B,124C,124D,124E for looking up KVP values in ES, selecting an agent, storing KVPs, selecting a call, and targeting a call, respectively, as described in greater detail below. Document database120can be internal or external to the server computing device108.

The contact center102initially answers the customer's call and performs call flow functions such as playing automated, pre-recorded prompts, collecting information about the purpose of the call, and/or authenticating the customer. The contact center102connects to the server computing device108via the network106. The network106can be a wide area network, such as the Internet and/or a cloud network. In some embodiments, the network106is comprised of several discrete networks and/or sub-networks (e.g., cloud to Internet). The server computing device108can be a device including specialized hardware and/or software modules that execute on a processor and interact with memory modules of the server computing device108, to receive data from other components of the system100, transmit data to other components of the system100, and perform functions for call routing as described herein.

The databases110,112,114are computing devices (or in some embodiments, all one computing device, or each a set of computing devices) coupled to the server computing device108and are configured to receive, generate, and store specific segments of data as described herein. In some embodiments, all or a portion of the databases110,112,114can be integrated with the server computing device108or be located on a separate computing device or devices. The databases110,112,114can each comprise one or more databases configured to store portions of data used by the other components of the system100. As shown inFIG. 1, the system comprises a call attribute database110, an agent skills database112, and an agent status database114. It should be appreciated that, in some embodiments, the agent skills database112and the agent status database114can be consolidated into a single database (e.g., an agent configuration database).

In one embodiment, call associated data values (e.g., KVPs) and target agent skills can be formulated into routing rules and expressed as JSON documents and loaded into an Elastic Search (ES) index120. An example document is shown below in greater detail in connection withFIG. 3A. Agent skills and proficiencies can be loaded into the agent skills database112. In some embodiments, there are thousands of agents (e.g., 10,000-20,000) online at any given time, with a fraction of those agents servicing a customer at any given time. Elastic search is a powerful tool because it can return a list of the best matches according to computed conditional and word similarity scores. It is very sophisticated and can perform multiple searches in parallel. In some embodiments, one method to speed up the search is to create multiple copies of the data (e.g., across different servers—called primary and “replica” servers)—a process called “sharding.”

When a call arrives, it moves into an entry point in the contact center102. The customer navigates IVR, and KVPs are attached to the call in the process. In some embodiments, Amazon Lex can be used to perform speech-to-text operations and generate call KVPs for each inbound call based on the associated customer's input. If the customer requests an agent, a call flow in Contact Center102invokes a REST API call in104to initiate the ES Lookup function124A (Lambda 1) to find one or more target skills in ES corresponding to the KVPs. Lambda 1 is responsible for querying ES using requests (e.g., posting an API call). The routing rules are stored in JSON format in120, where each JSON object represents a rule. Lambda 1 returns an ES document to the initiating call flow in102. In the case of the Amazon Connect contact center102, it further triggers the Agent Search124B function (Lambda 2). Lambda 2 is responsible for finding a match (e.g., the best match) by querying the agent skills database112for target skills and desired proficiencies across all agents. Lambda 2 also scans the agent status database114for all ready agents. If one or more suitable agents are available, Lambda 2 then selects the target agent based on certain pre-determined criteria, e.g., length of availability. Lambda 2 then sets the selected agent's status to busy. Connect then directs the call to the agent (or the target agent's queue). If no agent is available, Lambda 3 function124C then writes call attributes to the call attribute database110. The call treatment is then returned to Contact Center102, and the call is moved to the customer waiting queue.

When an agent enters into a “ready” state, Kinesis122detects the event and triggers the “Select Call” function124D (Lambda 4). Lambda 4 queries the call attribute database110to see if any calls are in the queue matching the newly available agent's skills. If there are one or more calls in queue, Lambda 4 targets the call that has been waiting the longest. Lambda 4 can also be programmed to read any “interaction priority” associated with the call, e.g., to ensure that higher priority calls are routed first. Lambda 4 then marks the call as “assigned” and changes the status of the agent to busy. Then, the Target Call function124E (Lambda 5) scans the call attribute database110to look for calls set to “assigned”. If it finds any, it moves the call to the targeted agent's queue.

The invention can also employ a principle called “target expansion.” The basic principle is that the institution would prefer to answer each customer's call as soon as possible even if it means sending the call to a less than desirable agent. In the above description, the Agent Search function124B (Lambda 2) can first search a skill level above an initial proficiency (e.g., greater than 8 out of 10). However, if after a certain predetermined time (e.g., 30 seconds) no agent has become available, the initial proficiency can be lowered (e.g., to greater than 3 out of 10), with the hope that more agents will now be available under the expanded search criteria. If more time passes (e.g., another 30 seconds) and no agents become available, the thresholds can be lowered even more, or removed entirely, with the goal of servicing the inbound call with an agent as soon as possible.

FIG. 2is a flow diagram of a computerized method200of routing calls (e.g., using the system100ofFIG. 1), according to an illustrative embodiment of the invention. In a first step202, a server computing device receives, from a contact center, a set of attributes (KVPs) for an incoming call. In a second step204, the server computing device searches, using an elastic search function and word matching criteria, an elastic search index to find a match (e.g., the best match) of the call attributes as compared with the attributes included in the elastic search index (e.g., contained in JSON documents). A conditional search may be used, which can include “must” and/or “should” match conditions applied to each attribute. In a third step206, the server computing device receives, with the elastic search function, from the elastic search database, a document (e.g., a JSON document) that meets (e.g., best meets) the word matching criteria for the set of attributes presented. This document includes the desired target skills, call treatment, and the target expansion rules. In a fourth step208, the server computing device searches an agent skills database, in electronic communication with the server computing device, to identify a set of agents having the skill and a suitable proficiency in the skill (e.g., as specified in the JSON document) returned from the elastic search function. In a fifth step210, the server computing device searches an agent status database to identify an agent status (e.g., ready or occupied). If one or more agents are identified, the server computing device: (i) selects a target agent based on length of availability (step212); (ii) sets a status of the target agent to busy (step214); and (iii) routes the call to the target agent (e.g., to a queue of the target agent) (step216). If no agents are identified, the server computing device (i) checks to see if any agents are staffed (step218); (ii) writes call attributes to the call attribute (or KVP) database (step220); (iii) returns call treatment to Connect (step222); and (iv) routes the call to a customer waiting queue (step224).

FIG. 3Ais an illustration of a JSON document310, according to an illustrative embodiment of the invention. The JSON document310includes several attributes, such as the DialedNumber (e.g., Orig_DN) corresponding to the phone number the customer dialed. The IVR-Prompt indicates that this caller selected one of the following options by voice or DTMF in the phone tree. The document includes a target rule and a treatment rule, as well as other data, which can be used for labeling the call or consumed for future processing by a call reporting system.

FIG. 3Bis an illustration of an agent skills and proficiency data segment320, according to an illustrative embodiment of the invention. The data segment320includes a list of skills and proficiencies for three agents identified as A123101, A123102 and A123103. In this example, the syntax for the skill is SkillName1:SkillProficiency1, SkillName2:SkillProficiency2, etc.

FIG. 3Cis an illustration of a rule segment component of the JSON document330, according to an illustrative embodiment of the invention. The rule segment component330includes a treatment rule, which in this case returns a specific prompt (291) to play while the customer is in the wait queue. The target rule returns the desired agent skill, and values associated with the initial agent proficiency and the incremental target expansion. In this example it is incremented by 2 from a start condition of 2 but is not to exceed 10, but other values and combinations of values are also possible.

FIG. 3Dis an illustration of a search query340, according to an illustrative embodiment of the invention. The search query340includes conditional search statements that “must” or “should” match the call attributes. All “must” statements must be identical matches. “Should” statements are not necessary to match, but will trigger the Lucene word matching algorithm that will factor into the elastic search score.

FIGS. 4-7show steps that can be executed on the system shown inFIG. 1together with additional sequencing details that may be understood in this alternative visual representation. Steps are denoted with encircled numbers or letters denoting the steps (e.g., step1is denoted with the number “1” inside a circle, and so on).FIG. 4is a flow diagram of a computerized method400of routing calls, according to an illustrative embodiment of the invention. In step1, a customer call is received by a contact center system (e.g., Amazon Connect) and moves to a Call Flow entry point. In step2, the call flow function of Connect invokes a lambda function “ES Lookup” (e.g., comparable to Lambda 1 function124A). In step3, the ES Lookup lambda function queries ES to look for routing rules based on the call's KVPs (which include, e.g., the dialed number, IVR prompt selected, etc.). In step4, ES returns the skills, desired skill proficiency required to handle the call, and the target expansion rule. The ES Lookup lambda function returns the output to the call flow as call attributes. In step5, the call flow function invokes a “Select Agent” lambda function (e.g., comparable to Lambda 2 function124B) and passes those target skills and proficiencies as input. In step6, the Select Agent lambda function scans the agent skill database to return all the agents trained for that skill with the required skill proficiency. In step7, the Select Agent lambda function scans the agent status database to check for the agents' availability. In step8, upon receiving an available agent, the lambda function returns a single target agent's details to the call flow function. In step9, the call flow function transfers the call to the target agent (e.g., places the call in the target agent's queue). If the Select Agent lambda function does not retrieve any available agent, the steps inFIG. 5can be utilized.

FIG. 5is a flow diagram of a computerized method500of target expansion for selecting an available customer agent, according to an illustrative embodiment of the invention. If the Select Agent lambda function does not retrieve any available agents, it can wait for a predetermined time interval (e.g., 30 seconds, during which call treatment music is played for the customer) and then perform a “target expansion” with respect to the agents required for the call (e.g., by adjusting the target proficiency for one or more required skills for servicing that call). In step1, the call flow function invokes the Select Agent lambda function after a predetermined time interval (e.g., 30 seconds) and passes the desired skills and proficiencies to the Select Agent lambda function. In step2, the Select Agent lambda function scans the agent skill database to obtain all the agents trained for that skill with the required skill proficiency. In step3, the Select Agent lambda function scans the agent status database to check for the agents' availability. In step4, upon targeting an available agent, it returns the agent's details to the call flow. In step5, the call flow transfers the call to the available agent.

FIG. 6is a flow diagram of a computerized method600of routing a call to a waiting queue if a target expansion process returns no available customer agent, according to an illustrative embodiment of the invention. If the Select Agent lambda function does not target an available agent even after the target expansion is performed, the call will be transferred to a waiting queue after writing the call details in the call attribute (KVP) database, e.g., using the storekvp function (e.g., comparable to Lambda 3 function124C). Here the call details are contact ID (unique for each and every call), time stamp, and target agent skill and proficiency.

FIG. 7is a flow diagram of a computerized method700of matching a newly available agent with a target customer call, according to an illustrative embodiment of the invention. When an agent comes online, the “Select Call” lambda function (e.g., comparable to Lambda 4 function124D) is triggered via the Kinesis data stream, which then scans the call attribute (KVP) database to take the call that matches the agent's skill and proficiency level. If it successfully finds a call that matches the agent's skill and proficiency level, then the Select Call lambda function sets an attribute in the Call Attribute database to set the call to “assigned.” In step1, call flow invokes the “Target Call” lambda function (e.g., comparable to Lambda 5 function124E) periodically (e.g., every 5 seconds). In step2, the target call lambda function queries the call attribute (KVP) database to determine whether or not an agent is assigned to the call. In step3, if an agent is assigned, it returns the agent details to the call flow. (If it does not find any agent assigned, the call continues waiting in the queue.) In step4, the call flow transfers the call to that agent.

FIG. 8is a flow diagram of another computerized method800of routing calls, according to an illustrative embodiment of the invention. In step1, a call placed by a customer is received by the contact center system (e.g., Amazon Connect). In some embodiments, the customer is asked to enter his or her advisor's phone extension or remain on the line for the next available agent. If the customer's advisor is unavailable, the customer can be given an option to leave a voicemail message. In step2, if the customer stays on the line, the customer is asked to provide customer input (e.g., to state the purpose of the call). A speech-to-text computing module (e.g., Amazon Lex) performs speech-to-text recognition on the customer's speech to determine the intent of the call. The call intent and the dialed number can constitute the KVPs of the incoming call. In step3, a call flow function (e.g., the call flow function of Amazon Connect) invokes a lambda function (e.g., “ES Lookup”). The ES Lookup lambda function queries ES to look for a skill and/or skill level based on the incoming call's KVPs. ES then returns the skill and skill level (and target expansion, if any) required to handle the call, which are then returned to Contact Flow as call attributes. In step4, Contact Flow invokes a “select agent” lambda function and scans the Agent Config database to search for an available agent who has the required skill and skill level. The Agent Config database returns the output agent information to Contact Flow. In step5, Contact Flow checks for the output returned. If Contact Flow obtains information for a suitable agent, it transfers the call to that agent (e.g., the agent shown). If Contact Flow does not obtain information for a suitable agent, it outputs a null value, writes the call KVPs and attributes in the call attribute database and transfers the call to a waiting queue. In some embodiments, the call KVPs and attributes refer to the contactID (unique identifier of the caller), skill, skill level, target expansion, call queue time, and/or call priority.

FIG. 9is a flow diagram of another computerized method of (i) matching a newly available customer agent with a target customer call, and (ii) target expansion for selecting an available customer agent, according to an illustrative embodiment of the invention. In step A, the live data streaming function (e.g., Amazon Kinesis) detects any changes in the status of each available agent (e.g., then agent shown). When the agent becomes available, the live data streaming function invokes a selectCall lambda function. Here, the selectCall lambda function provides event source mapping of the live data stream. In step B, the selectCall lambda function scans the call attribute database to look for the call with the highest priority and waiting time and matches its call attributes (e.g., skill, skill level, and/or target expansion skills) with the agent's skill and skill level. If there is a match, the selectCall lambda function updates the agent information in the call attribute database and changes the agent's status to “busy.” In some embodiments built in Genesys, the Genesys workflows are pointed to call the Rest API with incoming call KVPs as a request body. The REST API is a front end to a lambda function, which receives the input, forms an ES query and returns the output to Genesys. In this case, the output is the set of KVPs that is required to handle the call. Genesys makes use of those returned KVPs to transfer the call to an agent with the required skill and skill level.

FIG. 9also shows an event flow for target expansion for selecting an available customer agent and customer treatment (e.g., in steps1-3). In step1, the customer is treated in a waiting queue by a set of prompt files and treatment music. In step2, the customer queue flow invokes a Target Call lambda function at a periodic interval (e.g., every five seconds). This lambda function queries the call attribute database to look for the agent assignment for the call. In some embodiments, the call attribute database is scanned as soon as an agent becomes available, and the agent information is updated if the agent has the required skill and skill level. The input provided for the query can be a contactID. In step3, the customer queue flow checks for the output returned. If it receives the agent information, it transfers the call to the associated agent (e.g., the agent shown). An output with a null value makes the customer wait further.

FIG. 10is a flow diagram1000of another computerized method of routing a call, according to an illustrative embodiment of the invention. In one example implementation, ES routing was deployed in investment center branches in Amazon Connect non-production in a structure having approximately 200 US-based branches with an average of 16 agents per branch. In this setup, each branch has its own unique toll free number, and each branch agent has a unique 5-digit phone extension. Calls that are not answered by agents in the branch within three minutes are routed to a regional contact center that is staffed 24×7. Calls for Lex intents that mapped to service calls are routed directly to the regional contact centers.

For an incoming call, the “customer input” in the contact flow block asks to enter an agent extension or press # (pound). If the customer dials the agent extension, the call goes to the branch agent. Pressing #keeps the customer in the flow, and Amazon Lex asks for customer input (e.g., “Can you briefly tell us why you are calling today?”). Amazon Lex then performs speech-to-text conversion and generates intents based on the customer's response. Intents can be used, e.g., to decide whether the call should be routed to an investment center for resolution or should be transferred to a regional center. If the call is determined to be for an investment center, contact flow stores the dialed number as contact flow attributes.

Based on the stored dialed number, an ES Lookup lambda function queries ES to obtain the required set of rules that is needed for handling the call. The returned rules contains the time zone to check for working hours and holidays, call disconnect behavior, call treatment and target information. The contact flow executes a lambda function to check for holidays and then executes the “hours of operations” block for the returned time zone. If the call has come on a holiday or after hours, the call will be disconnected or routed to a different group (such as the regional contact center) based on the call disconnect behavior. If the call has come during the working hours, a Select Agent lambda function scans the agent config database to obtain an agent with the required skill and skill level. If it gets the agent, the call is transferred to that agent. If it does not get the agent, then the call is put in a waiting queue after writing the call attributes into the call attribute database.

FIG. 11Ashows an exemplary database entry1102in a call attribute database when the customer enters the waiting queue. Here, the required skill is “Skill B” and the required skill level is 10. When the agent becomes available, Kinesis invokes a selectCall lambda function. Here, the selectCall lambda function functions as the event source mapping of the Kinesis stream. The selectCall lambda function scans the call attribute database to look for the call with the highest priority and/or waiting time and matches its call attributes (e.g., skill, skill level, and/or target expansion skills) with the agent's skill and skill level. If there is a match, it updates the agent information in the call attribute database and changes the agent's status to “busy.” The customer queue flow looks for the agent assignment at a periodic interval (e.g., every five seconds), so if it notices the “agent_assigned” field in the call attribute database, it transfers the call to that agent. If the agent does not have the required skill and skill level, then the customer continues to wait in the waiting queue.

FIG. 11Bshows an exemplary database entry in a call attribute database when the agent becomes available and has the skill and skill level to handle the call. Here, the selectCall lambda function has assigned the call to AgentB since it has the required skill and skill level.

FIG. 11Cshows an exemplary database entry in a call attribute database when the status of AgentB is changed to Busy. As mentioned above with respect toFIG. 11B, because the call is assigned to AgentB, the status of AgentB changes to “Busy,” thereby preventing AgentB from being the target of subsequent routing decisions until the agent has completed the call (and thus had his or her status changed back to “Ready.”

In some embodiments, managing thousands of rules is a formidable challenge, and a user interface (UI) has been developed to manage the routing rules in a simple manner. A user can create, edit and delete the routing rules stored in Elasticsearch from the UI.FIG. 12is an exemplary segment of Elastic Search routing rules, according to an illustrative embodiment of the invention. The routing rules inFIG. 12relate to routing rules for branches that were loaded in to Elasticsearch. The branch routing rules package has different phases—6 OpenClosed, 2 Treatment, 2 Target Selection, and 5 Ixn Type rules. In some embodiments, an OpenClosed rule phase provides data which indicates whether the call has come during business hours or non-business hours. A Target Selection rule phase provides information about the skill and skill level required to handle the call. A Treatment rule phase provides information about the treatment music, duration etc. which needs to be played when a customer is in a waiting queue. An Ixn Type rule phase contains the mapping between the Dialed Number and the Branch Id (Ixn Type).

In some embodiments, each rule phase is a document in Elasticsearch. If a user wants to change anything in the rules stored in Elasticsearch, then they can change it in the UI either by editing the field or by importing data (e.g., an Excel sheet) with the new values. In both cases, the changes will be reflected into Elasticsearch.

As can be appreciated, the UI is built to view and manage the rules in the easiest and most user friendly manner.FIGS. 13A-13Bare diagrams of an exemplary architecture1300for managing routing rules via a UI, according to an illustrative embodiment of the invention. For example, the architecture1300follows an Active-Passive AWS service model, meaning that any changes made in the UI get reflected into the passive Elasticsearch index which will be in sync with the active Elasticsearch Index. The rules processing lambda function runs an automated rules testing and validation process (e.g., using various test cases) which validates any changes to the rules. Only after successful completion of the rules testing and validation process will the rules processing lambda function switch the index (with the updated rules) to the active Elasticsearch Index (seeFIG. 13B).

FIGS. 14A-14Dare screenshots of exemplary user interfaces for building and maintaining Elastic Search routing rules, according to an illustrative embodiment of the invention. As shown inFIGS. 14A-14D, a user can view, create, edit, update, and remove routing rules and their associated parameters to fully customize the routing ruleset.FIG. 14Aprovides a UI for viewing the rule schema,FIG. 14Bprovides a UI for adding fields to decision rules,FIG. 14Cprovides a UI for editing rules, andFIG. 14Dprovides a UI for viewing decision rules.

To provide for interaction with a user, the above described techniques can be implemented on a computing device in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, a mobile device display or screen, a holographic device and/or projector, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input.