Technique for effectively processing and dynamically routing communication calls

[00002] The invention relates generally to a communications system and method, and in particular to a system and method for processing and controlling a flow of communication calls.

[00003] It is commonplace that large companies and information service providers set up call centers in different geographic areas to handle telephone inquiries from customers. After receiving one such customer call, a call center normally assigns the call to an appropriate service representative, operator and/or interactive voice response (IVR) unit therein to attend to the call. For example, a customer of an information service provider may call a designated number for information, and the call is then routed to a call center where an operator can provide the customer with the desired phone numbers and addresses of particular persons and establishments, directions, movie listings, restaurant recommendations, etc.

[00004] A call center sometimes may be deluged with telephone calls such that the operators cannot answer all calls immediately after the calls come in. In that case, the calls are queued in the call center and answered in accordance with an automatic call distribution (ACD) algorithm. As a result, a caller may experience a long wait time and feel frustrated. To reduce such a wait time, techniques have been developed to route call traffic to multiple call centers to balance the load among them. One such prior art technique requires that each call received by a call center be automatically forwarded to a central switch location where a routing server identifies the call center to which the call is routed. However, this technique may actually cause a delay in answering those calls which can otherwise be answered immediately by the receiving call center. This stems from the aforementioned requirement that each call without exception needs to be forwarded to the central switch location before it is routed to a call center to be answered.

[00005] Another prior art technique involves routing overflow calls in a call center to other call centers in a predetermined sequence. That is, overflow calls in call center A are always routed to call center B, overflow calls in call center B always to call center C, and so on and so forth. An incoming call to a call center becomes an overflow call when it is queued in the call center longer than a predetermined period. However, a major shortcoming of this technique is its inflexibility to route overflow calls in a call center to any available call center not next thereto in the sequence. For example, an overflow call in call center A would be routed to call center B even if call center B has insufficient capacity to handle the call while another call center has ample capacity to handle it.

[00006] Accordingly, there exists a need for a technique for effectively identifying overflow calls in a call center, and dynamically routing the overflow call traffic to other available call centers to handle the overflow calls.

[00007] In accordance with the invention, an incoming call to a call center is identified as an overflow call, which needs to be rerouted to an alternate call center, based on measures of conditions concerning the call center. Such measures include, e.g., the number of calls being queued in the call center to be answered, the number of operators in the call center attending to the calls, etc. Once an incoming call is designated an overflow call, an attempt to reserve a communication path for transporting the call out of the call center (the “overflow call center”) is made. If the attempt is successful, a request for rerouting the call to an alternate call center is issued to a remote call routing server. The latter keeps track of availability of each call center to receive an overflow call, and determines its availability based on, e.g., periodic measures of conditions concerning the call center. Of the identified available call centers, the server may further determine whether any identified call center is an appropriate alternate call center for the overflow call to maintain the quality of service (QOS) of the overflow call center. For example, calls from an overflow call center may not be transferrable to any alternate call center unless the alternate call center is within the same region as the overflow call center to take advantage of the local knowledge of the operators in the alternate call center. After the server identifies the appropriate alternate call center, it communicates rerouting information including an identity of the alternate call center to the overflow call center. In response to such information, the overflow call center transfers the overflow call to the alternate call center through the earlier reserved communication path.

[00008] In an alternative embodiment, before a call from a communication network is routed to any call center, a processor in the network queries the remote call routing server for an appropriate call center to which the call is routed, thereby avoiding an overflow condition in the receiving call center and rerouting the call.

[00009] In another embodiment, as a disaster recovery measure, a call originally directed to a call center which is out of commission is switched to another network where a processor queries the call routing server for an appropriate call center to which the call is transferred. Based on a response from the server, the call which otherwise goes unanswered is then routed to the appropriate call center to be answered.

