An automatic call distributor (ACD) is a type of system for automatically handling incoming telephone calls. An ACD is designed to efficiently route calls, such as toll-free "800" calls, to agents in telemarketing and service inquiry centers and provides specialized real-time call management and report generation capabilities. An ACD is a unique communications product in that it directly supports the operation and management of a customer's business. The ACD monitors the status of each agent and, when an incoming call is received- selects the agent best able to handle a particular marketing or service request. The ACD also provides detailed reporting on the performance of the agents in their tasks, reporting such statistics as the number of calls handled and the time spent in various stages of call handling.

ACDs can have different application programs to handle calls in different ways, e.g., one application program to handle sales calls and a different application program to handle service calls.

Summary of the Invention In one aspect, the invention features in general automatically handling incoming telephone calls by a call discrimination subsystem that receives telephony information about the incoming telephone calls (e.g., number dialed, incoming line, number of caller) and assigns the incoming telephone call to one of a plurality of possible application programs to handle the call based upon the telephony information. At least one of the

application programs includes queries for obtaining further information about the incoming call (e.g. , in response to questions to the caller by a voice response unit or customer information on file) and thereafter the incoming call is returned to the subsystem to reassign the call based upon the original telephony information and the further information that was obtained.

In another aspect, the invention features, in general, automatically handling incoming telephone calls by comparing telephony information about the call with telephony digit patterns that have been input by a user and are associated with a respective application program. The digit patterns include patterns for plural fields corresponding to different types of telephony information. The call discrimination subsystem includes a translation module that translates the patterns into assignment logic for assigning the incoming calls. The translation module treats all patterns in the same field as logical OR operations and patterns in different fields as logical AND operations in creating the assignment logic. The assignment logic created by the translation module includes a global name table that lists a global application index (GAI) for each possible application program, a global-to-local application table (GLAT) for each field, and a field matrix (FM) for each field; the GLAT matches each GAI to local application indexes (LAI) that each identify a telephony pattern associated with an application program; the FM includes sets of pattern digit values along one axis and pattern digit positions along another axis and sets of LAI values at the intersections of digit values and digit positions.

In another aspect, the invention features in general selecting agents to handle incoming calls by maintaining a list of quantitative agent performance values that are continuously updated by a monitoring

system. E.g., the total sales made by each agent can be monitored so that the call can be first directed to the agent making the most sales. The system could also monitor the average time spent by each agent per call and direct the call to the agent having the lowest (or highest) average time values.

In another aspect, the invention features in general, selecting agents to handle incoming calls by maintaining a plurality of lists of quantitative selection values that correspond to different criteria for agent selection, and providing a means for the user to select which list, and thus which criterion, is employed in selecting agents. The criteria can include total sales made by each agent, an average time to handle each call by each agent, an agent performance rank assigned to each agent, and a waiting time list listing the amount of time each agent has been ready to receive a call.

In another aspect, the invention features in general automatically handling incoming calls by maintaining a list of quantitative agent selection values (not necessarily related to agent performance) and modifying the selection values based upon respective offset values assigned to the agents in order to obtain effective selection values for the agents. This gives the user flexibility in employing quantitative selection values, e.g., permitting the user to guarantee that a new agent is not receiving too many calls, even if he might be achieving high total sales or low times per call when selection values are based on one of these criteria. In another aspect, the invention features automatically handling incoming telephone calls by a system that selects one agent of a plurality of agents to receive the call and provides one command of a plurality of possible commands regarding the handling of the

incoming call depending upon which agent has been selected.

In preferred embodiments, the command can be a command to play a message to the caller, a command to communicate with an agent supervisor regarding the call, a command to obtain information from an external database and to send the information prior to connecting the incoming call, or a command to take some action after the agent has completed handling the incoming call and has been disconnected from the incoming call. The various commands can be entered by a user of the system using an interactive input device. The input device is adapted to input a list of agent pool identifiers and actions to be taken before connecting the incoming call to an agent in the indicated pool and actions to be taken after the incoming call has been disconnected from an agent in the indicated pool. The system translates the list into a list of pointers to instruction lists that provide the commands to cause the indicated actions. In another aspect, the invention features in general automatically handling incoming telephone calls by a system that counts the number of incoming calls (or the number of incoming calls that have reached a specified step in the call handling process) and handles a portion of the total number of calls by a different method than the remainder of the calls. E.g., an agent supervisor can be connected to listen to a conversation between an agent and a caller making an incoming call; alternatively, the agent supervisor can be selected as the agent to receive an incoming call in order to sample the types of incoming calls, or different messages can be played to different incoming callers to evaluate the effectiveness of the messages.

