Call routing control using call routing scripts

[0002] 1. Field of the Invention

[0003] The present invention relates generally to a technique for use in controlling the routing of calls in a communications system, and more specifically, to such a technique wherein call routing scripts are used in controlling call routing.

[0004] 2. Brief Description of Related Prior Art

[0005] Systems for routing calls through public and/or private communications networks are known in the art. Conventional automatic call distribution (ACD) systems route calls to agents in telemarketing and service inquiry centers, and provide limited real-time call management and reporting capabilities. A typical ACD system will monitor the status of the agent and, when an incoming call is received, selects the agent to handle a particular service request. Reporting and performance data from the agents are also generated by the ACD.

[0006] One particular type of scheme for distributing calls to agents is disclosed in Frauenthal et al., U.S. Pat. No. 4,737,983. According to Frauenthal et al., data representing the present call congestion of each of the ACD systems is accumulated in a data base. Using the data in the data base, the percentage of calls made to the ACD systems, as a group, is determined. The information is then used to generate call routing information. When a new call is made to the central office, the routing information is queried to determine which of the ACD systems is to receive the call, so as to balance the call traffic load across the ACD systems.

[0007] Another call distribution scheme is provided in Gechter et al., U.S. Pat. No. 5,036,535. This patent discloses a system for automatically distributing telephone calls placed over a network to one of a plurality of agent stations connected to the network via service interfaces, and providing status messages to the network. Gechter et al.'s disclosed system includes means for receiving the agent status messages and call arrival messages from the network, which means are connected via a network service interface to the network. Routing means responsive to the receiving means is provided for generating a routing signal provided to the network to connect the incoming call to an agent station through the network. In the system disclosed in Gechter et al., when an incoming call is made to the call router, it decides which agent station should receive the call, establishes a call with that agent station, and then transfers the original call onto the second call to connect the incoming caller directly to the agent station and then drops out of the connection (See, Gechter et al., column 11, lines 45-51).

[0008] Other prior art call routing and distribution techniques are disclosed in Andrews et al., U.S. Pat. No. 5,873,130, which is assigned to the assignee of the subject application. This patent discloses a communications system and method for automatically making telephone routing decisions with global authority based upon information gathered in real time from the entire communications system and global optimization criteria. The entirety of the disclosure of the Andrews et al. patent is incorporated herein by reference.

[0009] In conventional call processing systems, calls may be routed in accordance with call routing control scripts executed by the system. These scripts may comprise one or more call routing instructions that when executed by the system cause the system to route the call to a desired destination; such destinations are commonly called “labels.” A “label” may be a particular destination telephone number, trunk group, or dialed number identification service (“DNIS”) number.

[0010] Heretofore, such labels have been expressly recited in the scripts' instructions. That is, heretofore, the labels have been expressed in the scripts as specific constant numerical values corresponding to e.g., particular destination telephone numbers, trunk groups, and/or DNIS numbers. Unfortunately, this makes modification of the labels in the scripts difficult, as such modification may require e.g., line-by-line searching and replacement of code in the scripts (i.e., to change the values of the labels), and also makes less modular the script code. As a result, a significant burden may be placed upon script programmers in terms of script coding and debugging time, effort, and frustration. Additionally, the use of constant value labels in the scripts decrease adaptability and flexibility of the scripts for use in other call routing applications.

[0011] In accordance with the present invention, a technique is provided for use in controlling the routing of calls in a communications system that overcomes the aforesaid and other disadvantages of the prior art. In one embodiment of the technique of the present invention, a call routing script is generated that includes at least one call routing instruction of a predetermined type that references a variable. The value of the variable is determined by the system when the system executes the script (i.e., at script run-time), and a call is routed to a desired destination based upon the value of the variable computed by the system at run-time.

[0012] The at least one instruction of predetermined type may contain a variable expression whose value may be computed at script run-time by the system for use by the system in determining a desired call destination. When computed, the variable expression's value may specify a destination telephone number, trunk group, and/or DNIS number to which the call is to be routed by the system.

[0013] The system may include a user-modifiable database in which a plurality of different respective variables that may be referenced by the call routing instruction may be stored in association with their respective values. The execution by the system of the call routing instruction may cause the system to retrieve the respective value of the variable referenced by the instruction from the database and to perform call routing based upon this value.