[00020] The present invention is directed to a technique for processing and dynamically routing calls to call centers. In accordance with the invention, an incoming call to a call center may be identified as an “overflow call” based on measures of metrics pertaining to the call center. As soon as one such overflow call is identified, the call center may cause the overflow call to be rerouted to an alternate call center which can more readily answer the call. For efficiency reasons, the call center reserves in advance an outbound telecommunication channel through which the overflow call is to be transferred before it sends to a call routing server a request for rerouting the overflow call. In response, such a server identifies any alternate call center to which the overflow call is to be rerouted.

[00021] FIG. 1 illustrates an arrangement embodying the principles of the invention where call centers 102-1, 102-2, . . . 102-K receive customer calls from communication networks 104, where K represents a predetermined number greater than one. Networks 104 here generically include a public switched telephone network (PSTN), packet switched network (e.g., voice over Internet protocol (VoIP) based), wireless communication network, etc. In this illustrative embodiment, operators in call centers 102-1 through 102-K provide an information service where a calling customer may obtain from an operator the desired phone numbers and addresses of particular persons and establishments, directions, movie listings, restaurant recommendations, etc. It should be pointed out that the term “operator” here broadly encompasses entities that are capable of providing assistance in a telecommunication environment, including without limitation human operators, voice response/recognition capabilities, web-enabled operator services, and other electronic access. Illustratively, each of call centers 102-1 through 102-K is connected to call routing server 108 via wide area network 110, and/or an intranet, the Internet, etc. Server 108 responds to requests from the call centers for rerouting overflow calls in a call center to an alternate call center, in accordance with the invention.

[00022] FIG. 2 illustrates call center 102 generically representing one of call centers 102-1 through 102-K. Call center 102 includes switch 202 having T1 spans 204 for connection to voice response unit (VRU) 206, channel bank 208, and communications networks 104. Channel bank 208 is used to couple multiple operator telephones 210 to switch 202. The operators in call center 102 are further equipped with operator terminals 212, each of which includes a video display unit and a keyboard with an associated dialing pad. Operator terminals 212 are connected over data network 224 to database server 218. The latter provides, e.g., directory information, movie listings, restaurant recommendations, weather and traffic information, etc. Switch host computer 222 and VRU 206 are also connected to data network 224. By way of example, data network 224 includes a local area network (LAN) supplemented by a number of point-to-point data links, and connected to WAN 110.

[00023] Center 102 may receive an incoming call from communication networks 104 through a carrier switching center therein. It also places outgoing calls through one of networks 104 which may be different than that used for the incoming call. Switch 202 is conventional which includes digital signal processing circuitry providing the requisite conference capability, and DTMF and multi frequency (MF) tone generation/detection capabilities. In this illustrative embodiment, switch 202 supports digital T1 connectivity. The operation of switch 202 is governed by instructions stored in switch host computer 222.

[00024] VRU 206 is used to play the constant repeated parts of an operator's speech, namely, the various greetings and signoffs (or closings). VRU 206 is connected via data network 224 to switch host computer 222 and via one or more T1 spans to switch 202. At appropriate stages in a call progression, switch host computer 222 initiates a voice path connection between VRU 206 and switch 202 such that the user, or the user and the operator, are able to hear whatever pre-recorded speech is played on that connection by VRU 206. Computer 222 then instructs VRU 206, via data network 224, what type of message to play, and passes data parameters that enable VRU 206 to locate the message appropriate to the call state.

[00025] Each incoming call from a user is received by switch 202 in center 102 which connects it to an available operator's telephone. If no operator is available when a call is received, the call is queued. At the same time, switch host computer 222 in accordance with the invention determines whether the received call should be accorded an “overflow call” status based on measures of metrics pertaining to call center 102, which are registered in computer 222. If the call is identified as an overflow call, computer 222 further arranges to have the overflow call rerouted to an alternate call center for answering. In this example, the call metrics include, but not limited to, the following:

[00026] (1) Call Abandonment (CA) metric—this metric indicates the percentage of callers that have hung up after experiencing a set answer delay, e.g., 24 seconds in this instance. A relatively high CA metric value indicates that a relatively high percentage of calls received by call center 102 were abandoned by the callers because of a long answer delay. Thus, one may want to set a maximum limit on the CA metric value, say, 20%, to meet a certain quality of service (QOS) requirement. When the CA metric value exceeds the maximum limit, an incoming call received by the call center is very likely to be designated by computer 222 an overflow call.