Other advantages and features of the invention will be apparent from the following description of the preferred embodiment thereof and from the claims.

Description of the Preferred Embodiment Fig. 1 is a block diagram of a system for automatically handling an incoming telephone call according to the invention.

Fig. 2 is a block diagram of the software architecture used in a call router of the Fig. 1 automatic call handling system.

Fig. 3 is a block diagram of the software architecture for a call center manager control console employed in the Fig. 1 system.

Figs. 4 and 5 are tables illustrating the use of quantitative agent selection values by an agent selection mechanism of the Fig. 2 call router.

Fig. 6 is a table presenting different agent ranking criteria that could be used in the agent selection mechanism depending upon the type of agent pool.

Fig. 7 is a diagram illustrating the effect of a before/after mechanism of the Fig. 2 call router on a display screen of an agent station.

Figs. 8 shows a fragment of a program containing before/after statements.

Fig. 9 shows a stack of pointers used to implement the Fig. 8 statements.

Fig. 10 is flow chart for executing the instructions indicated by the Fig. 9 stack of pointers.

Structure

Referring to Fig. 1, the various components of an automatic call handling system are shown. The call handling system distributes incoming calls from callers

12 to agent stations 14 that are connected to public telephone network 16. (In fact there would be a much larger number of both callers and agents.) The call handling system includes call router 18, call center manager module 20, agent supervisor station 22, host database 24, and voice response unit 25. These components and agent stations 14 are each connected to public telephone network 16 via a network service interface, which in the preferred embodiment is an integrated systems digital network (ISDN) interface.

Call router 18 is used to cause network 16 to connect an incoming call of a caller 12 to one of the agent stations 14. Call router 18 selects the agent station 14 to receive an incoming call based upon user-selected criteria, including dynamically changing information as to agent performance, which is monitored by the system. Call center manager console 20 provides an interface for the system manager to input information to configure the operation of system (as is described in detail below) and to monitor the operation of the system. Agent supervisor station 22 is used to monitor the performance of agents by an agent supervisor. Host database 24 and external database 25 include business databases (e.g., order entry, customer information, service schedules) which are accessed by call router 18. The hardware platforms employed in the components of the call handling system and various control algorithms are as described in U.S. Serial No. 07/441,945, filed on November 27, 1989, which is hereby incorporated by reference. Referring to Fig. 2, software architecture for call router 18 is shown. Network communications interface 26 is connected to a plurality of incoming telephone lines 28 via a communications driver layer (not shown in Fig. 2) . Network communications interface 26 feeds event handler 22, which tracks the system state as

seen by call router 18 and filters incoming events to notify appropriate subprocessors. Event handler 30 feeds actions to state manager 32 and queries to routing interpreter 34 and receives actions from routing interpreter 34.

Three important subsystems of call router 18 are call discriminator 38 (used to determine which application program is to be used) , agent selector mechanism 36 (used to select which agent should receive a call) , and before/after mechanism 42 (used to control actions before and after connection of an incoming call to an agent) . Call discriminator 38 receives queries from routing interpreter 34 and accesses call discriminator table 40. Agent selector mechanism 36 resides in state manager 32, and before/after mechanism 42 resides in routing interpreter 34, which accesses routing tables 37. The operation of call discriminator 38 and before/after mechanism 42 are user configurable by the system manager at call center manager console 20. The operation of agent selector mechanism 36 is user configurable by the system manager at call center manager console 20 or an agent supervisor at agent supervisor station 24.