[0014] Advantageously, the technique of the present invention may be used to replace a constant-value label in a call routing script with a variable or variable expression whose respective value may be computed at script run-time based upon a value in a database external to the script. By simply modifying the value in the database, the value utilized in the script at run time to determine call destination also may be modified. Advantageously, this makes modification, testing, and debugging of call routing control scripts in accordance with the present invention much easier and less time consuming than in the prior art, and increases the adaptation flexibility of scripts according to the present invention.

[0015] It will be appreciated by those skilled in the art that although the following Detailed Description will proceed with reference being made to illustrative embodiments and methods of use, the present invention is not intended to be limited to these embodiments and methods of use. Rather, the present invention is of broad scope and is intended to be limited as only set forth in the accompanying claims.

[0016] Other features and advantages of the present invention will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and wherein:

[0017] FIG. 1 is a functional block diagram of one embodiment of a communications system wherein the technique of the present invention may be practiced to advantage.

[0018] FIG. 2 is a functional block diagram of the primary central controller of the system of FIG. 1.

[0019] FIG. 3 is a functional block diagram of an agent system of the system of FIG. 1.

[0020] FIG. 4 is a functional block diagram of an administrative workstation used in the system of FIG. 1.

[0021] FIG. 5 is a schematic block diagram illustrating data structures in the database shown in FIG. 4.

[0022] FIG. 6 is a schematic diagram illustrating contents of a call routing control script that may be stored and used in the system of FIG. 1.

[0023] FIG. 7 is a schematic diagram illustrating the structure and contents of the variable resolution table shown in FIG. 5.

[0024] FIG. 1 is an architectural-level block diagram illustrating functional components of a communications system 10 wherein one embodiment of the technique of the present invention may be practiced. System 10 includes a plurality of agent systems 24, 26, 28 connected to a primary central controller 30 and a plurality of conventional public telephone and/or long distance carrier networks (e.g., MCI, Sprint, AT&T) 12, 14, 16. Callers 18, 20, 22 place calls to the agent systems 24, 26, 28 via public networks 12, 14, 16. As will be explained more fully below, primary central controller 30 generates control signals for controlling routing and distribution of calls through the long distance carriers to and from the agent systems, and through the agent systems themselves to and from individual workgroups, customer agents and/or caller services, based upon requested service data (e.g., telephone numbers and other information) supplied by callers through the public networks, status messages (i.e., availability of resources for use by callers, loading of system resources, etc.) supplied by the agent systems, and user-generated call routing control scripts) stored in controller 30. Administration workstation 32 permits user access and control of the system 10 by, for example, permitting generation and modification of system configuration data, call routing scripts, etc. stored in controller 30. Monitoring and diagnostic mechanism 31 monitors the various elements of the system (i.e., the agent systems 24, 26, 28, administration means 32, etc.) to determine whether these elements are functioning properly. If a malfunction is detected, that fact is signaled to the central controller 30, so that it can undertake appropriate action to correct and/or eliminate the malfunction and/or any resulting problems to the system 10 from the malfunction.