[00027] (2) Calls in Queue (CIQ) metric—this metric measures the number of incoming calls waiting in the queue to be answered by receiving call center 102. The higher the CIQ metric value, the higher the likelihood that an incoming call would be designated an overflow call. The CIQ metric value may be weighted against the number of logged in or active operators in call center 102, indicated by metric value (5) below. This stems from the fact that the more (fewer) active operators in the call center, the more (fewer) calls in the queue they can manage to maintain the appropriate wait time. Thus, the CIQ metric value relative to the number of active operators may be more effective in determining whether an incoming call should be designated an overflow call.

[00028] (3) Direct Call Processing Time (DCPT) metric—this metric indicates the average duration of a call after the call is picked up by an operator in call center 102, thereby measuring the efficiency of the operators answering the incoming calls. The higher the DCPT metric value, the more likely that an incoming call is designated an overflow call. For example, a high DCPT value may be a minute or more.

[00029] (4) H metric—this metric measures the number of calls processed per hour by the operators in call center 102. The higher the H metric value, i.e., the larger the number of calls answered by the operators per hour, the less likely that an incoming call would be designated an overflow call. Like the CIQ metric, the H metric may be weighed against the number of active operators, indicated by metric value (5) below, as what constitutes a high H metric value depends on the number of active operators in call center 102.

[00030] (5) Logged in Operators (LIO) metric—this metric measures the number of operators who have logged in the system to answer calls in call center 102. As mentioned before, this metric may be considered in combination with other metrics such as the CIQ and H metrics.

[00031] (6) Longest Queue Time (LQT) metric—this metric measures the longest queue time for any incoming call waiting in the queue to be answered. Incoming calls would likely be designated overflow calls if the LQT metric value exceeds a predetermined threshold.

[00032] (7) Rerouted Inbound Calls in Progress (RICIP) metric—this metric measures the number of overflow calls being rerouted to call center 102 acting as an alternate call center. A high RICIP metric value indicates a high rate of acceptance of overflow calls in call center 102, and the call center is likely to not designate any incoming call an overflow call since the call volume is manageable.

[00033] (8) Rerouted Outbound Calls in Progress (RICIP) metric—this metric measures the number of overflow calls being rerouted from call center 102 to an alternate call center. If call center 102 is already rerouting many of its incoming calls, it is likely that call center 102 would need to continue to designate an incoming call an overflow call and reroute same.

[00034] (9) Outbound Channels Available for Rerouting (OCAFR) metric—this metric measures the number of channels or circuits available for transporting a call out of call center 102. The lower the OCAFR metric value, the less likely that call center 102 would designate an incoming call an overflow call since the overflow call requires an outbound channel for transferring it to an alternate call center, unless the call is routed out via a VoIP connection.

[00035] (10) Time Service Factor (TSF) metric—this metric measures the percentage of calls answered in call center 102 within a predetermined time limit, e.g., 24 seconds, to meet a QOS requirement. The higher the TSF metric value, the more likely that an incoming call would not be designated an overflow call.