Referring to Fig. 3, call center manager console 20 includes interactive user interface 44 (e.g., a CRT and keyboard) , which is used by the operator to enter information necessary to program the call discrimination, agent selection and before/after functions implemented by call router 18. The information is entered employing high-level, simplified languages, and translator modules 46, 48, 50 are adapted to convert the entries in the high-level languages into machine readable entries. In particular, call discriminator translator module 46 includes algorithms to convert telephony digit patterns, described in more detail below, into call discriminator

table 40. Agent selector mechanism module 48 includes algorithms to convert value and offsets for quantitative agent selection criteria into a format used by agent selector mechanism 36. Agent selector module 48 can also reside in agent supervisor station 22, permitting the agent supervisor to control the agent selection criteria and offsets. Routing language module 50 includes algorithms to convert lists of before/after clauses (indicating actions to be taken before connecting a call to an agent and after the call has been completed) into pointers to instructions in routing tables 37. Console 20 also includes communications interface 52 for sending the outputs of modules 46, 48, 50 over public telephone network 16 to call router 18.

Operation

The general operation of call handling system will be described first, and then the user configuration and operation of the call discrimination, agent selection and before/after subsystems will be described in turn in detail. When an incoming call is received by call router 18, a call record is established in memory in call router 18 to store data about the call that can be accessed by and added to by various processes in call router 18. In the initial stage of routing, routing interpreter 34 calls call discriminator 38 to determine which application program (e.g., sales or service or a particular sales or service application program) within routing interpreter 34 should be employed to handle the call. The selected application program is then used to continue processing, which generally includes identification of an agent pool or pools from which an agent can be selected to handle the call and adding entries identifying the pool and specifying actions to be taken during continued handling of the call to the call

record. State manager 32 then adds the call to the queue for an agent pool, employing agent selector mechanism 36 to choose between available agents. When an available agent has been selected, the selected agent identification is added to the call record. Event handler 30 then takes the actions indicated in the call record, generally including transferring the incoming call to the selected agent by instructing network 16 to transfer the call to the selected agent station 14. Information regarding the calls and the status of agents is continuously transferred between call router 18 and agent stations 14 and other components of the call handling system over the X.25 network.

Call Discrimination Subsystem Call discriminator 38 accesses telephony information about an incoming telephone call (e.g., number dialed, incoming line, number of caller) in the call record and assigns the incoming telephone call to one of a plurality of possible application programs to handle the call based upon the telephony information. In assigning an application program, call discriminator 38 compares the telephony information associated with an incoming call with the digit patterns of telephony data associated with the various application programs in call discriminator table 40.

Call discriminator table 40 is created by information entered by the system manager into interactive input device 44 of call center manager console 20. Console 20 employs a simple programming language that hides logical operations from the system manager. Call discriminator translator module 46 in console 20 converts a user program written in simple language into machine-readable call discriminator table 40.

The system manager enters application selection information in the form of digit patterns for various fields of telephony information that are associated with application programs. The following fields are used in the preferred embodiment, but the system is expandable to any number of fields.

BRI: Basic Rate Interface is the number of the line 28 on which the call arrived.

DNIS: Dialed Number Identification Service identifies the telephone number dialed by the caller to reach the incoming line. It is used when the same incoming line has more than one telephone number and is a service of the telephone carrier.

CLID: Calling Line Identification identifies the telephone number from which the caller is placing the call. Its delivery is a service of the telephone carrier, and may be received when the call arrives, or requested while the call is in progress.

DIALED: The dialed field contains digits dialed by the caller in response to voice prompts after the call has been answered. It may also contain additional digits, such as a customer account number obtained by querying a customer database.

Each field name (BRI, DNIS, CLID, DIALED) is associated with a field table (FT) . The collection of all field tables is machine readable call discriminator table 40. An FT has two parts: a global to local application table (GLAT) and a field matrix (FM) . The GLAT is explained below. The FM has 11 columns (one for each digit 0, 1, 2 ... 9, and a special column for unspecified digits) . The FM has one row for each digit position in the field; for example, CLID has 10 digits and its FT has 10 rows, while DNIS has 4 digits, and its FT has only 4 rows. Each entry in the FM consists of the set of application programs which can have that digit