[0025] Although not shown in the Figures, each of the conventional long distance carriers 12, 14, 16 includes a long distance control network (e.g., AT&T's Signaling System 7 (SS7) control network, MCI's TCP/IP-based control network, Sprint's X.25-based control network and/or foreign telecommunication's CCITT SS7-based control network) and local exchange carriers. The long distance control networks control routing of calls through the long distance network serviced by the exchange carriers. When a long distance call request is received. (e.g., a caller dials a long distance telephone number) by the exchange carrier, it forwards the call to the long distance network, which routes the call to its intended destination. In system 10, when the long distance control network receives a request for long distance connection to one of the agent systems 24, 26, 28 (or, as will be explained more fully below, to one of the agent systems' workgroups or caller services), the long distance control network forwards the long distance routing request to the central controller 30. As will be described more fully below, central controller then processes the request and controls the system 10 to route the call to a destination in accordance with call routing control scripts executed by the controller 30. The system 10 accomplishes call routing by, inter alia, translating the routing request message into a route response message for addressing the desired destination. System 10 also supports routing of calls across local exchange carriers and international PTT's by utilizing substantially the same call control and distribution techniques discussed above.

[0026] FIG. 2 is a schematic block diagram illustrating functional components of the central controller 30. Controller 30 includes interfaces 33 for receiving status messages and caller service requests, and for supplying control signals generating by the controller 30 to the public networks and the agent systems. Interfaces 33 include long distance carrier interfaces 38, 40, 42 for interfacing the controller 30 to the public networks 12, 14, 16, respectively. Each of the interfaces 38, 40, 42 is appropriately constructed to permit transmission of control signals and receipt of caller service requests from the respective network to which it is connected. For example, if carrier interface 42 is connected to an AT&T network, then it is appropriately constructed to permit transfer of control signals and service requests between the controller 30 and the SS7 network. Other types of carriers must also be similarly accommodated by appropriately constructing the other interfaces 40, 38 to permit exchange of such data between these networks and the controller 30.

[0027] Interfaces 33 also include agent gateways (i.e., interfaces) 34 for interfacing the controller 30 to the agent systems 24, 26, 28. Interfaces 34 include agent systems interfaces 46 connected to a conventional wide area network 44. Wide area network 44 connects the controller 30 to the interfaces 34 so as to permit transmission of status messages from the agent systems to the controller 30, and to permit transmission of control signals to the agent systems 24, 26, 28. It should be understood that the particular types of interfaces 46 used will depend upon the particular constructions of the agent systems, the wide area network, and the controller. Wide area network 44 may be a conventional TCP/IP (Transmission Control Protocol/Internet Protocol) network, although alternatively, network 44 may be constructed to use other types of network protocols.

[0028] Control signal generator 36 is connected to the interfaces 33, monitoring mechanism 31, and administrative workstation 32. Control signal generator 36 comprises routing engine 48, database logger/retrieving engine 50, database manager 52, and database 54. Routing engine 48 determines how to route calls in the system 10 (i.e., through the public networks to the agent systems, and in the agent systems themselves), and transmits this routing information (in the form of appropriate control signals, such as routing response messages) for addressing the desired end-termination (e.g., a workgroup/caller service in the system) to interfaces 33, 34 for transmission to the agent systems and long distance control networks, respectively. In order to determine how to route calls in the system, routing engine 48 takes into consideration real-time requested service data supplied to it by the interfaces 33, system configuration data 202 and historical (i.e., previously stored) requested service data and status messages 204 retrieved by logger/retriever 50 at the command of the routing engine 48 from the system's historical database (comprising database manager 52 and storage mechanism 54), real-time status messages from the agent systems supplied to it from the interfaces 34, information from the monitoring mechanism 31 concerning what components (if any) of the system are currently unavailable because they are malfunctioning or inoperative, and routing optimization criteria and/or rules and commands in the form of call routing control scripts 200 generated by the administration workstation and stored in database 54. Routine engine 48 uses this data to determine the manner in which to route calls in the system. After making its decision on how best to route a particular call, generating appropriate control signals to implement this decision, and transmitting the control signals to the interfaces 33 and 34, routing engine 48 instructs logging engine 50 to store the real-time information presented above in the database 54 for use in determining how to route later calls. Logging engine 50 in turn, commands database manager 50 to store this information in database 54. Scripts 200 may comprise corporate and/or customer-generated call routing scripts.

[0029] FIG. 3 is a functional block diagram of an agent system 26. Agent system 26 may comprise wide area network interface 72 for interfacing the agent system's local controller/router 70 to the controller's wide area network 44, so as to permit transfer of control signals from controller 30 to local controller 70 and status message from the local controller 70 to controller 30. In response to control signals received by local router 70 from controller 30, local router 70 issues commands to the ACD/IVR, or PBX system causing public network interfaces (not shown) in the ACD, PBX or IVR to connect calls received thereat from the public networks to appropriate caller services (e.g. interactive voice response system 74) or individual agents (e.g. private branch exchange (PBX) 56 or ACD 60). It should be noted that the particular type and number of caller services and individual agents shown in FIG. 3 are merely for illustrative purposes and may vary. Local router 70 issues commands via the conventional local network 58 to the caller service or individual agent system to which the call is connected, as to how the individual agent or caller service is to distribute or process the call. For example, depending upon the control signals transmitted by the controller 30 to controller 70, controller 70 may instruct the call to be forwarded directly to the interactive voice response system 74 which is connected as an answering resource to ACD 60, and instruct the interactive voice response system to store information from the call for later retrieval and transmission to a workstation (not shown) connected to the PBX 56, or to connect the call to the ACD 60 and instruct the ACD to forward the call to one of its workgroups 62, 64, 66. Of course, it will be appreciated that if appropriately modified, the network interfaces may be comprised within the public networks or may comprise a separate, stand-alone interfaces distinct from the agent systems. Likewise, if the PBX, IVR, and/or ACD are appropriately modified so as to include other of the various functional components of the agents (e.g. router 70), they may be eliminated, or comprised as separate functional components from the agent system.

[0030] Local controller 70 also queries the individual agents and caller services for status information (e.g. whether they are active or busy, what resources are available for use by callers, etc.), gathers this status information via the local network 58, and transmits this information to the central controller 30 via interface 72 for use in the central controller's routing decisions. In this way, the central controller 30 may automatically control routing of calls not only through the public networks, but also in the agent systems, according to status information gathered from the entire system, using the call routing scripts and global call distribution criteria.

[0031] Agent system 26 may also comprise local administration workstation 73 for permitting user control of the local router 70, and remote administration workstation 71 for permitting remote control of central controller 30. Both administration workstations 73, 71 are of similar construction to administration workstation 32. Local administration workstation 73 may be limited in its ability to control local router 70 (i.e., only to control matters not being controlled by central controller 30). Likewise, remote administration workstation 71 may be limited in its authority over system 10 such that administration workstation 32 may override commands issued by administration workstation 71.

[0032] FIG. 4 is a functional block diagram of administration workstation 32. Workstation 32 may comprise a user input/output interface 78 connected to central controller interface 76. User interface 78 may comprise a graphical user interface for permitting a human user 81 to generate, edit, and store call control routing scripts 200, system configuration data 202, etc. in the database 54 of the central controller 30. The database interface 76 is adapted to change the user's graphically input data into a form usable by the central controller in the central controller's database 54. Administration workstation 32 comprises a user-accessible database 75 for storing real-time information and configuration information and for permitting such information to be communicated to a human user via the user interface 78. Also, administration workstation 32 permits a user to monitor various system activities and current system information, such as, call routing, system configuration, etc.

[0033] The above-presented functional components (with the exception of networks 12, 14, and 16) of system 10 may be embodied as one or more distributed computer program processes executing in a plurality of computer nodes; each of these nodes may include computer-readable memory for storing software programs, algorithms, and data structures associated with, and for carrying out, the inventive techniques, and related and other techniques and methods described herein as being carried out by or implemented in system 10. In addition, each of these nodes may further include a processor (e.g., an Intel 80×86 processor) for executing these software programs and algorithms, and for manipulating the stored data structures, to enable the nodes to carry out these methods and techniques in system 10. Additionally, the nodes may be provisioned with such networking hardware and software (e.g., including computer networking and telephonic communications hardware and software) as is needed to enable performance of the stated functionality.

[0034] It should be noted that the functional components of the system 10 may vary depending upon particular functional and operational requirements. For example, the existing components of system 10 may be modified to incorporate the functionality of, or the system 10 may be modified to include, fault-tolerance-related functional components (e.g., a redundant central controller), components related to processing of Internet calls, and/or call-queuing-related components described in the aforesaid Andrews et al. patent (i.e., U.S. Pat. No. 5,873,130). Accordingly, it should be appreciated that the present invention may be practiced in systems other than system 10 (e.g., in systems having different and/or additional functional components like those described in the aforesaid Andrews et al. patent, and other communications systems).

[0035] In accordance with one embodiment of the technique of the present invention that may be practiced in system 10, user 80 may input via interface 78 call routing control scripts 200 which, after being inputted, may be stored in database 54. Interface 78 also permits the user 80 to input and store in database 54 a variable resolution table 206 (whose contents and purpose will be discussed below).

[0036] Each of the call routing control scripts 200 includes one or more call routing script instructions (collectively and/or singly referred to by numeral 302 shown in FIG. 6). In system 10, depending upon the particular script, these instructions 302 may comprise one or more special instructions (referred to collectively and/or singly by numeral 304 shown in FIG. 6) of a predetermined type. The instructions 302 in scripts 200 control the manner in which calls are routed in system 10 by routing engine 48. That is, the instructions 302 are retrieved by engine 48 from database 54 (via retriever 50 and database manager 52) and after being compiled into an executable form by engine 48, are executed by engine 48 to generate the control signals that are supplied by engine 48 to the interfaces 33, 34 to control routing and distribution of calls in the system 10, and also otherwise control the operation of the functional components of system 10.

[0037] Special instructions 304, in essence, constitute or comprise function calls that, when executed by the engine 48, cause control signals to be supplied to the functional components of system 10 that cause these components to route calls to desired labels. These function calls 304 contain (e.g., as function arguments) variables or variable expressions whose respective values are not determined by engine 48 prior to execution of the instructions 304, but instead, are determined by the engine 48 only when the instructions 304 are executed by the engine 48 (i.e., at run-time of the script 300 containing the instructions 304). Engine 48 determines the respective values of these variables, by examining, at run-time of the special instructions 304 containing the variables, the contents of table 206.

[0038] More specifically, in table 206, each of the variables (collectively referred to by numeral 401) that are permitted to be referenced or contained in the function calls 304 is associated with a respective value (collectively referred to by numeral 402) that engine 48 is to use at script run-time as being the respective value of that variable. For example, for purposes of illustration, if one assumes that one of the instructions 304 contains or references a variable 406, when that instruction is executed by the engine 48, the engine determines the value of that variable 406 to be the respective value 404 associated with variable 406 in table 206.

[0039] In this embodiment of the technique of the present invention, each of the values 402 associated with the variables 401 specifies a particular label (e.g., by being or comprising a destination telephone number, trunk group number, or DNIS number). When a particular instruction 304 is executed that contains or references such a variable (e.g., variable 406), the execution of that instruction 304 causes the engine 48 to provide the routing client(s) (e.g., the functional component or components in system 10 through which a particular call is to be routed to the call's desired destination) via the interfaces 33, 34 (and possibly the wide area network if necessary) control signals that cause the routing client(s) to route the call to the label specified by the value (e.g., value 404) associated with that variable 406. Alternatively, if the instruction 304 contains a variable expression, the engine 48 evaluates that expression to determine the particular label to which the call is to be routed. For example, the expression may be an index into an array (not shown) in the database 54 in which possible caller-entered digits (e.g., possible to be entered by a caller by interaction with, and in response to, prompts from IVR 74) are associated with values specifying a respective labels to which a call whose caller entered those digits is to be routed, or specifying multiple such labels (e.g., to permit routing client(s) to determine therefrom an optimal label to which to route the call). The variable expression is evaluated by the engine 48 at script run-time to be equal to the value(s) specifying such label(s) and the instruction 304, when executed, may cause the engine 48 to provide to the routing client(s) control signals that cause the routing client(s) to route the call to an optimal destination specified by the label(s).

[0040] Such variable expressions may be used to advantage e.g., in connection with script instructions for routing calls to alternate destinations when an initial desired destination is busy or unavailable. For example, the script instructions may cause a call to be routed to an IVR 74 if an initial agent destination is busy, the IVR 74 may supply caller-entered digits to the controller 30 (e.g., entered in response to IVR prompts concerning requested services to be provided to the caller), and the instructions may route the call to an alternate destination based upon such caller-entered digits in accordance with the process described above.

[0041] Thus, it is evident that there has been provided an inventive technique for call routing control based upon execution of call routing scripts that fully satisfies both the aims and objectives hereinbefore set forth. It will be appreciated that although specific embodiments and methods of use of the present invention have been presented, many modifications, alternatives and equivalents thereof will be apparent to those skilled in the art. Accordingly, the technique of the present invention should be viewed broadly as encompassing all such modifications, alternatives and equivalents, and as being defined only as set forth in the hereinafter appended claims.