[00036] In accordance with the invention, a call control routine stored in computer 222 is invoked each time when an incoming call to call center 102 is not answered immediately and thus placed in a queue. FIG. 3 illustrates such a call control routine, which is denoted 400. Instructed by routine 400, computer 222 at step 416 determines whether the incoming call should be designated an “overflow call.” For example, computer 222 checks whether the LQT metric measure at that time exceeds a first configurable threshold (e.g., 24 seconds), whether the CA metric measure in the current five minute window exceeds a second configurable threshold, whether the CIQ metric measure exceeds a third configurable threshold, whether the LIO metric measure does not exceed a fourth configurable threshold, and/or whether OCAFR metric measure does not exceed a fifth configurable threshold. If the result of one or more of these tests turns out to be negative, computer 222 designates the incoming call in the queue a non-overflow call. As a consequence, routine 400 comes to an end, and the incoming call remains in the queue. Otherwise, if the result of one or more of these tests turns out to be positive, computer 222 designates the incoming call in the queue as an overflow call. In addition, computer 222 at step 422 determines whether an outbound communication channel in T1 span 204 is available, in anticipation of using such an outbound channel to reroute the overflow call from call center 102 to an alternate call center. If no outbound channel is available, routine 400 again comes to an end, and the incoming call remains in the queue. Otherwise, if an outbound channel is available, computer 222 at step 425 reserves such an outbound channel. In addition, computer 222 at step 428 issues a request to call routing server 108 via WAN 110 for rerouting the overflow call to an alternate call center. If server 108 responds to the rerouting request with routing information including an identity of the alternate call center, computer 222 then causes switch 202 to reroute the overflow call to the identified call center through the reserved outbound channel. Otherwise, if server 108 denies the rerouting request, computer 222 causes the previously reserved outbound channel to be released for other uses.

[00037] It should be noted at this juncture that an incoming call may be accorded priority over other calls in queue to be answered by an operator. Such priority may be identified based on call set up signals, e.g., an automatic call identifier (ANI), received by switch 202 in establishing the incoming call. As is well known, the ANI indicates the telephone number of the caller, or the mobile directory number (MDN) if the caller is a mobile phone user. Computer 222 consults therein a priority table where selected callers' phone numbers having a priority status are indicated. For example, the priority may be specified in terms of a priority value P relative to a predetermined value for a medium priority. Specifically, the priority may be measured on a five point scale, and the predetermined value for the medium priority is 3. In accordance with this priority scheme, the calls in queue having a priority value P are answered ahead of medium priority calls in the proportion of P out of (P+3) times. Thus, relatively high priority calls with P=5 are answered ahead of medium priority calls 5 out of 8 times. On the other hand, relatively low priority calls with P=1 are answered ahead of medium priority calls 1 out of 4 times. In this instance, the default priority value of each incoming call is 3.

[00038] In accordance with an aspect of the invention, the denial by server 108 of a rerouting request may be accompanied by a request by server 108 for increasing or decreasing the priority of the overflow call. Accordingly, computer 222 causes the overflow call to be answered in server 102 in a shorter (longer) time in response to its increased (decreased) priority.

[00039] FIG. 4 illustrates call routing server 108, including interface 702 through which server 108 is connected to WAN 110, processor 708, and memory 706 which contain, among others, call routing routine 714 and look-up table 716. In this illustrative embodiment, each of call centers 102-1 through 102-K from time to time, e.g., periodically, sends to server 108 a set of metric measures concerning the call center. The set of metric measures include the measures of one or more of the aforementioned metrics, and additional metrics which may be important for deciding the availability of a call center to receive an overflow call. For example, one such additional metric is an Inbound Channels Available for Rerouting (ICAFR) metric, which measures the number of channels or circuits available for receiving a call in a call center. The lower the ICAFR metric value, the less likely that the call center would be designated an alternate call center since it requires an inbound channel in the alternate call center to receive an overflow call. After receiving from each call center a set of metric measures concerning the call center, processor 708 looks up table 716 to determine the availability of the call center to receive an overflow call. The availability statuses of the respective call centers are then stored in a status table, and are updated periodically in this instance.

[00040] For example, the call center availability determination may be achieved by checking the metric measures received from a call center against look-up table 716. Table 716 includes different combinations of metric measures corresponding to an availability status in which the center becomes a candidate for receiving an overflow call.