value (represented by the column) in that position (represented by the row) . These sets are generated automatically by call discriminator translator module 46, from the list of applications and digit patterns provided by the user. Typically, each of these sets has more than one element.

Translator module 46 includes grammar to translate any user program written in that grammar into machine readable call discriminator table 40. A name in brackets (<name>) denotes a placeholder for an arbitrary name, and a name not in brackets must be entered literally. The syntax for the grammar is

<application name> application

<list of initial attributes> pattern

BRI: <list of patterns>

DNIS: <list of patterns>

CLID: <list of patterns>

DIALED: <list of patterns> match

The list of initial attributes, which is optional, can specify a particular agent or a high or low priority when queuing before agent pools. Not all the fields (BRI, CLID, DNIS, DIALED) need to be entered, and they may appear in any order. Also, the patterns can include capital letters representing telephone digits (A-P, R- Y) ; e.g., 3xx USA 123x could be a valid pattern. A list of patterns is of the form

<combination of digits, letter x, spaces> \n <combination of digits, letter x, spaces> \n

\n stands for the new line character (carriage return) ; x stands for any digit 0, 1, 2 ... 9. Spaces in the pattern are ignored. The following is an example of a pattern list including ten digit telephone numbers: 617 466 xxxx

305 XXX xxx 415 XXX xxxx The first entry specifies all phone numbers in the 617 area code and 466 local exchange. The second and third entries include all phone numbers in the 305 and 415 area codes. Translator module 46 interprets each new line character as a logical OR operation, and each appearance of a field name as a logical AND operation. This is implemented by adding, for each pattern in a pattern list, a new local application index (for the corresponding field, and matched to the global application in which the pattern appears) . For each digit in the pattern, that local application index is added to the sets in the field matrix. An automated software tool, known in the art as "yacc", is employed to generate a C program used in translator module 46 from the grammar described above and fragments of C program code (not complete programs or subroutines) , according to established techniques in computer science, as described in, e.g., Aho, Sethi, Ullman, Compilers: Principles. Techniques and Tools, (Addison-Wesley, 1986) and Unix System V.3.2/386 Programmer's Guide, Volume, Chapter 6, AT&T, (1988) and as available in the Unix V.3.2/386 operating system. The output of yacc is a C program that translates the digit patterns input by the system manager

according to the grammar into an output language specified by the fragments of C code given to yacc; the output language here is call discriminator table 40. An example with two application programs is described here to illustrate the use of the call discrimination subsystem. The systems operator wishes to classify as sales calls all arriving calls that are received on lines 20-29, and which are dialed as either 800 USA 1234 or as 800 USA 2222. The operator also wishes to classify as service all calls that arrived on lines 10-30 and which were dialed as 800 USA 1230-1239. The patterns entered by the user at interactive input device 44 are shown below with line numbers in parentheses. (1) sales application

(2) pattern

(3) BRI: 2x

(4) DNIS: 2222

(5) 1234 (6) match

(7) service application

(8) pattern

(9) BRI: lx

(10) 2x (11) 30

(12) DNIS: 123x

(13) match

Translator module 46 reads this description and creates call discriminator table 40, creating and expanding as necessary the following tables as each line is read: global index to name table (which lists a global index for each named application program) , BRI table, and DNIS table. The BRI and DNIS tables each have a local to global translation table (which lists a local application

index for each digit pattern entered in a field) and a field matrix (as described above) .

line 1: global to name table: global name 0 sales

line 3: BRI table: local to global table: global local 0 0 field matrix: digit: 0 1 2 5.

{0} {0} {0} {0} {0} {0} {0}

line 4: DNIS table: local to global table global local

field matrix: digit: 0 1 2 5..

{0} {0} {0} {0}

line 5: DNIS table: local to global table global local 0 0 0 1 field matrix:

{1}

{1}