[00041] FIG. 5 illustrates a simple example of table 716 assuming that only two metrics are relevant in determining the availability status. Specifically, in this simple example only the CIQ metric and LIO metric are assumed relevant and used. As mentioned before, the CIQ metric measures the number of calls in queue, and the LIO metric measures the number of logged in or active operators attending to incoming calls in a call center. In table 716 of FIG. 5, the upper limits of the CIQ and LIO metric values are represented by T and R, respectively, where T and R are both integers greater than zero. Based on the received measure of LIO metric, r, and measure of CIQ metric, t, processor 708 looks up table 716 to determine an availability status. For example, if (r t)=(R 1), the corresponding status is indicated in entry 503 in table 716, which is a “Y,” i.e., an availability status. As another example, if (r t)=(1 T), the corresponding status is indicated in entry 507 in table 716, which is an “N,” i.e., an unavailability status.

[00042] It should be noted that table 716 is a collection of results from manipulating the metrics in accordance with an underlying program which is a function of those metrics. This program is run by processor 708, and is dynamically modified in response to observed statistics and call patterns (e.g., daytime versus nighttime, and weekdays versus weekends) and other factors to meet QOS requirements. As a result, the entries and the make up of table 716 change dynamically. It should also be noted that the metrics in the program may be weighted by respective weights. For example, the aforementioned modification may be achieved by manipulating the respective weights of the metrics. These weights may be varied from time to time to amplify or reduce the effects of the metrics.

[00043] Table 716 may also be expressed in the form of a matrix. For example, FIG. 6 illustrates such a matrix (denoted 610) containing the same information of the table of FIG. 5. As shown in FIG. 6, matrix 610 has TR rows and three columns, which incorporates different combinations of t values in column 615 and r values in column 617. For each combination of t and r appearing in a row, matrix 610 provides an indication of the corresponding unavailability status (indicated by “N”) or an availability status (indicated by “Y”) in the same row. For example, in row 631 where (r t)=(R 1), the corresponding status is “Y” as described before, and in row 635 where (r t)=(1 T), the corresponding status is “N” as described before. The matrix representation of table 310 is conducive to easy mathematical manipulation of metric values, especially when there are more than two metrics involved, which is the usual case. For consideration of each additional metric in determining an availability status, a column is added to matrix 610 containing different values of such an additional metric. Column 619 would then list the status indications corresponding to the resulting combinations. It should be noted that for some metric values, it may be more desirable to express them in terms of intervals and/or thresholds. For example, the DCPT metric values may be expressed in such intervals as 0 to 10 seconds, 11 to 20 seconds, 21 to 30 seconds, and over a 30 second threshold.

[00044] In another illustrative embodiment, business rules, as opposed to predefined code, are used to determine whether an overflow call should be rerouted or a call center is available to receive overflow calls. To that end, a well known business rule engine is employed, which may be of the type of Blaze Advisor software provided by Blaze Software, Inc., Mountain View, Calif. For example, by using one such business rule engine, the business rules may be expressed in a natural English-like language, which are easy for rule developers to write, and analysts to read and validate. The rules which would otherwise be hard-coded into procedural code are placed in a rulebase and can be devised and modified dynamically. The rules are translated into “software rules” which enable the rule processor (e.g., processor 708) to compile and execute.

[00045] Examples of business rules (expressed in English-like language) concerning rerouting an overflow call used in this illustrative embodiment are as follows:

• • [00046] (a) If longest wait time for a call>40 seconds in a call center, reroute overflow call from the call center;
  • [00047] (b) If the number of available operators<5 and longest wait time>20 seconds in a call center, reroute overflow call from the call center;
  • [00048] (c) If the number of operators>5 in a call center, the call center is available to receive overflow calls;
  • [00049] (d) If call is from XYZ carrier, do not reroute the call;
  • [00050] (e) If call center is being shut down, reroute all calls directed to the call center;
  • [00051] (f) If call is accorded relatively high priority (e.g., priority>3), do not reroute the call; and
  • [00052] (g) If caller's profile requires a Spanish speaking operator and call is rerouted, reroute the call to call centers in San Diego, Los Angeles or San Antonio.

[00053] It should be noted that rules (a) through (c) are devised based on aforementioned call center metric measures while (d) through (g) are instructions or exceptions apart from the metric measures.

[00054] FIG. 7 illustrates call routing routine 714 run by processor 708. When processor 708 at step 801 receives a request for rerouting an overflow call from a call center, say, call center 102, processor 708 at step 803 determines whether the overflow call should be rerouted based, e.g., on the aforementioned business rules. If it is determined that the overflow call should not be rerouted, processor 708 at step 805 returns a denial of the rerouting request to computer 222, and at the same time may request computer 222 to upgrade (or downgrade) the priority status of the overflow call so that it would be answered in a shorter (or longer) time in call center 102. Otherwise, processor 708 identifies from the status table any alternate call centers available to receive an overflow call, as indicated at step 806. If no alternate call center is identified, routine 714 returns to step 805. Otherwise, if one or more alternate call centers are identified, processor 708 at step 812 determines whether any one of the alternate call centers is appropriate to receive the overflow call. In this illustrative embodiment, given a call center having an overflow call to be rerouted, not every alternate call center is a suitable recipient of the call. For example, limitations may be imposed that overflow calls from certain call centers can only be answered by operators in those alternate call centers within the same region or state to take advantage of the local knowledge of such operators. In general, without limitation, when given a choice between alternate call centers, the closest alternate call center to the overflow call center is preferred.

[00055] If processor 708 at step 812 identifies an appropriate alternate call center, processor 708 returns to computer 222 rerouting information including an identity of the selected alternate call center, as indicated at step 815. Otherwise, if processor 708 identifies no appropriate alternate call center, routine 714 returns to step 805 described above.

[00056] FIG. 8 illustrates an arrangement for use in a second embodiment of the invention. In this embodiment, the routing of calls to call centers 102-1 through 102-K is orchestrated by network processor 907 in communication networks 104, with the help of call routing server 108. Specifically, when one such call to a call center at a predetermined telephone number is routed through switching facility 910, having learned the predetermined telephone number, facility 910 queries network processor 907 for an available call center to which the call is to be routed. In response, network processor 907 in turn queries call routing server 108 for such an available call center, e.g., via WAN 110. Server 108 then identifies any available call center to accommodate the call, in accordance with a routine similar to that of FIG. 8 although, here, server 108 is in communication with network processor 907, as opposed to a call controller in a call center. Once processor 907 receives from server 108 the routing information including an identity of the available call center, processor 907 communicates such information to facility 910 which then causes the call in question to be routed to the identified call center. This arrangement is particularly advantageous as the call center receiving the call should always be available to answer the call in the first instance, thereby avoiding the possible need of rerouting the call after it is received in a call center.

[00057] FIG. 9 illustrates another arrangement for use in a third embodiment of the invention. In this arrangement a call to a call center, say, center 1005, at a predetermined telephone number is normally routed by switching facility 1003 in first communication network 1002 to the call center, without regard for its availability in the first instance as in the arrangement of FIG. 1. However, in accordance with an aspect of the invention, disaster recovery measures are put in place here in case center 1005 is out of commission and the calls directed to center 1005 which would otherwise go unanswered are rerouted to alternate call centers. To that end, as soon as center 1005 is identified to be out of order, switching facility 1003 is programmed to switch each call otherwise directed to call center 1005 to switching facility 1009 in second communication network 1006. Facility 1009 is connected to network processor 1011 similar to above-described network processor 907. Like processor 907, processor 1011 queries call routing server 108 for an available call center to answer the call to call center 1005. Once processor 1011 receives from server 108 the routing information including an identity of the available call center, say, center 1007, processor 1011 communicates such information to facility 1009 which then causes the call in question to be routed to call center 1007 to be answered.

[00058] The foregoing merely illustrates the principles of the present invention. It will thus be appreciated that those skilled in the art will be able to devise numerous other arrangements which embody the principles of the invention and are thus within its spirit and scope.

[00059] For example, call center 102 and call routing server 108 are disclosed herein in a form in which various functions are performed by discrete functional blocks. However, any one or more of these functions could equally well be embodied in an arrangement in which the functions of any one or more of those blocks or, indeed, all of the functions thereof, are realized, for example, by one or more appropriately programmed processors.