line 9: BRI table: local to global table global local 0 0 1 1 field matrix: digit: 0 1 2 3 4 5... {1} {0} {0,1} {0,1} {0,1} {0,1} {0,1} {0,1

line 10: BRI table: local to global table: global local

0 0 1 1

1 2 field matrix: digit: 0 1 2 3 4 5..,

{1} {0,2} {0,1,2} {0,1,2} {0,1,2} {0,1,2} {0,1,2} {0,1,2}

line 11: BRI table: local to global table: global local 0 0

1 1

1 2

1 3 field matrix: digit: 0 1 2 3 4 5..

{1} {0,2} {3} {0,1,2,3} {0,1,2} {0,1,2} {0,1,2} {0,1,2} {0,1,2}

line 12: DNIS table: local to global table: global local 0 0

0 1

1 2 field matrix: digit: 0 1 2 3 4 5...

{1,2} {0} {3} {0,1,2}

{0} {1,2} {2} {2} {0,2} {2} {1,2} {2}

After line 13 has been read, the translation is complete, and the final tables are: the global to name table from line 7, the BRI table from line 11, and the DNIS table from line 12. These tables are transmitted to call router 18 and stored as call discriminator table 40 for access by call discriminator 38.

When an incoming call needs to be assigned an application program, call discriminator 38 compares the telephony information associated with the incoming call with the digit patterns entered by the system manager for the candidate application programs. This is done by traversing call discriminator table 40 on a digit-by- digit basis for the telephony information, excluding an application program from the set of candidate application programs when the requirements for an associated field have not been met.

For example, assume a caller dials 800 USA 1230; the call arrives on line 25, and the call discriminator table 40 described above is used. The call's candidate set is set initially to all the application programs. Using global indices, this set is {0,1}. The call data are BRI: 25, DNIS: 1230.

First, the BRI table is traversed. The candidate set is translated to local applications, using the final BRI local to global table (after translating line 11 above), and becomes {0, 1, 2, 3}. The BRI digit at the first digit position is 2, and the candidate set is replaced by its intersection with the set in the first row (corresponding to first digit position) of the BRI field matrix, under digit 2, giving a new candidate set

{0,2} = {0,1,2,3} f {0,2}

(In this notation the new candidate set is to the left of the = sign; the old candidate set is the first entry to the right of the = sign, and the set in the field matrix is the second entry to the right.) The second BRI digit is 5, so the candidate set is intersected with the set in the second row under digit 5, and becomes

{0,2} = {0,2} f {0,1,2}

This ends the traversal of the BRI table; converting from local to global indices (using the final local to global table after translating line 11) , the candidate set becomes {0,1}. Thus, on the basis of BRI value alone, the application program may be either application 0, sales, or application 1, service.

Traversing the DNIS table, the candidate set is initially, in local indices (from the DNIS table after translating line 12), {0,1,2}. Traversing the DNIS digits 1230, the candidate set (in local indices) becomes successively.

{1,2} = {0,1,2} fl {1,2}

{1,2} = {1,2} fl {0,1,2}

{1,2} = {1,2} fl {1,2}

{2} = {1,2} fl {2}

Hence, the call belongs to local application 2, which translates to global application 1, service.

If more than one application program remains in the candidate set after traversing call router table 40, of the remaining application programs, the one that was entered last by the system manager is selected. If no application program remains, a default program is selected.

The candidate sets and sets in the field matrices are represented as bit patterns, and each element of the set is represented by a bit turned on in the set. The intersection of two sets is the logical AND of two bit patterns, an extremely fast machine operation, resulting in fast execution time for the call discrimination procedure. After an application program has been selected, routing interpreter 34 continues processing handling of the incoming call according to that application program. Call discriminator 38 can be recalled from an application program after more information has been obtained about the call. An application program that does not have the DIALED field may direct a call to voice response unit 25, which then asks the caller to enter digits in response to prompts and then returns control to call discriminator 38 to traverse field table 40 once again, this time with digits in the DIALED field, now permitting a match with an application program that has digit patterns for the DIALED field. No incoming call would ever be transferred directly to an application program having digit patterns for the DIALED field. An advantage of the invention is

that it allows a refinement of the call discrimination (separating calls on the basis of the dialed digits in the example above) by simply listing more applications and patterns, without the need for user programming in the call processing programs.

The call discrimination subsystem allows the system manager to specify digit patterns for the various fields in many combinations in order to make fine distinctions between different calls and to process the calls differently.

Agent Selector Mechanism

Agent selector mechanism 36 maintains lists of quantitative agent selection values that are used to select which agent of a plurality of available agents is to receive an incoming call. A plurality of quantitative values relating to different criteria are maintained for each agent. A criterion can be static or dynamic. An example of a static criterion is an agent rank assigned by an agent supervisor. Examples of dynamic criteria, which are updated automatically by the system, are:

- amount of time the agent has been ready to receive calls,

- total sales by the agent, and

- average time to handle a call. The static and dynamic values are maintained in associated fields in agent selector mechanism 36. The supervisor of an agent pool at agent supervisor station 24 or the system manager at console 20 selects which of the four fields (i.e., agent rank and the three dynamic fields just mentioned) will be used to rank agents. Each of these fields has an associated offset value for each agent that has been set statically by the agent supervisor. Every time the agent completes a call, or becomes ready, the dynamic fields are updated by state

manager 30. An effective selection value is calculated by subtracting the field offset from the current selected field value. As agents become ready, they are ordered in increasing effective field value, and a call queued for that agent pool is given to the ready agent at the head of the queue (highest effective value of the selected field) .

Fig. 4 shows field and offset values for four hypothetical agents A, B, C, D. The agent supervisor has assigned the quantitative ranks listed in the third row and an offset value of 500 for the total sales field for agent C and an offset of 2 for the calls per hour field for agent D. The field values for availability (i.e., the time that the agent has been waiting in the available state ready to receive a call) , total sales for a given period (e.g., that day), and calls per hour are continuously updated by state manager 32 as new information is made available to it. Which agent is selected to receive the next call depends upon which field has been selected by the agent supervisor, as is shown in Fig. 5. If the availability field is selected, agent C receives the first call, agent A the second call, and so on. If the sales field is selected, agent A receives the first call, agent B the second, and agent C the third, even though agent C has higher total sales, because agent C's offset gives it an effective value that is less than that of agent A and agent B.

If an agent supervisor wishes to give the next call to the agent with the highest sales, he sets all the offsets (for total sales) to 0 and selects total sales as the field. When introducing a trainee agent into such an agent pool, the supervisor would probably set the trainee agent's offset to a large positive value. The trainee agent will have a lower effective field value than a normal agent in the same pool with the same sales,

because the trainee agent has a non-zero offset. The number of calls the trainee agent is offered could be increased gradually by decrementing the offset gradually. Fig. 6 lists ranking criterion and offsets that could be selected depending upon whether the agents are in sales, service or support pools. The agent selector mechanism thus allows agents in an agent pool to be assigned calls based on a user defined criterion, permitting a supervisor to affect agent selection in a way that is designed to promote performance or meeting other call center objectives. The offset feature permits the supervisor to fine tune the system based upon the unique characteristics of the individual agents in the agent pool.

Before/After Mechanism

The before/after mechanism is used to specify actions to be taken before and after actual handling of a call by an agent. It is implemented as an integral part of routing interpreter 34 that is configured by the system manager using a simplified language. The mechanism is employed during running of an application program prior to agent selection to identify what actions are to be taken. Pointers to lists of instructions for the actions are placed in the call record for a call at the time of assigning an agent pool, and the identified actions are then executed after the selection of an agent. The specified actions can be different for each agent pool before which the call is queued, and are triggered only if the call is transferred to an agent in the corresponding pool.

The before mechanism causes a list of user specified instructions to be executed just prior to transferring a call to an agent. The following is an example of a program fragment (written in the simplified

call processing language used at interface 44) that implements the before mechanism: AddAgentPool SALES1 before

DumpCallData; SupervisorMonitor; done; AddAgentPool SALES2 before

ChangeAgentScreen; done; It has the following effect: an incoming call is queued before the SALES1 and the SALES2 agent pools. If an agent in SALES1 becomes ready to take the call, first, the call data are delivered to a host database (the DumpCallData statement); second, the agent's supervisor is directed to monitor the agent (SupervisorMonitor statement) , and, third, the call is connected to the agent in SALES1. However, if it is an agent in SALES2 that becomes ready to take the call then, first, the agent's screen is changed, and, second, the call is connected to the agent.

The after mechanism causes a list of user specified instructions to be executed after a call has been released by the agent. The following is an example of a program fragment that implements the after mechanism:

AddAgentPool SALES1 after

ChangeAgentScreen; done; AddAgentPool SALES2 after

SupervisorMonitor done;

It has the following effect: an incoming call is queued before the agent pools SALESl and SALES2. If the call is answered by an agent in SALESl, then, after the call has been released by the agent, the agent's screen is modified. If the call is answered by an agent in SALES2, then, after the call has been released by the agent, the agent is monitored by a supervisor.

Fig. 7 shows the effect that the before/after mechanism has on call handling as seen by the agent. The first screen shows the screen when an agent in the SALESl agent pool is ready for a call. After a call has been assigned to this agent and before it is actually transferred to him, the DumpCallData command of the before mechanism results in call information (e.g., from a customer file) appearing on the screen at that agent station 14. After the call has been released by the agent, the after mechanism executes the ChangeAgentScreen command, resulting in the last screen on Fig. 7, used, e.g., to enter follow-up information about a call before going into the ready state to take another call. The before/after mechanism thus permits the system manager to easily configure the system to automatically change the way that an agent station operates depending on what application program is employed and what pool of agents receives the call.

As is mentioned above, the before/after mechanism is implemented using a stack of pointers to instruction lists in routing table 37. The statement: AddAgentPool <name> before <listl> done after <list2> done, entered by the agent supervisor or system manager, is transformed into the stack:

pointer to start of <listl> top of stack connect to agent in <name> pointer to start of <list2> STOP bottom of stack

This stack is inserted into the call record for the incoming call, and is associated both with the call and the agent pool (identified by name) before which it is queued. If an agent in the pool becomes ready to take the call, the agent's identifier is inserted in the middle statement (connect to agent in <name>) , and the stack of instructions is executed, beginning at the top. When <listl> (the before list) has been executed, the next statement is connect to agent, which effects the transfer of the call to the agent. When the call is released (i.e., after the agent and caller have been disconnected from each other) , that statement is deemed to have been completed, and the rest of the stack (<list2>, the after list of statements) is executed. Figs. 8-10 show the before/after statements (Fig. 8) , the resulting stack of pointers (Fig. 9) to implement the statements, and a flow chart (Fig. 10) for executing the instructions indicated by the stack of pointers for before commands bl-bn and after commands al-an. This approach also allows nested before and after statements (before and after clauses in <listl>, <list2> which are implemented by normal stack operations) .

Some additional examples of actions that are user configurable employing the before mechanism are described below. In these examples, the call is queued, successively, before agent pools SALES 1 and SALES2. Comparable applications are possible using the after mechanism.

1) Allowing a supervisor group to monitor all the calls answered by a SALESl agent:

AddAgentPool SALESl before SupervisorMonitor; done;

AddAgentPool SALES2

2) Allowing a supervisor group to monitor 1% of all the calls answered by a SALESl agent;

AddAgentPool SALESl before sample 100 do SupervisorMonitor done; done; AddAgentPool SALES2

3) Playing an agent specific recording to the caller just before the call is answered by an agent in the pool: AddAgentPool SALESl before play SALES1_REC; done;

AddAgentPool SALES2; before play SALES2_REC; done;

4) Connecting any agent that answers a call to an external database, with customer information from the database appearing on the agent screen: AddAgentPool SALESl before

DumpCallData; done; AddAgentPool SALES2 before DumpCallData; done; Example 2 illustrates the ability of call router 18 to count the number of incoming calls and to handle a portion of the total number of calls by a different method than the remainder of the calls. In Example 2, for 1% of the incoming calls, the agent supervisor is connected to listen to a conversation between an agent and a caller. Alternatively, the agent supervisor could be selected as the agent to receive an incoming call in order to determine the types of incoming calls. Instead of counting all incoming calls, the call router could count calls that have reached a specified step in the call handling process, e.g., calls that have waited 45 seconds. The sample capability could also be used to play different messages to different incoming callers to evaluate the effectiveness of the messages.

Other Embodiments Other embodiments of the invention are within the scope of the following claims.

What is claimed is: