CA2264464C - Prioritized transaction server allocation - Google Patents
Prioritized transaction server allocation Download PDFInfo
- Publication number
- CA2264464C CA2264464C CA002264464A CA2264464A CA2264464C CA 2264464 C CA2264464 C CA 2264464C CA 002264464 A CA002264464 A CA 002264464A CA 2264464 A CA2264464 A CA 2264464A CA 2264464 C CA2264464 C CA 2264464C
- Authority
- CA
- Canada
- Prior art keywords
- transaction
- server
- application
- service level
- transactions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
Abstract
A facility for distributing transaction servers to process transactions of a number of different types is provided. The transaction types are organized into two or more priority levels ordered from highest to lowest. Each priority level has one or more transaction types. In the facility, a service level goal attribution system attributes a service level goal to each transaction type reflecting the level of service sought for transactions of the transaction type. An identification subsystem identifies transaction servers when they become available to process transactions. In response to each transaction server identified by the identification subsystem, a transaction server distribution subsystem assigns the identified transaction server to process a transaction of a type that needs an additional transaction server to meet its service level goal, and whose priority level is at least as high as that of any other transaction types that need an additional transaction server to meet its service level goal. When the assigned transaction servers complete processing of the transactions to which they are assigned, the identification subsystem reidentifies these transaction servers as again being available to process transactions.
Description
t PRIORITIZED TRANSACTION SERVER ALLOCATION
S
TECHNICAL FIELD
The present invention relates generally to the field of allocating transaction server resources and, in particular, to allocating transaction servers in telephonic call centers.
BACKGROUND OF THE INVENTION
A ca.Il center is a facility for receiving and/or placing large volumes of telephone calls. The calls are received and placed by call servers, such as human agents or automatic response units. Such call centers typically include an automatic call distributor for assigning each incoming call to a call server. Call centers also typically include a predictive dialer for placing outgoing calls that., if answered, are each assigned to a call server.
In some call centers, agents are also assigned to non-call tasks, such as filling out forms, writing letters, or running credit checks. Call centers in which agents are also assigned to non-call tasks are also called service centers.
Assignment of these non-call tasks is generally accomplished manually or handled by a workflow system that is distinct from the automatic call distributor or predlictive dialer that assigns phone calls to agents.
Conventionally, the automatic call distributor, the predictive dialer, and the workflow system operate independently to assign calls and non-call tasks, respectively, to agents. To accommodate the independence between these two components, a call center supervisor generally mamia.lly divides agent resources between calls and non-call tasks in a static, predetermined manner. For example, a first group of agents may be dedicated to conducting calls, while a second, distinct group of agents is dedicated to performing non-call tasks. As another example, certain agents may be dedicated to conducting calls every morning, and dedicated to performing non-call tasks every afternoon.
Such call centers usually succeed in making a certain amount of progress in handling both calls and non-call tasks. Depending on the aptness of the manual division of agent resources and the particular pattern of calls and non-call tasks experienced, however, unacceptable levels of service are often obtained for either calls, non-call tasks, or both. In cases in which it is essential to ensure high levels of service, it is often necessary for call center supervisors to overstaff the pool of agents, at significant cost.
Based on these disadvantages of conventional call centers, which are shared by similar transaction processing systems of several other types, a facility for more effectively managing call server resources and other transaction server resources would have significant utility.
SUMMARY OF THE INVENTION
The present invention provides a facility for allocating transaction servers ("servers") in a transaction processing system in a manner that facilitates differentiation between transactions of different priorities and balancing the performance of transactions of the same priority. Within the constraints imposed by the availability of servers, the facility facilitates maintaining pre-defined service level goals.
For example, the facility may allocate telephone call processing servers, such as human operators/agents and automatic response units, for processing telephone calls.
The facility can also allocate servers to process virtually any other type of transaction, including, but not limited to, form processing; response to world wide web hits ("web hits"); letter, fax, or email generation or response; account adjustment; and various forms of network and Internet communication. The facility can allocate servers between several different types of transactions. Transactions may be initiated within the organization using the facility, by external customers or clients of the organization, or both.
In a preferred embodiment, the facility allocates servers among different applications each of which processes transactions of a different type or of the same type but with a different service level goal. For example, a first application may process incoming telephone call transactions for platinum credit card holders, a second application may process outgoing telephone call transactions for new credit card offers, and a third application may process credit check transactions, such as those received via the world wide web or in the mail, and a fourth application that responds to web hits with outgoing phone calls.
The facility preferably enables a service level goal to be specified for each application, indicating the level of performance sought in processing transactions of the application's type. Service level goals are generally each comprised of two components: a performance criterion specifying an amount of time by which some action relating to the transaction is to completed, and a minimum frequency indicating the percentage of transactions for which the criterion is to be satisfied. As an example, one service level goal may specify a criterion of assigning transaction within 15 seconds of their receipt, and a minimum frequency that indicates that 90% of the transactions are to be processed in accordance with the performance criterion. Performance criteria ("criteria") may be of various types, including transaction assignment criteria and transaction completion criteria. Transaction assignment criteria relate to the amount of time that it takes for a server to be assigned to transactions after they arrive. A
transaction assignment criterion may indicate, for example, that incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arnval. Transaction assignment criteria are particularly well adapted to transactions initiated outside the organization using a real-time medium, such as an incoming telephone call or web hit-especially those transactions initiated by a human client. Such transactions are regarded as "volatile," as they may be lost if not quickly assigned to a server. For example, if an incoming telephone call is not answered within a few seconds after it is initiated, the caller may hang up and end the call.
S
TECHNICAL FIELD
The present invention relates generally to the field of allocating transaction server resources and, in particular, to allocating transaction servers in telephonic call centers.
BACKGROUND OF THE INVENTION
A ca.Il center is a facility for receiving and/or placing large volumes of telephone calls. The calls are received and placed by call servers, such as human agents or automatic response units. Such call centers typically include an automatic call distributor for assigning each incoming call to a call server. Call centers also typically include a predictive dialer for placing outgoing calls that., if answered, are each assigned to a call server.
In some call centers, agents are also assigned to non-call tasks, such as filling out forms, writing letters, or running credit checks. Call centers in which agents are also assigned to non-call tasks are also called service centers.
Assignment of these non-call tasks is generally accomplished manually or handled by a workflow system that is distinct from the automatic call distributor or predlictive dialer that assigns phone calls to agents.
Conventionally, the automatic call distributor, the predictive dialer, and the workflow system operate independently to assign calls and non-call tasks, respectively, to agents. To accommodate the independence between these two components, a call center supervisor generally mamia.lly divides agent resources between calls and non-call tasks in a static, predetermined manner. For example, a first group of agents may be dedicated to conducting calls, while a second, distinct group of agents is dedicated to performing non-call tasks. As another example, certain agents may be dedicated to conducting calls every morning, and dedicated to performing non-call tasks every afternoon.
Such call centers usually succeed in making a certain amount of progress in handling both calls and non-call tasks. Depending on the aptness of the manual division of agent resources and the particular pattern of calls and non-call tasks experienced, however, unacceptable levels of service are often obtained for either calls, non-call tasks, or both. In cases in which it is essential to ensure high levels of service, it is often necessary for call center supervisors to overstaff the pool of agents, at significant cost.
Based on these disadvantages of conventional call centers, which are shared by similar transaction processing systems of several other types, a facility for more effectively managing call server resources and other transaction server resources would have significant utility.
SUMMARY OF THE INVENTION
The present invention provides a facility for allocating transaction servers ("servers") in a transaction processing system in a manner that facilitates differentiation between transactions of different priorities and balancing the performance of transactions of the same priority. Within the constraints imposed by the availability of servers, the facility facilitates maintaining pre-defined service level goals.
For example, the facility may allocate telephone call processing servers, such as human operators/agents and automatic response units, for processing telephone calls.
The facility can also allocate servers to process virtually any other type of transaction, including, but not limited to, form processing; response to world wide web hits ("web hits"); letter, fax, or email generation or response; account adjustment; and various forms of network and Internet communication. The facility can allocate servers between several different types of transactions. Transactions may be initiated within the organization using the facility, by external customers or clients of the organization, or both.
In a preferred embodiment, the facility allocates servers among different applications each of which processes transactions of a different type or of the same type but with a different service level goal. For example, a first application may process incoming telephone call transactions for platinum credit card holders, a second application may process outgoing telephone call transactions for new credit card offers, and a third application may process credit check transactions, such as those received via the world wide web or in the mail, and a fourth application that responds to web hits with outgoing phone calls.
The facility preferably enables a service level goal to be specified for each application, indicating the level of performance sought in processing transactions of the application's type. Service level goals are generally each comprised of two components: a performance criterion specifying an amount of time by which some action relating to the transaction is to completed, and a minimum frequency indicating the percentage of transactions for which the criterion is to be satisfied. As an example, one service level goal may specify a criterion of assigning transaction within 15 seconds of their receipt, and a minimum frequency that indicates that 90% of the transactions are to be processed in accordance with the performance criterion. Performance criteria ("criteria") may be of various types, including transaction assignment criteria and transaction completion criteria. Transaction assignment criteria relate to the amount of time that it takes for a server to be assigned to transactions after they arrive. A
transaction assignment criterion may indicate, for example, that incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arnval. Transaction assignment criteria are particularly well adapted to transactions initiated outside the organization using a real-time medium, such as an incoming telephone call or web hit-especially those transactions initiated by a human client. Such transactions are regarded as "volatile," as they may be lost if not quickly assigned to a server. For example, if an incoming telephone call is not answered within a few seconds after it is initiated, the caller may hang up and end the call.
Transaction completion criteria, on the other hand, relate to the amount of time that it takes to complete the processing of transactions. A
transaction completion criterion may indicate, for example, that credit check transactions are to be completed within 4 days of their arnval, or that outgoing telephone call transactions for new credit card offers are to be completed at the rate of 200 per day.
Transaction completion criteria are particularly well adapted to transactions initiated outside the organization using a non-real-time medium, such as incoming letters, or transactions that are initiated from inside the organization, such as outgoing telephone calls or are generated as a follow on to a transaction assignment transaction, such as a telephone call requesting a loan. Servicing the telephone call involves a transaction assignment criterion (such as answering all customer telephone calls within 20 seconds) but generating the loan application that results involves satisfying a transaction completion criterion (such as processing all loan applications within 4 business days).
In addition to specifying a performance criterion, a service level goal may also indicate a minimum percentage of times, or "minimum frequency," that the performance criterion is to be satisfied. For example, a transaction assignment service level goal may indicate that at least 90% of incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival.
In addition to a service level goal, each application preferably also has a priority level, indicating the importance of satisfying the service level goal of that application relative to the importance of satisfying the service level goals of the other applications. For example, incoming telephone call transactions for platinum credit card holders may have a priority level of 1 (indicating the highest priority), incoming telephone call transactions for gold credit card holders may have a priority level of 2, and outgoing telephone call transactions for new credit card offers may have a priority level of 3. Multiple applications may have the same priority level.
In contrast to conventional transaction processing systems that attempt to assign each newly-arnved transaction to a server, the facility of the present invention assigns each newly-available server to a transaction. Such assignment takes place each time a server becomes available, either when an existing server completes the processing of the last transaction that it was assigned to process, or when a new server arnves. The assignment process involves "offering" use of the server for use by each priority level of applications in sequence, from the highest priority level to the lowest S priority level, until a priority level accepts use of the server. To determine whether to accept the offered server, each priority level in turn offers the server to each application of that priority level, until an application accepts use of the server. If any application at that priority level accepts use of the server, then the priority level accepts the use of the server. On the other hand, if none of the applications at that priority level accepts use of the server, then the priority level declines the use of the server, and the facility offers use of the server to the next lower priority level. By offering each available server in accordance with the priority levels, the facility ensures that at least applications in the highest priority levels will successfully reach their service level goals.
Where adequate numbers of servers are available, however, the facility permits applications in all priority levels to reach their service level goals.
Within a single priority level, the facility offers use of the server to the applications of the priority level in a certain sequence. In cases in which the server is needed by more than one application in the current priority level, this sequence determines which of these applications is able to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the priority level. As one example, the facility may use a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this way, each application of the priority level has equal opportunity to accept servers offered to the priority level. As another example, the facility may assess the success of each application at reaching its service level goals, and establish a sequence that favors the applications that are the furthest from reaching their service level goals. In this way, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
When the facility offers a server to a particular application, the application preferably determines whether it should accept the offered server based on whether the offered server is needed by the application to meet its service level goal.
The facility may make this determination either on a "closed-loop" basis, in which the facility uses the current achieved service level of the application to make the determination, or on an "open-loop" basis, in which the facility uses information other than the current achieved service level of the application.
For the closed loop basis, the facility compares the current achieved service level with the pre-defined service level goal to make the determination. If the offered server is not required for achievement of the predetermined service level goals, then the server is not accepted. If the offered server is required to achieve the pre-determined service level goal, then the server is accepted.
For the open-loop basis, the facility may use a preestablished model, formula, or table to determine whether an offered server is needed by the application to meet its service level goal using current operating parameters of the application, such as transaction arnval rate, number of uninitiated transactions, wait times of uninitiated transactions, transaction service completion rate, and transaction service completion time.
When the application accepts the offered server, if any transactions are waiting for processing, the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in an idle/reserved server queue until a new transaction arrives. When a new transaction subsequently arrives, a server in the idle/reserved server queue is assigned to process the new transaction.
By maintaining one or more servers in its idle/reserved server queue, that is, by accepting a server or servers even when its transaction queue is empty, an application can ensure that a server will be immediately assigned to the next arriving transaction.
In this way, the application is able to exert control over its achieved service level.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a conceptual diagram showing the relationship between the facility, transactions, and servers.
Figure 2 is a table diagram identifying a number of sample transaction types.
Figure 3 is a conceptual diagram showing the facility's approach to assigning available servers to the priority levels identified in Figure 3.
Figure 4 is a flow diagram showing the steps preferably performed by the facility in order to assign an available server to one of the priority levels.
Figure 5 is a conceptual diagram showing the facility's approach to assigning available servers to the sample applications identified in Figure 2 within a particular priority level.
Figure 6 is a flow diagram showing the steps preferably performed by the facility in order to offer an available server to a particular priority level, as described above for step 402 of Figure 4.
Figure 7 is a flow diagram showing the steps preferably performed by the facility in order to accept or decline an available server offered to a particular application, as described above for step 603 of Figure 6.
Figure 8 is a workflow diagram showing the activity performed by the facility with respect to a single application.
Figure 9 is a high-level block diagram showing an illustrative computer system upon which the facility of the present invention may operate.
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides a facility for allocating transaction servers ("servers") in a transaction processing system in a manner that facilitates differentiation between transactions of different priorities and balancing the performance of transactions of the same priority. Within the constraints imposed by the availability of servers, the facility facilitates maintaining pre-defined service level goals.
For example, the facility may allocate telephone call processing servers, such as human g operators/agents and automatic response units, for processing telephone calls.
The facility can also allocate servers to process virtually any other type of transaction, including, but not limited to, form processing; response to world wide web hits ("web hits"); letter, fax, or email generation or response; account adjustment; and various forms of network and Internet communication. The facility can allocate servers between several different types of transactions. Transactions may be initiated within the organization using the facility, by external customers or clients of the organization, or both.
In a preferred embodiment, the facility allocates servers among different applications, each of which processes transactions of a different type or of the same type but with a different service level goal. For example, a first application may process incoming telephone call transactions for platinum credit card holders, a second application may process outgoing telephone call transactions for new credit card offers, and a third application may process credit check transactions, such as those received via the world wide web or in the mail, and a fourth application that responds to web hits with outgoing phone calls.
The facility preferably enables a service level goal to be specified for each application, indicating the level of performance sought in processing transactions of the application's type. Service level goals are generally each comprised of two components: a performance criterion specifying an amount of time by which some action relating to the transaction is to completed, and a minimum frequency indicating the percentage of transactions for which the criterion is to be satisfied. As an example, one service level goal may specify a criterion of assigning transaction within 15 seconds of their receipt, and a minimum frequency that indicates that 90% of the transactions are to be processed in accordance with the performance criterion. Performance criteria ("criteria") may be of various types, including transaction assignment criteria and transaction completion criteria. Transaction assignment service level goals relate to the amount of time that it takes for a server to be assigned to transactions after they arrive.
A transaction assignment criterion may indicate, for example, that incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival. Transaction assignment criteria are particularly well adapted to transactions initiated outside the organization using a real-time medium, such as an incoming telephone call or web hit-especially those transactions initiated by a human client. Such transactions are regarded as "volatile," as they may be lost if not quickly assigned to a server. For example, if an incoming telephone call is not answered within a few seconds after it is initiated, the caller may hang up and end the call.
Transaction completion criteria, on the other hand, relate to the amount of time that it takes to complete the processing of transactions. A
transaction completion criterion may indicate, for example, that credit check transactions are to be completed within 4 days of their arnval, or that outgoing telephone call transactions for new credit card offers are to be completed at the rate of 200 per day.
Transaction completion criteria are particularly well adapted to transactions initiated outside the organization using a non-real-time medium, such as incoming letters, or transactions that are initiated from inside the organization, such as outgoing telephone calls or are generated as a follow on to a transaction assignment transaction, such as a telephone call requesting a loan. Servicing the telephone call involves a transaction assignment criterion (such as answering all customer telephone calls within 20 seconds) but generating the loan application that results involves satisfying a transaction completion criterion (such as processing all loan applications within 4 business days).
In addition to specifying a performance criterion, service level goals may also indicate a minimum percentage of times, or "minimum frequency," that the performance criterion is to be satisfied. For example, a transaction assignment service level goal may indicate that at least 90% of incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival.
In addition to a service level goal, each application preferably also has a priority level, indicating the importance of satisfying the service level goal of that application relative to the importance of satisfying the service level goals of the other applications. For example, incoming telephone call transactions for platinum credit card holders may have a priority level of 1 (indicating the highest priority), incoming telephone call transactions for gold credit card holders may have a priority level of 2, and outgoing telephone call transactions for new credit card offers may have a priority level of 3. Multiple applications may have the same priority level.
In contrast to conventional transaction processing systems that attempt to 5 assign each newly-arnved transaction to a server, the facility of the present invention assigns each newly-available server to a transaction. Such assignment takes place each time a server becomes available, either when an existing server completes the processing of the last transaction that it was assigned to process, or when a new server arrives. The assignment process involves "offering" use of the server for use by each 10 priority level of applications in sequence, from the highest priority level to the lowest priority level, until a priority level accepts use of the server. To determine whether to accept the offered server, each priority level in turn offers the server to each application of that priority level, until an application accepts use of the server. If any application at that priority level accepts use of the server, then the priority level accepts the use of the server. On the other hand, if none of the applications at that priority level accepts use of the server, then the priority level declines the use of the server, and the facility offers use of the server to the next lower priority level. By offering each available server in accordance with the priority levels, the facility ensures that at least applications in the highest priority levels will successfully reach their service level goals.
Where adequate numbers of servers are available, however, the facility permits applications in all priority levels to reach their service level goals.
Within a single priority level, the facility offers use of the server to the applications of the priority level in a certain sequence. In cases in which the server is needed by more than one application in the current priority level, this sequence determines which of these applications is able to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the priority level. As one example, the facility may use a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this way, each application of the priority level has equal opportunity to accept servers offered to the priority level. As another example, the facility may assess the success of each application at reaching its service level goals, and establish a sequence that favors the applications that are the fiurthest from reaching their service level goals. In this way, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
When the facility offers a server to a particular application, the application preferably determines whether it should accept the offered server based on whether the offered server is needed by the application to meet its service level goal.
The facility may make this determination either on a "closed-loop" basis, in which the facility uses the current achieved service level of the application to make the determination, or on an "open-loop" basis, in which the facility uses information other than the current achieved service level of the application.
For the closed loop basis, the facility compares the current achieved service level with the pre-determined service level goal to make the determination. If the offered server is not required for achievement of the predetermined service level goal, then the server is not accepted. If the offered server is required to achieve the pre-determined service level goal, then the server is accepted.
For the open-loop basis, the facility may use a preestablished model, formula, or table to determine whether an offered server is needed by the application to meet its service level goal using current operating parameters of the application, such as transaction arnval rate, number of uninitiated transactions, wait times of uninitiated transactions, transaction service completion rate, and transaction service completion time.
When the application accepts the offered server, if any transactions are waiting for processing, the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in a reserved/idle server queue until a new transaction arrives. When a new transaction subsequently arnves, a server in the reserved/idle server queue is assigned to process the new transaction. By maintaining one or more servers in its reserved/idle server queue, that is, by accepting a server or servers even when its transaction queue is empty, an application can ensure that a server will be immediately assigned to the next arriving transaction. In this way, the application is able to exert control over its achieved service level.
Figure 1 is a conceptual diagram showing the relationship between the facility, transactions, and servers. It can be seen from Figure 1 that the facility 100 receives arriving transactions 111, such as telephone calls or web hits, and arriving servers 112, such as servers like human agents, automatic telephone response units, and/or automated web servers. Servers may arnve because they have just become available ("logged on" or "gone online"), or because they have completed servicing a transaction and are available for reassignment. The facility 100 assigns each arnving server to a particular transaction, such that an assigned server processes the transaction to which it is assigned. After the processing of a particular assignment by a server is completed, the facility 100 produces a completed transaction 121. The server assigned to process the completed transaction may exit the facility as a departing server 122. For example, human agents may leave their workstations for a break or at the end of the workday, while automatic response units may be deactivated for service or replacement.
If the server does not leave the facility, however, it becomes a new arriving server 112, which is reassigned by the facility to a new transaction.
Figure 2 is a table diagram identifying a number of sample transaction types. Each row of the table 200 corresponds to a different transaction type and application for processing transactions of that type, and indicates an application number 201 uniquely identifying an application, a priority level 202, a transaction type 203 of the application, a service level goal 204, and a service level goal type 205.
Each service level goal 204 is in turn made up of a performance criterion 206 and a minimum frequency 207. For example, row 221 of table 200 indicates that incoming calls from gold card customers have a priority level of 2. Their service level goal is to assign transactions within 60 seconds of their arrival (their performance criterion) for 90% of the transactions (their minimum frequency). This is a transaction assignment service level goal. Row 241 differs somewhat from the other rows, in that it represents a default activity for servers that are not needed for any application. As such, it has a service level goal type of "none." When a server becomes available, the facility preferably offers the server first to the priority level 1 application identified in row 21 l, then to the priority level 2 applications identified in rows 221 and 222, then to the priority level 3 applications identified in rows 231-233, then to the priority level 100 application identified in row 241, until the offered server is accepted.
Figure 3 is a conceptual diagram showing the facility's approach to assigning available servers to the priority levels identified in Figure 2. In Figure 3, when each arnving server 301 becomes available to the facility, the facility offers the arnving server to one priority level after another until one of the priority levels accepts the offered server. 'The facility begins by offering the server to the highest priority level, that is, the priority level having the smallest number. In the example, highest priority level is 1. Priority level 1 (311 ) determines whether the offered server is needed to meet the service level goal of any of its applications. If so.
priority level 1 accepts the offered server, and assigns it to one of its applications (discussed in greater detail below), which uses it to process an arriving transaction. After such processing is complete, the application outputs the completed transaction, and releases the server. At this point, the server may join the departing servers 302 that are no longer available to process transactions, or may follow route 303 to reenter the facility as an arriving server.
If priority level 1 does not accept the offered server, the facility next offers the server to priority level 2 (312). Again, if priority level 2 accepts the server, then one of the applications in priority level 2 uses the server to process one of its arriving transactions, and then that application releases the server for departure or reassignment. If priority level 2 does not accept the offered server, then the facility offers the server to priority level 3 (313).
If, after offering the server to priority levels 1-3, the server has not been accepted, the facility preferably offers the application to priority level 100 (314).
Priority level 100 has a minimum priority, and contains a single "background"
application, which always has transactions available. This background application is preferably provided to accept any offered servers that are not accepted by applications in higher priority levels. As the net result of this process, the server is accepted and used by exactly one of the four priority levels, then released either to depart or to be reassigned.
Figure 4 is a flow diagram showing the steps preferably performed by the facility in order to assign an available server to one of the priority levels. In steps 401-404, the facility loops through each defined priority level, from the highest priority level to the lowest. In terms of the applications identified in Figure 2, this involves looping through priority levels 1, 2, 3, and 100, in that order. Step 401 marks the beginning of this loop, and step 404 marks its end. In step 402, the facility offers the available server to the current priority level (i.e., level 1 in the first loop through). The details of step 402 are discussed in greater detail below in connection with Figure 6. In step 403, if, in response to the offer of step 402, the server is accepted by the current priority level, then these steps conclude. If in step 402 the server is not accepted, the facility continues in step 404. In step 404, if additional, lower priority levels remain, then the facility loops back to step 401 to offer the server to the next lower priority level. If no lower priority levels remain, these steps conclude. If no default application is defined for the facility, the facility may loop through all of the priority levels without assigning the available server to any of the priority levels. In this case, the facility preferably repeats these steps at a later time.
Figure 5 is a conceptual diagram showing the facility's approach to assigning available servers to the sample applications identified in Figure 2 within a particular priority level. Figure 5 shows the operation of distribution logic for priority level 3 as identified in the table shown in Figure 2, containing applications 4, 5, and 6.
After an available agent has been offered to priority levels 1 and 2 and declined by both, the available server 501 is offered to priority level 3. In response, the priority level 3 server distribution logic ( 1 ) prioritizes the applications in the service level in terms of their need for available servers, then tests for server demand in the applications in that priority order. In prioritizing, the server distribution logic 500 uses indications of the current or expected future service level of each of the applications 511-513.
The server distribution logic then offers the available server, in turn, to the three applications in the 1$
priority level $21-$23 in this order. As discussed below, each application, when it is offered the available server, determines whether the server is needed to meet its service level goal, and if so, accepts the server. If the available server is not needed by the current application to meet its service level goal, the current application declines the $ available server and the priority level server distribution logic offers it to the next application in the priority order. If the available server is accepted by one of the applications, it is used to process a transaction, then released as a departing server $03.
On the other hand, if the available server is not accepted by any of the applications, the server is declined by the priority level $02, and can be offered to the next lower priority level.
Figure 6 is a flow diagram showing the steps preferably performed by the facility in order to offer an available server to a particular priority level, as described above for step 402 of Figure 4. In step 601, the facility establishes an order for the applications having the current priority level. The facility preferably omits step 601 for 1$ priority levels having only one application. In terms of the applications identified in Figure 2, for priority level 3, the facility would establish an order for the applications identified in rows 231, 232, and 233. In cases in which the server is needed by more than one application in the current priority level, the order established in step 601 determines which of these applications is permitted to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the current priority level. In one preferred embodiment, the facility uses a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this embodiment, each application of the priority level has equal opportunity to accept servers offered to 2$ the priority level. In another preferred embodiment, the facility assesses the success of each application at reaching its service level goal, and establishes a sequence that favors the applications that are the furthest from reaching their service level goals. In this embodiment, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
In steps 602-605 of Figure 6, the facility loops through each application in the order established in step 601. Step 602 marks the beginning of this loop, and step 605 marks its end. In step 603, the facility offers the available server to the current application. The performance of step 603 is discussed in greater detail below in conjunction with Figure 7. In step 604, if the current application accepts the server in response to the offer of step 603, then these steps conclude. If the current application does not accept the server, the facility continues in step 605. In step 605, if additional applications remain in the established order, then the facility loops back to step 602 to offer the available server to the next application. If no additional applications remain, these steps conclude.
Figure 7 is a flow diagram showing the steps preferably performed by the facility in order to accept or decline an available server offered to a particular application, as described above for step 603 of Figure 6. In step 701, the facility determines whether the server is needed to satisfy the current application's service level goal. In terms of the applications identified in row 221 of Figure 2, for the incoming gold calls application, the facility determines whether the available server is needed in order to assign incoming gold calls within 60 seconds of their arrival for 90%
of such calls. In step 701, if it is determined that the available server is needed to satisfy the current application's service level goal, then the facility continues in step 702. In step 702, the facility accepts the available server to process transactions within the current application. When the application accepts the offered server, if any transactions are waiting for processing the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in an idle/reserved server queue until a new transaction arrives. When a new transaction arrives, a server in the idle/reserved server queue is assigned to process the new transaction. After step 702, these steps conclude. If in step 701 the available server is not needed, the facility continues in step 703. In step 703, the facility declines to accept the server for the current application, and these steps conclude. In one preferred embodiment, the detenrnination of step 701 is expanded to also include one or more tests (not shown) for the suitability of the available server to the transaction type of the current application.
In this embodiment, each individual server has certain qualification standards, which are used as the basis for determining whether a particular server is well-suited to a particular transaction type.
Figure 8 is a workflow diagram showing the activity performed by the facility with respect to a single application. Block 801 shows that a server is offered to the application, and the application either accepts or declines based on such parameters as the current service level ("SL"), the number of transactions waiting in a transaction queue 804 to be assigned ("NQUE~"), and the number of servers waiting to be assigned to a transaction in an idle/reserved server queue 802 ("NmLE"). If the server is accepted, it is added to the idle/reserved server queue 802. Block 803 shows that arriving transactions are queued in a transaction queue 804. The rate at which transactions arrive is monitored by SL control logic 807. As shown by block 805, any time the idle/reserved server queue contains at least one server and the transaction queue contains at least one transaction, a server is removed from the idle/reserved server queue 802, a transaction is removed from the transaction queue 804 and thus the removed server is assigned to process the removed transaction. When a server is assigned to a transaction in this manner, the SL control logic 807 monitors the amount of time the transaction spent in the transaction queue 804. Transactions being processed by servers are shown in block 806. After a server completes the processing of a transaction, the facility preferably reassigns the server in accordance with the steps shown in Figure 6. Also, when processing of the transaction is completed, the SL
control logic 807 monitors the amount of time the server took to process the transaction.
The SL control logic 807 calculates statistics relating to the processing of transactions in the application, such as NQ~~, Nm~E, and SL, that are used in block 801 to determine whether to accept or decline an offered server.
The facility may be implemented on a wide variety of hardware configurations. Figure 9 is a high-level block diagram showing an illustrative computer system upon which the facility of the present invention may execute. As shown in Figure 9, the computer system 900 comprises a central processing unit (CPU) 910, input/output devices 920, and a computer memory 930. Among the input/output devices is a storage device 921, such as a hard disk drive; and a computer-readable media drive 922, which can be used to install software products, including the facility, which are provided on a computer-readable medium, such as a CD-ROM. The input/output devices 930 further include a connection 923 to servers and transaction sources from which transactions are received. For example, the connection 923 may be used to connect the computer system to one or more computer telephony interfaces, world wide web servers, or world wide web browsers. This connection is usable by the facility to detect server availability, assign servers to applications and transactions, and monitor the processing of transactions by servers.
The memory 930 contains the facility 931 for distributing servers, which includes a priority level server distribution subsystem 932 whose operation is discussed above in conjunction with Figure 4, and an application level server distribution subsystem 933 whose operation is discussed above in connection with Figure 6.
In addition to the facility 931, the memory 930 preferably also contains logic for each application, such as application 1 934 and application 2 936. Included for each application is a server acceptance subsystem for determining whether to accept servers offered to the application, such as server acceptance subsystem 935.
While the facility is preferably implemented on a computer system configured as described above, those skilled in the art will recognize that it may also be implemented on computer systems having different configurations. For example, the facility may be implemented on a computer system having different components than described above. Further, the functionality of the computer system 900 may be divided among several different computers in a distributed system. For example, application 1 (934) and application 2 (936) may reside on separate, geographically-distributed hardware configurations interconnected via a communications network. The facility may also be implemented on special-purpose computer systems, such as those in a call center. The facility may further be implemented without software in special-purpose hardware, using, for example, application-specific integrated circuits.
While the present invention has been shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes or modifications in form and detail may be made without departing from the scope of the invention. For example, though described in conjunction with telephone call transactions, the facility may be used to allocate servers for processing virtually any kind of transaction. Further, the facility may maintain additional state information that obviates certain steps of the allocation process described above.
Additionally, the facility preferably facilitates the use of service level metrics and service level goal types other than those discussed above.
transaction completion criterion may indicate, for example, that credit check transactions are to be completed within 4 days of their arnval, or that outgoing telephone call transactions for new credit card offers are to be completed at the rate of 200 per day.
Transaction completion criteria are particularly well adapted to transactions initiated outside the organization using a non-real-time medium, such as incoming letters, or transactions that are initiated from inside the organization, such as outgoing telephone calls or are generated as a follow on to a transaction assignment transaction, such as a telephone call requesting a loan. Servicing the telephone call involves a transaction assignment criterion (such as answering all customer telephone calls within 20 seconds) but generating the loan application that results involves satisfying a transaction completion criterion (such as processing all loan applications within 4 business days).
In addition to specifying a performance criterion, a service level goal may also indicate a minimum percentage of times, or "minimum frequency," that the performance criterion is to be satisfied. For example, a transaction assignment service level goal may indicate that at least 90% of incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival.
In addition to a service level goal, each application preferably also has a priority level, indicating the importance of satisfying the service level goal of that application relative to the importance of satisfying the service level goals of the other applications. For example, incoming telephone call transactions for platinum credit card holders may have a priority level of 1 (indicating the highest priority), incoming telephone call transactions for gold credit card holders may have a priority level of 2, and outgoing telephone call transactions for new credit card offers may have a priority level of 3. Multiple applications may have the same priority level.
In contrast to conventional transaction processing systems that attempt to assign each newly-arnved transaction to a server, the facility of the present invention assigns each newly-available server to a transaction. Such assignment takes place each time a server becomes available, either when an existing server completes the processing of the last transaction that it was assigned to process, or when a new server arnves. The assignment process involves "offering" use of the server for use by each priority level of applications in sequence, from the highest priority level to the lowest S priority level, until a priority level accepts use of the server. To determine whether to accept the offered server, each priority level in turn offers the server to each application of that priority level, until an application accepts use of the server. If any application at that priority level accepts use of the server, then the priority level accepts the use of the server. On the other hand, if none of the applications at that priority level accepts use of the server, then the priority level declines the use of the server, and the facility offers use of the server to the next lower priority level. By offering each available server in accordance with the priority levels, the facility ensures that at least applications in the highest priority levels will successfully reach their service level goals.
Where adequate numbers of servers are available, however, the facility permits applications in all priority levels to reach their service level goals.
Within a single priority level, the facility offers use of the server to the applications of the priority level in a certain sequence. In cases in which the server is needed by more than one application in the current priority level, this sequence determines which of these applications is able to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the priority level. As one example, the facility may use a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this way, each application of the priority level has equal opportunity to accept servers offered to the priority level. As another example, the facility may assess the success of each application at reaching its service level goals, and establish a sequence that favors the applications that are the furthest from reaching their service level goals. In this way, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
When the facility offers a server to a particular application, the application preferably determines whether it should accept the offered server based on whether the offered server is needed by the application to meet its service level goal.
The facility may make this determination either on a "closed-loop" basis, in which the facility uses the current achieved service level of the application to make the determination, or on an "open-loop" basis, in which the facility uses information other than the current achieved service level of the application.
For the closed loop basis, the facility compares the current achieved service level with the pre-defined service level goal to make the determination. If the offered server is not required for achievement of the predetermined service level goals, then the server is not accepted. If the offered server is required to achieve the pre-determined service level goal, then the server is accepted.
For the open-loop basis, the facility may use a preestablished model, formula, or table to determine whether an offered server is needed by the application to meet its service level goal using current operating parameters of the application, such as transaction arnval rate, number of uninitiated transactions, wait times of uninitiated transactions, transaction service completion rate, and transaction service completion time.
When the application accepts the offered server, if any transactions are waiting for processing, the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in an idle/reserved server queue until a new transaction arrives. When a new transaction subsequently arrives, a server in the idle/reserved server queue is assigned to process the new transaction.
By maintaining one or more servers in its idle/reserved server queue, that is, by accepting a server or servers even when its transaction queue is empty, an application can ensure that a server will be immediately assigned to the next arriving transaction.
In this way, the application is able to exert control over its achieved service level.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a conceptual diagram showing the relationship between the facility, transactions, and servers.
Figure 2 is a table diagram identifying a number of sample transaction types.
Figure 3 is a conceptual diagram showing the facility's approach to assigning available servers to the priority levels identified in Figure 3.
Figure 4 is a flow diagram showing the steps preferably performed by the facility in order to assign an available server to one of the priority levels.
Figure 5 is a conceptual diagram showing the facility's approach to assigning available servers to the sample applications identified in Figure 2 within a particular priority level.
Figure 6 is a flow diagram showing the steps preferably performed by the facility in order to offer an available server to a particular priority level, as described above for step 402 of Figure 4.
Figure 7 is a flow diagram showing the steps preferably performed by the facility in order to accept or decline an available server offered to a particular application, as described above for step 603 of Figure 6.
Figure 8 is a workflow diagram showing the activity performed by the facility with respect to a single application.
Figure 9 is a high-level block diagram showing an illustrative computer system upon which the facility of the present invention may operate.
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides a facility for allocating transaction servers ("servers") in a transaction processing system in a manner that facilitates differentiation between transactions of different priorities and balancing the performance of transactions of the same priority. Within the constraints imposed by the availability of servers, the facility facilitates maintaining pre-defined service level goals.
For example, the facility may allocate telephone call processing servers, such as human g operators/agents and automatic response units, for processing telephone calls.
The facility can also allocate servers to process virtually any other type of transaction, including, but not limited to, form processing; response to world wide web hits ("web hits"); letter, fax, or email generation or response; account adjustment; and various forms of network and Internet communication. The facility can allocate servers between several different types of transactions. Transactions may be initiated within the organization using the facility, by external customers or clients of the organization, or both.
In a preferred embodiment, the facility allocates servers among different applications, each of which processes transactions of a different type or of the same type but with a different service level goal. For example, a first application may process incoming telephone call transactions for platinum credit card holders, a second application may process outgoing telephone call transactions for new credit card offers, and a third application may process credit check transactions, such as those received via the world wide web or in the mail, and a fourth application that responds to web hits with outgoing phone calls.
The facility preferably enables a service level goal to be specified for each application, indicating the level of performance sought in processing transactions of the application's type. Service level goals are generally each comprised of two components: a performance criterion specifying an amount of time by which some action relating to the transaction is to completed, and a minimum frequency indicating the percentage of transactions for which the criterion is to be satisfied. As an example, one service level goal may specify a criterion of assigning transaction within 15 seconds of their receipt, and a minimum frequency that indicates that 90% of the transactions are to be processed in accordance with the performance criterion. Performance criteria ("criteria") may be of various types, including transaction assignment criteria and transaction completion criteria. Transaction assignment service level goals relate to the amount of time that it takes for a server to be assigned to transactions after they arrive.
A transaction assignment criterion may indicate, for example, that incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival. Transaction assignment criteria are particularly well adapted to transactions initiated outside the organization using a real-time medium, such as an incoming telephone call or web hit-especially those transactions initiated by a human client. Such transactions are regarded as "volatile," as they may be lost if not quickly assigned to a server. For example, if an incoming telephone call is not answered within a few seconds after it is initiated, the caller may hang up and end the call.
Transaction completion criteria, on the other hand, relate to the amount of time that it takes to complete the processing of transactions. A
transaction completion criterion may indicate, for example, that credit check transactions are to be completed within 4 days of their arnval, or that outgoing telephone call transactions for new credit card offers are to be completed at the rate of 200 per day.
Transaction completion criteria are particularly well adapted to transactions initiated outside the organization using a non-real-time medium, such as incoming letters, or transactions that are initiated from inside the organization, such as outgoing telephone calls or are generated as a follow on to a transaction assignment transaction, such as a telephone call requesting a loan. Servicing the telephone call involves a transaction assignment criterion (such as answering all customer telephone calls within 20 seconds) but generating the loan application that results involves satisfying a transaction completion criterion (such as processing all loan applications within 4 business days).
In addition to specifying a performance criterion, service level goals may also indicate a minimum percentage of times, or "minimum frequency," that the performance criterion is to be satisfied. For example, a transaction assignment service level goal may indicate that at least 90% of incoming telephone call transactions for platinum credit card holders are to be assigned to a server within 15 seconds of their arrival.
In addition to a service level goal, each application preferably also has a priority level, indicating the importance of satisfying the service level goal of that application relative to the importance of satisfying the service level goals of the other applications. For example, incoming telephone call transactions for platinum credit card holders may have a priority level of 1 (indicating the highest priority), incoming telephone call transactions for gold credit card holders may have a priority level of 2, and outgoing telephone call transactions for new credit card offers may have a priority level of 3. Multiple applications may have the same priority level.
In contrast to conventional transaction processing systems that attempt to 5 assign each newly-arnved transaction to a server, the facility of the present invention assigns each newly-available server to a transaction. Such assignment takes place each time a server becomes available, either when an existing server completes the processing of the last transaction that it was assigned to process, or when a new server arrives. The assignment process involves "offering" use of the server for use by each 10 priority level of applications in sequence, from the highest priority level to the lowest priority level, until a priority level accepts use of the server. To determine whether to accept the offered server, each priority level in turn offers the server to each application of that priority level, until an application accepts use of the server. If any application at that priority level accepts use of the server, then the priority level accepts the use of the server. On the other hand, if none of the applications at that priority level accepts use of the server, then the priority level declines the use of the server, and the facility offers use of the server to the next lower priority level. By offering each available server in accordance with the priority levels, the facility ensures that at least applications in the highest priority levels will successfully reach their service level goals.
Where adequate numbers of servers are available, however, the facility permits applications in all priority levels to reach their service level goals.
Within a single priority level, the facility offers use of the server to the applications of the priority level in a certain sequence. In cases in which the server is needed by more than one application in the current priority level, this sequence determines which of these applications is able to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the priority level. As one example, the facility may use a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this way, each application of the priority level has equal opportunity to accept servers offered to the priority level. As another example, the facility may assess the success of each application at reaching its service level goals, and establish a sequence that favors the applications that are the fiurthest from reaching their service level goals. In this way, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
When the facility offers a server to a particular application, the application preferably determines whether it should accept the offered server based on whether the offered server is needed by the application to meet its service level goal.
The facility may make this determination either on a "closed-loop" basis, in which the facility uses the current achieved service level of the application to make the determination, or on an "open-loop" basis, in which the facility uses information other than the current achieved service level of the application.
For the closed loop basis, the facility compares the current achieved service level with the pre-determined service level goal to make the determination. If the offered server is not required for achievement of the predetermined service level goal, then the server is not accepted. If the offered server is required to achieve the pre-determined service level goal, then the server is accepted.
For the open-loop basis, the facility may use a preestablished model, formula, or table to determine whether an offered server is needed by the application to meet its service level goal using current operating parameters of the application, such as transaction arnval rate, number of uninitiated transactions, wait times of uninitiated transactions, transaction service completion rate, and transaction service completion time.
When the application accepts the offered server, if any transactions are waiting for processing, the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in a reserved/idle server queue until a new transaction arrives. When a new transaction subsequently arnves, a server in the reserved/idle server queue is assigned to process the new transaction. By maintaining one or more servers in its reserved/idle server queue, that is, by accepting a server or servers even when its transaction queue is empty, an application can ensure that a server will be immediately assigned to the next arriving transaction. In this way, the application is able to exert control over its achieved service level.
Figure 1 is a conceptual diagram showing the relationship between the facility, transactions, and servers. It can be seen from Figure 1 that the facility 100 receives arriving transactions 111, such as telephone calls or web hits, and arriving servers 112, such as servers like human agents, automatic telephone response units, and/or automated web servers. Servers may arnve because they have just become available ("logged on" or "gone online"), or because they have completed servicing a transaction and are available for reassignment. The facility 100 assigns each arnving server to a particular transaction, such that an assigned server processes the transaction to which it is assigned. After the processing of a particular assignment by a server is completed, the facility 100 produces a completed transaction 121. The server assigned to process the completed transaction may exit the facility as a departing server 122. For example, human agents may leave their workstations for a break or at the end of the workday, while automatic response units may be deactivated for service or replacement.
If the server does not leave the facility, however, it becomes a new arriving server 112, which is reassigned by the facility to a new transaction.
Figure 2 is a table diagram identifying a number of sample transaction types. Each row of the table 200 corresponds to a different transaction type and application for processing transactions of that type, and indicates an application number 201 uniquely identifying an application, a priority level 202, a transaction type 203 of the application, a service level goal 204, and a service level goal type 205.
Each service level goal 204 is in turn made up of a performance criterion 206 and a minimum frequency 207. For example, row 221 of table 200 indicates that incoming calls from gold card customers have a priority level of 2. Their service level goal is to assign transactions within 60 seconds of their arrival (their performance criterion) for 90% of the transactions (their minimum frequency). This is a transaction assignment service level goal. Row 241 differs somewhat from the other rows, in that it represents a default activity for servers that are not needed for any application. As such, it has a service level goal type of "none." When a server becomes available, the facility preferably offers the server first to the priority level 1 application identified in row 21 l, then to the priority level 2 applications identified in rows 221 and 222, then to the priority level 3 applications identified in rows 231-233, then to the priority level 100 application identified in row 241, until the offered server is accepted.
Figure 3 is a conceptual diagram showing the facility's approach to assigning available servers to the priority levels identified in Figure 2. In Figure 3, when each arnving server 301 becomes available to the facility, the facility offers the arnving server to one priority level after another until one of the priority levels accepts the offered server. 'The facility begins by offering the server to the highest priority level, that is, the priority level having the smallest number. In the example, highest priority level is 1. Priority level 1 (311 ) determines whether the offered server is needed to meet the service level goal of any of its applications. If so.
priority level 1 accepts the offered server, and assigns it to one of its applications (discussed in greater detail below), which uses it to process an arriving transaction. After such processing is complete, the application outputs the completed transaction, and releases the server. At this point, the server may join the departing servers 302 that are no longer available to process transactions, or may follow route 303 to reenter the facility as an arriving server.
If priority level 1 does not accept the offered server, the facility next offers the server to priority level 2 (312). Again, if priority level 2 accepts the server, then one of the applications in priority level 2 uses the server to process one of its arriving transactions, and then that application releases the server for departure or reassignment. If priority level 2 does not accept the offered server, then the facility offers the server to priority level 3 (313).
If, after offering the server to priority levels 1-3, the server has not been accepted, the facility preferably offers the application to priority level 100 (314).
Priority level 100 has a minimum priority, and contains a single "background"
application, which always has transactions available. This background application is preferably provided to accept any offered servers that are not accepted by applications in higher priority levels. As the net result of this process, the server is accepted and used by exactly one of the four priority levels, then released either to depart or to be reassigned.
Figure 4 is a flow diagram showing the steps preferably performed by the facility in order to assign an available server to one of the priority levels. In steps 401-404, the facility loops through each defined priority level, from the highest priority level to the lowest. In terms of the applications identified in Figure 2, this involves looping through priority levels 1, 2, 3, and 100, in that order. Step 401 marks the beginning of this loop, and step 404 marks its end. In step 402, the facility offers the available server to the current priority level (i.e., level 1 in the first loop through). The details of step 402 are discussed in greater detail below in connection with Figure 6. In step 403, if, in response to the offer of step 402, the server is accepted by the current priority level, then these steps conclude. If in step 402 the server is not accepted, the facility continues in step 404. In step 404, if additional, lower priority levels remain, then the facility loops back to step 401 to offer the server to the next lower priority level. If no lower priority levels remain, these steps conclude. If no default application is defined for the facility, the facility may loop through all of the priority levels without assigning the available server to any of the priority levels. In this case, the facility preferably repeats these steps at a later time.
Figure 5 is a conceptual diagram showing the facility's approach to assigning available servers to the sample applications identified in Figure 2 within a particular priority level. Figure 5 shows the operation of distribution logic for priority level 3 as identified in the table shown in Figure 2, containing applications 4, 5, and 6.
After an available agent has been offered to priority levels 1 and 2 and declined by both, the available server 501 is offered to priority level 3. In response, the priority level 3 server distribution logic ( 1 ) prioritizes the applications in the service level in terms of their need for available servers, then tests for server demand in the applications in that priority order. In prioritizing, the server distribution logic 500 uses indications of the current or expected future service level of each of the applications 511-513.
The server distribution logic then offers the available server, in turn, to the three applications in the 1$
priority level $21-$23 in this order. As discussed below, each application, when it is offered the available server, determines whether the server is needed to meet its service level goal, and if so, accepts the server. If the available server is not needed by the current application to meet its service level goal, the current application declines the $ available server and the priority level server distribution logic offers it to the next application in the priority order. If the available server is accepted by one of the applications, it is used to process a transaction, then released as a departing server $03.
On the other hand, if the available server is not accepted by any of the applications, the server is declined by the priority level $02, and can be offered to the next lower priority level.
Figure 6 is a flow diagram showing the steps preferably performed by the facility in order to offer an available server to a particular priority level, as described above for step 402 of Figure 4. In step 601, the facility establishes an order for the applications having the current priority level. The facility preferably omits step 601 for 1$ priority levels having only one application. In terms of the applications identified in Figure 2, for priority level 3, the facility would establish an order for the applications identified in rows 231, 232, and 233. In cases in which the server is needed by more than one application in the current priority level, the order established in step 601 determines which of these applications is permitted to use the server. The facility therefore establishes the sequence in a manner that is fair to all of the applications of the current priority level. In one preferred embodiment, the facility uses a round-robin approach for establishing this order, beginning with an initial random order and, for each offer, rotating the order one position in a consistent direction. In this embodiment, each application of the priority level has equal opportunity to accept servers offered to 2$ the priority level. In another preferred embodiment, the facility assesses the success of each application at reaching its service level goal, and establishes a sequence that favors the applications that are the furthest from reaching their service level goals. In this embodiment, the facility exerts a balancing force on the applications of the priority level, enabling underperforming applications to receive extra servers that can be used to improve the performance of these applications.
In steps 602-605 of Figure 6, the facility loops through each application in the order established in step 601. Step 602 marks the beginning of this loop, and step 605 marks its end. In step 603, the facility offers the available server to the current application. The performance of step 603 is discussed in greater detail below in conjunction with Figure 7. In step 604, if the current application accepts the server in response to the offer of step 603, then these steps conclude. If the current application does not accept the server, the facility continues in step 605. In step 605, if additional applications remain in the established order, then the facility loops back to step 602 to offer the available server to the next application. If no additional applications remain, these steps conclude.
Figure 7 is a flow diagram showing the steps preferably performed by the facility in order to accept or decline an available server offered to a particular application, as described above for step 603 of Figure 6. In step 701, the facility determines whether the server is needed to satisfy the current application's service level goal. In terms of the applications identified in row 221 of Figure 2, for the incoming gold calls application, the facility determines whether the available server is needed in order to assign incoming gold calls within 60 seconds of their arrival for 90%
of such calls. In step 701, if it is determined that the available server is needed to satisfy the current application's service level goal, then the facility continues in step 702. In step 702, the facility accepts the available server to process transactions within the current application. When the application accepts the offered server, if any transactions are waiting for processing the accepted server is assigned to process one of the waiting transactions. On the other hand, if no transactions are waiting when the application accepts the server, the accepted server is maintained in an idle/reserved server queue until a new transaction arrives. When a new transaction arrives, a server in the idle/reserved server queue is assigned to process the new transaction. After step 702, these steps conclude. If in step 701 the available server is not needed, the facility continues in step 703. In step 703, the facility declines to accept the server for the current application, and these steps conclude. In one preferred embodiment, the detenrnination of step 701 is expanded to also include one or more tests (not shown) for the suitability of the available server to the transaction type of the current application.
In this embodiment, each individual server has certain qualification standards, which are used as the basis for determining whether a particular server is well-suited to a particular transaction type.
Figure 8 is a workflow diagram showing the activity performed by the facility with respect to a single application. Block 801 shows that a server is offered to the application, and the application either accepts or declines based on such parameters as the current service level ("SL"), the number of transactions waiting in a transaction queue 804 to be assigned ("NQUE~"), and the number of servers waiting to be assigned to a transaction in an idle/reserved server queue 802 ("NmLE"). If the server is accepted, it is added to the idle/reserved server queue 802. Block 803 shows that arriving transactions are queued in a transaction queue 804. The rate at which transactions arrive is monitored by SL control logic 807. As shown by block 805, any time the idle/reserved server queue contains at least one server and the transaction queue contains at least one transaction, a server is removed from the idle/reserved server queue 802, a transaction is removed from the transaction queue 804 and thus the removed server is assigned to process the removed transaction. When a server is assigned to a transaction in this manner, the SL control logic 807 monitors the amount of time the transaction spent in the transaction queue 804. Transactions being processed by servers are shown in block 806. After a server completes the processing of a transaction, the facility preferably reassigns the server in accordance with the steps shown in Figure 6. Also, when processing of the transaction is completed, the SL
control logic 807 monitors the amount of time the server took to process the transaction.
The SL control logic 807 calculates statistics relating to the processing of transactions in the application, such as NQ~~, Nm~E, and SL, that are used in block 801 to determine whether to accept or decline an offered server.
The facility may be implemented on a wide variety of hardware configurations. Figure 9 is a high-level block diagram showing an illustrative computer system upon which the facility of the present invention may execute. As shown in Figure 9, the computer system 900 comprises a central processing unit (CPU) 910, input/output devices 920, and a computer memory 930. Among the input/output devices is a storage device 921, such as a hard disk drive; and a computer-readable media drive 922, which can be used to install software products, including the facility, which are provided on a computer-readable medium, such as a CD-ROM. The input/output devices 930 further include a connection 923 to servers and transaction sources from which transactions are received. For example, the connection 923 may be used to connect the computer system to one or more computer telephony interfaces, world wide web servers, or world wide web browsers. This connection is usable by the facility to detect server availability, assign servers to applications and transactions, and monitor the processing of transactions by servers.
The memory 930 contains the facility 931 for distributing servers, which includes a priority level server distribution subsystem 932 whose operation is discussed above in conjunction with Figure 4, and an application level server distribution subsystem 933 whose operation is discussed above in connection with Figure 6.
In addition to the facility 931, the memory 930 preferably also contains logic for each application, such as application 1 934 and application 2 936. Included for each application is a server acceptance subsystem for determining whether to accept servers offered to the application, such as server acceptance subsystem 935.
While the facility is preferably implemented on a computer system configured as described above, those skilled in the art will recognize that it may also be implemented on computer systems having different configurations. For example, the facility may be implemented on a computer system having different components than described above. Further, the functionality of the computer system 900 may be divided among several different computers in a distributed system. For example, application 1 (934) and application 2 (936) may reside on separate, geographically-distributed hardware configurations interconnected via a communications network. The facility may also be implemented on special-purpose computer systems, such as those in a call center. The facility may further be implemented without software in special-purpose hardware, using, for example, application-specific integrated circuits.
While the present invention has been shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes or modifications in form and detail may be made without departing from the scope of the invention. For example, though described in conjunction with telephone call transactions, the facility may be used to allocate servers for processing virtually any kind of transaction. Further, the facility may maintain additional state information that obviates certain steps of the allocation process described above.
Additionally, the facility preferably facilitates the use of service level metrics and service level goal types other than those discussed above.
Claims (19)
1 WHAT IS CLAIMED IS:
1. A method in a computer system for distributing transaction servers to process transactions of a plurality of different types,, the transaction types being organized into a plurality of priority levels ordered from highest to lowest, each priority level having one or more transaction types, each transaction type further having a service level goal reflecting the level of service sought for transactions of the transaction type, the method comprising the steps of identifying transaction servers when they become available to process transactions;
for each identified transaction server, in response to the identification of the transaction server:
for each priority level, from the highest priority level to the lowest priority level, until the identified transaction server is assigned to process a transaction of a selected type:
determining whether assigning the identified transaction server to a transaction of any of the transaction types of the; priority level is necessary to meet the service level goal for that transaction type;
if it is determined that assigning the identified transaction server to a transaction of any of the transaction types of the; priority level is necessary to meet the service level goal for that transaction type, assigning the identified transaction server to process a transaction of one of the transaction types of the priority level; and after the assigned transaction server has completed processing of the transaction to which it was assigned, reidentifying the assigned transaction server as being available to process additional transactions, such that, for transaction types of a higher priority level relative to transaction types of a lower priority level, an available transaction server cannot be assigned to process a transaction of the transaction type of the lower priority level when the service level goal
1. A method in a computer system for distributing transaction servers to process transactions of a plurality of different types,, the transaction types being organized into a plurality of priority levels ordered from highest to lowest, each priority level having one or more transaction types, each transaction type further having a service level goal reflecting the level of service sought for transactions of the transaction type, the method comprising the steps of identifying transaction servers when they become available to process transactions;
for each identified transaction server, in response to the identification of the transaction server:
for each priority level, from the highest priority level to the lowest priority level, until the identified transaction server is assigned to process a transaction of a selected type:
determining whether assigning the identified transaction server to a transaction of any of the transaction types of the; priority level is necessary to meet the service level goal for that transaction type;
if it is determined that assigning the identified transaction server to a transaction of any of the transaction types of the; priority level is necessary to meet the service level goal for that transaction type, assigning the identified transaction server to process a transaction of one of the transaction types of the priority level; and after the assigned transaction server has completed processing of the transaction to which it was assigned, reidentifying the assigned transaction server as being available to process additional transactions, such that, for transaction types of a higher priority level relative to transaction types of a lower priority level, an available transaction server cannot be assigned to process a transaction of the transaction type of the lower priority level when the service level goal
2 for the transaction type of the higher priority level is not being satisfied, thus ensuring that transaction servers are distributed in a manner that satisfies service level goals for transaction types in order from the transaction types of the highest priority level toward the transaction types of the lowest priority level.
2. The method of claim 1 wherein the determining and assigning steps comprise the steps of:
generating an order for the transaction types of the priority level, from first to last;
for each transaction type of the priority level, from first to last, until the identified transaction server is assigned to process a transaction of a selected type:
determining whether assigning the: identified transaction server to a transaction of the transaction type is necessary to meat the service level goal for the transaction type; and if it is determined that assigning the identified transaction server to a transaction of the transaction type is necessary to meet the service level goal for the transaction type, assigning the identified transaction server to process a transaction of the transaction type.
2. The method of claim 1 wherein the determining and assigning steps comprise the steps of:
generating an order for the transaction types of the priority level, from first to last;
for each transaction type of the priority level, from first to last, until the identified transaction server is assigned to process a transaction of a selected type:
determining whether assigning the: identified transaction server to a transaction of the transaction type is necessary to meat the service level goal for the transaction type; and if it is determined that assigning the identified transaction server to a transaction of the transaction type is necessary to meet the service level goal for the transaction type, assigning the identified transaction server to process a transaction of the transaction type.
3. The method of claim 2 wherein the generating step generates an order reflecting the extent to which the service level goals of the transaction types of the priority level presently satisfied.
4. The method of claim 2 wherein the generating step generates an order for the transaction types different from the order generated by an immediately preceding performance of the generating step.
5. An apparatus for distributing transaction servers to process transactions of a plurality of different types, the transaction types being organized into a plurality of priority levels ordered from highest to lowest, each priority level having one or more transaction types, the apparatus comprising:
a service level goal attribution subsystem for attributing a service level goal to each transaction type that reflects the level of service sought for transactions of this type;
an identification subsystem that identifies transaction servers when they become available to process transactions; and a transaction server distribution subsystem that, in response to each transaction server identification by the identification subsystem, assigns the identified transaction server to process a transaction of a type that needs an additional transaction server to meet its service level goal, and whose priority level is at least as high as that of any other transaction type that needs an additional transaction server to meet its service level goal, the identification subsystem reidentifying assigned transaction servers when they complete processing of the transactions to which they were assigned.
a service level goal attribution subsystem for attributing a service level goal to each transaction type that reflects the level of service sought for transactions of this type;
an identification subsystem that identifies transaction servers when they become available to process transactions; and a transaction server distribution subsystem that, in response to each transaction server identification by the identification subsystem, assigns the identified transaction server to process a transaction of a type that needs an additional transaction server to meet its service level goal, and whose priority level is at least as high as that of any other transaction type that needs an additional transaction server to meet its service level goal, the identification subsystem reidentifying assigned transaction servers when they complete processing of the transactions to which they were assigned.
6. A computer memory containing a transaction server allocation data structure usable to allocate an available transaction server to processing one of a plurality of transaction types, the data structure comprising, for each transaction type:
an indication of the priority of transactions of the transaction type relative to the priorities of transactions of other transaction types; and an indication of a service level goal reflecting the level of service sought for transactions of the transaction type, such that the data structure may be used to allocate an available transaction server by, for each transaction type, in descending order of the priorities indicated for the transactions of the transaction types, determining whether the available transaction server is needed in order to meet the service level goal indicated for the transaction type, and assigning the available transaction server to the highest priority transaction type for which the available transaction server is determined to be needed.
an indication of the priority of transactions of the transaction type relative to the priorities of transactions of other transaction types; and an indication of a service level goal reflecting the level of service sought for transactions of the transaction type, such that the data structure may be used to allocate an available transaction server by, for each transaction type, in descending order of the priorities indicated for the transactions of the transaction types, determining whether the available transaction server is needed in order to meet the service level goal indicated for the transaction type, and assigning the available transaction server to the highest priority transaction type for which the available transaction server is determined to be needed.
7. The computer memory of claim 6 wherein at least one pair of priority indications contained in the data structure indicate: the same level of priority.
8. The computer memory of claim 6 wherein at least a portion of the service level goal indications indicate a service level goal specifying a target rate at which transactions of the transaction type are to be assigned to available transaction servers.
9. The computer memory of claim 6 wherein at least a portion of the service level goal indications indicate a service level goal specifying a target minimum amount of time in which transactions of the transaction type are to be assigned to available transaction servers.
10. The computer memory of claim 6 wherein at least a portion of the service level goal indications indicate a service level goal specifying a target rate at which transactions of the transaction type are to be completed by the available transaction servers.
11. The computer memory of claim 6 wherein at least a portion of the service level goal indications indicate a service level goal specifying a target maximum amount of time in which processing of transactions of the transaction type are to be completed by the available transaction servers.
12. A computer-readable medium whose contents cause a computer system to distribute available transaction servers among a plurality of transaction processing applications each having the same priority, each application further having a service level goal indicating the service level sought for the application, by performing the steps of, when a transaction server becomes available:
establishing an order for the applications, from highest to lowest;
for each application, in the established order, until the available transaction server is assigned to an application;
offering the available transaction server to the application;
under the control of the application, determining whether the available transaction server is needed by the application in order for the application to meet its service level goal; and if it is determined that the available transaction server is needed by the application in order for the application to meet its service level goal, assigning the available transaction server to the application.
establishing an order for the applications, from highest to lowest;
for each application, in the established order, until the available transaction server is assigned to an application;
offering the available transaction server to the application;
under the control of the application, determining whether the available transaction server is needed by the application in order for the application to meet its service level goal; and if it is determined that the available transaction server is needed by the application in order for the application to meet its service level goal, assigning the available transaction server to the application.
13. The computer-readable medium of claim 12 wherein the contents of the computer readable medium further cause the computer system to perform the step of, before the establishing step, determining a current service level of each application that reflects the performance of the application, and wherein the establishing step establishes an order based upon a comparison of current service level to the service level goal for each application.
14. The computer readable medium of claim 12, further comprising the step of, before establishing the step, determining an expected service level of each application that reflects the projected future performance of the application, and wherein the establishing step establishes an order based upon a comparison of the expected service level to the service level goal for each application.
15. The computer-readable medium of claim 12 wherein each iteration of the establishing step establishes an order that is rotated one position from the order established from the previous iteration of the establishing step, such that the applications each have a comparable opportunity to obtain available transaction servers.
16. The computer readable medium of claim 12 wherein a selected one of the applications has a server qualification standard, and wherein only a portion of the transaction servers have qualification credentials satisfying the server qualification standard, and wherein the determining step for the selected application includes the step of determining whether the available transaction server has qualification credentials satisfying the server qualification standard.
17. A method in a computer system for distributing reassignable transaction processing servers among a plurality of transaction processing applications, the method comprising the steps of:
defining for a first application of the plurality a transaction assignment service level goal reflecting the performance sought for t:he first application in assigning transactions to a server;
defining for a second application of the plurality a transaction completion service level goal reflecting the performance sought for the second application in completing the processing transactions;
when a server is available for distribution:
assessing the demand for an additional server by the first application based on the transaction assignment service level goal defined for the first application;
assessing the demand for an additional server by the second application based on the transaction completion service level goal defined for the second application;
comparing the assessments; and based upon the results of the comparing step, selecting between the first and second application for distribution of the available server.
defining for a first application of the plurality a transaction assignment service level goal reflecting the performance sought for t:he first application in assigning transactions to a server;
defining for a second application of the plurality a transaction completion service level goal reflecting the performance sought for the second application in completing the processing transactions;
when a server is available for distribution:
assessing the demand for an additional server by the first application based on the transaction assignment service level goal defined for the first application;
assessing the demand for an additional server by the second application based on the transaction completion service level goal defined for the second application;
comparing the assessments; and based upon the results of the comparing step, selecting between the first and second application for distribution of the available server.
18. The method of claim 17 wherein the first application is for processing telephone call transactions, and wherein the step of defining a transaction assignment level goal defines a transaction assignment service level goal reflecting the performance sought in assigning telephone call transactions to servers.
19. The method of claim 18 wherein the second application is for processing transactions other than telephone calls, and wherein the step of defining a transaction completion service goal defines a transaction completion service goal reflecting the performance sought in assigning transactions other than telephone calls to servers.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US7715798P | 1998-03-06 | 1998-03-06 | |
US60/077,157 | 1998-03-06 | ||
US09/089,848 | 1998-06-03 | ||
US09/089,848 US6226377B1 (en) | 1998-03-06 | 1998-06-03 | Prioritized transaction server allocation |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2264464A1 CA2264464A1 (en) | 1999-09-06 |
CA2264464C true CA2264464C (en) | 2006-01-24 |
Family
ID=26758959
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002264464A Expired - Fee Related CA2264464C (en) | 1998-03-06 | 1999-03-05 | Prioritized transaction server allocation |
Country Status (3)
Country | Link |
---|---|
US (1) | US6226377B1 (en) |
CA (1) | CA2264464C (en) |
GB (1) | GB2338093B (en) |
Families Citing this family (126)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6477559B1 (en) * | 1998-08-21 | 2002-11-05 | Aspect Communications Corporation | Method and apparatus for remotely accessing an automatic transaction processing system |
US7295669B1 (en) | 1999-01-21 | 2007-11-13 | Avaya Technology Corp. | Call center telephone and data flow connection system |
US6560649B1 (en) * | 1999-02-10 | 2003-05-06 | Avaya Technology Corp. | Hierarchical service level remediation for competing classes based upon achievement of service level goals |
US7200219B1 (en) | 1999-02-10 | 2007-04-03 | Avaya Technology Corp. | Dynamically allocating server resources to competing classes of work based upon achievement of service goals |
US6571270B1 (en) * | 1999-03-15 | 2003-05-27 | International Business Machines Corporation | Timeout detection facility |
GB2349715B (en) * | 1999-05-05 | 2003-10-01 | Mitel Corp | Quotation mechanism for service environments |
US7401112B1 (en) * | 1999-05-26 | 2008-07-15 | Aspect Communication Corporation | Methods and apparatus for executing a transaction task within a transaction processing system employing symmetric multiprocessors |
US6470406B1 (en) * | 1999-06-25 | 2002-10-22 | International Business Machines Corporation | Managing isochronous processes in a heterogenous work environment |
JP2001134657A (en) * | 1999-11-05 | 2001-05-18 | Sony Corp | Device and method for coping with inquiry, computer readable information recording medium with program having function of coping with inquiry recorded thereon and transmitting medium transmitting program having function of copying with inquiry |
CA2328335A1 (en) * | 2000-01-24 | 2001-07-24 | Avaya Technology Corp. | Automated transaction distribution system and method allowing selection of agents by transaction initiators |
US7117263B1 (en) | 2000-02-01 | 2006-10-03 | Hewlett-Packard Development Company, L.P. | Apparatus and method for processing requests from an external queue in a TCP/IP-based application system |
US6742016B1 (en) * | 2000-03-24 | 2004-05-25 | Hewlett-Packard Devolpment Company, L.P. | Request acceptor for a network application system and a method thereof |
JP3535068B2 (en) * | 2000-03-30 | 2004-06-07 | 富士通株式会社 | Multi-channel processing control apparatus and multi-channel processing control method |
US6956941B1 (en) * | 2000-04-12 | 2005-10-18 | Austin Logistics Incorporated | Method and system for scheduling inbound inquiries |
US7739325B1 (en) | 2000-04-24 | 2010-06-15 | Aspect Software, Inc. | Apparatus and method for extensible real-time workflows |
US7221377B1 (en) | 2000-04-24 | 2007-05-22 | Aspect Communications | Apparatus and method for collecting and displaying information in a workflow system |
US7844504B1 (en) | 2000-04-27 | 2010-11-30 | Avaya Inc. | Routing based on the contents of a shopping cart |
US7577683B2 (en) * | 2000-06-08 | 2009-08-18 | Ingenuity Systems, Inc. | Methods for the construction and maintenance of a knowledge representation system |
US6741986B2 (en) * | 2000-12-08 | 2004-05-25 | Ingenuity Systems, Inc. | Method and system for performing information extraction and quality control for a knowledgebase |
US6772160B2 (en) * | 2000-06-08 | 2004-08-03 | Ingenuity Systems, Inc. | Techniques for facilitating information acquisition and storage |
US7103173B2 (en) | 2001-07-09 | 2006-09-05 | Austin Logistics Incorporated | System and method for preemptive goals based routing of contact records |
US7502460B2 (en) | 2006-11-20 | 2009-03-10 | Austin Logistics Incorporated | Method and system for distributing outbound telephone calls |
US7142662B2 (en) | 2000-07-11 | 2006-11-28 | Austin Logistics Incorporated | Method and system for distributing outbound telephone calls |
JP4294879B2 (en) * | 2001-02-05 | 2009-07-15 | 株式会社日立製作所 | Transaction processing system having service level control mechanism and program therefor |
JP4230673B2 (en) * | 2001-02-22 | 2009-02-25 | 富士通株式会社 | Service management device |
EP1374050A1 (en) * | 2001-03-29 | 2004-01-02 | BRITISH TELECOMMUNICATIONS public limited company | Legacy system interface |
JP2002297900A (en) | 2001-03-30 | 2002-10-11 | Ibm Japan Ltd | Control system for reception by businesses, user side terminal device, reception side terminal device, management server queue monitoring device, method of allocating reception side terminals, and storage medium |
US7715546B2 (en) * | 2001-07-09 | 2010-05-11 | Austin Logistics Incorporated | System and method for updating contact records |
US7054434B2 (en) | 2001-07-09 | 2006-05-30 | Austin Logistics Incorporated | System and method for common account based routing of contact records |
US6990593B2 (en) * | 2001-07-31 | 2006-01-24 | Hewlett-Packard Development Company, L.P. | Method for diverting power reserves and shifting activities according to activity priorities in a server cluster in the event of a power interruption |
US7685126B2 (en) | 2001-08-03 | 2010-03-23 | Isilon Systems, Inc. | System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system |
US6823382B2 (en) * | 2001-08-20 | 2004-11-23 | Altaworks Corporation | Monitoring and control engine for multi-tiered service-level management of distributed web-application servers |
US8793073B2 (en) | 2002-02-04 | 2014-07-29 | Ingenuity Systems, Inc. | Drug discovery methods |
JP4594622B2 (en) * | 2002-02-04 | 2010-12-08 | インジェヌイティ システムズ インコーポレイテッド | Drug discovery method |
US7336779B2 (en) * | 2002-03-15 | 2008-02-26 | Avaya Technology Corp. | Topical dynamic chat |
US20040044749A1 (en) * | 2002-08-30 | 2004-03-04 | Harkin Arthur S. | Method and system for controlling class of service admission to a server |
JP4077352B2 (en) * | 2003-03-31 | 2008-04-16 | 株式会社日立製作所 | Load balancing method, execution system thereof, and processing program thereof |
US7426267B1 (en) * | 2003-09-04 | 2008-09-16 | Contactual, Inc. | Declarative ACD routing with service level optimization |
US8094804B2 (en) | 2003-09-26 | 2012-01-10 | Avaya Inc. | Method and apparatus for assessing the status of work waiting for service |
US20050071241A1 (en) * | 2003-09-26 | 2005-03-31 | Flockhart Andrew D. | Contact center resource allocation based on work bidding/auction |
US7770175B2 (en) * | 2003-09-26 | 2010-08-03 | Avaya Inc. | Method and apparatus for load balancing work on a network of servers based on the probability of being serviced within a service time goal |
US7581008B2 (en) * | 2003-11-12 | 2009-08-25 | Hewlett-Packard Development Company, L.P. | System and method for allocating server resources |
US7886055B1 (en) | 2005-04-28 | 2011-02-08 | Hewlett-Packard Development Company, L.P. | Allocating resources in a system having multiple tiers |
US8457300B2 (en) * | 2004-02-12 | 2013-06-04 | Avaya Inc. | Instant message contact management in a contact center |
US7729490B2 (en) * | 2004-02-12 | 2010-06-01 | Avaya Inc. | Post-termination contact management |
US7885401B1 (en) | 2004-03-29 | 2011-02-08 | Avaya Inc. | Method and apparatus to forecast the availability of a resource |
US7734032B1 (en) | 2004-03-31 | 2010-06-08 | Avaya Inc. | Contact center and method for tracking and acting on one and done customer contacts |
US7328265B2 (en) * | 2004-03-31 | 2008-02-05 | International Business Machines Corporation | Method and system to aggregate evaluation of at least one metric across a plurality of resources |
US7953859B1 (en) | 2004-03-31 | 2011-05-31 | Avaya Inc. | Data model of participation in multi-channel and multi-party contacts |
US8000989B1 (en) | 2004-03-31 | 2011-08-16 | Avaya Inc. | Using true value in routing work items to resources |
US8234141B1 (en) | 2004-09-27 | 2012-07-31 | Avaya Inc. | Dynamic work assignment strategies based on multiple aspects of agent proficiency |
US7949121B1 (en) | 2004-09-27 | 2011-05-24 | Avaya Inc. | Method and apparatus for the simultaneous delivery of multiple contacts to an agent |
US7949123B1 (en) | 2004-09-28 | 2011-05-24 | Avaya Inc. | Wait time predictor for long shelf-life work |
US7657021B2 (en) * | 2004-09-29 | 2010-02-02 | Avaya Inc. | Method and apparatus for global call queue in a global call center |
US8055711B2 (en) | 2004-10-29 | 2011-11-08 | Emc Corporation | Non-blocking commit protocol systems and methods |
US8238350B2 (en) | 2004-10-29 | 2012-08-07 | Emc Corporation | Message batching with checkpoints systems and methods |
US8051425B2 (en) * | 2004-10-29 | 2011-11-01 | Emc Corporation | Distributed system with asynchronous execution systems and methods |
US20060233345A1 (en) * | 2005-04-18 | 2006-10-19 | Michael Frediani | Automatic contact distributor with workflow system integration |
US7817796B1 (en) | 2005-04-27 | 2010-10-19 | Avaya Inc. | Coordinating work assignments for contact center agents |
US7809127B2 (en) | 2005-05-26 | 2010-10-05 | Avaya Inc. | Method for discovering problem agent behaviors |
US7779042B1 (en) | 2005-08-08 | 2010-08-17 | Avaya Inc. | Deferred control of surrogate key generation in a distributed processing architecture |
US7881450B1 (en) | 2005-09-15 | 2011-02-01 | Avaya Inc. | Answer on hold notification |
US8577015B2 (en) * | 2005-09-16 | 2013-11-05 | Avaya Inc. | Method and apparatus for the automated delivery of notifications to contacts based on predicted work prioritization |
US7822587B1 (en) | 2005-10-03 | 2010-10-26 | Avaya Inc. | Hybrid database architecture for both maintaining and relaxing type 2 data entity behavior |
US10572879B1 (en) | 2005-10-03 | 2020-02-25 | Avaya Inc. | Agent driven media-agnostic work item grouping and sharing over a consult medium |
US8116446B1 (en) | 2005-10-03 | 2012-02-14 | Avaya Inc. | Agent driven work item awareness for tuning routing engine work-assignment algorithms |
US8073129B1 (en) | 2005-10-03 | 2011-12-06 | Avaya Inc. | Work item relation awareness for agents during routing engine driven sub-optimal work assignments |
US8411843B1 (en) | 2005-10-04 | 2013-04-02 | Avaya Inc. | Next agent available notification |
US7752230B2 (en) | 2005-10-06 | 2010-07-06 | Avaya Inc. | Data extensibility using external database tables |
US7787609B1 (en) | 2005-10-06 | 2010-08-31 | Avaya Inc. | Prioritized service delivery based on presence and availability of interruptible enterprise resources with skills |
US7797283B2 (en) * | 2005-10-21 | 2010-09-14 | Isilon Systems, Inc. | Systems and methods for maintaining distributed data |
US7788303B2 (en) * | 2005-10-21 | 2010-08-31 | Isilon Systems, Inc. | Systems and methods for distributed system scanning |
US7551572B2 (en) | 2005-10-21 | 2009-06-23 | Isilon Systems, Inc. | Systems and methods for providing variable protection |
US7917474B2 (en) | 2005-10-21 | 2011-03-29 | Isilon Systems, Inc. | Systems and methods for accessing and updating distributed data |
US8238541B1 (en) | 2006-01-31 | 2012-08-07 | Avaya Inc. | Intent based skill-set classification for accurate, automatic determination of agent skills |
US7848261B2 (en) | 2006-02-17 | 2010-12-07 | Isilon Systems, Inc. | Systems and methods for providing a quiescing protocol |
US8737173B2 (en) | 2006-02-24 | 2014-05-27 | Avaya Inc. | Date and time dimensions for contact center reporting in arbitrary international time zones |
US8442197B1 (en) | 2006-03-30 | 2013-05-14 | Avaya Inc. | Telephone-based user interface for participating simultaneously in more than one teleconference |
US7756898B2 (en) | 2006-03-31 | 2010-07-13 | Isilon Systems, Inc. | Systems and methods for notifying listeners of events |
WO2008014495A2 (en) * | 2006-07-28 | 2008-01-31 | Ingenuity Systems, Inc. | Genomics based targeted advertising |
US7936867B1 (en) | 2006-08-15 | 2011-05-03 | Avaya Inc. | Multi-service request within a contact center |
US7590652B2 (en) * | 2006-08-18 | 2009-09-15 | Isilon Systems, Inc. | Systems and methods of reverse lookup |
US7882071B2 (en) | 2006-08-18 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7822932B2 (en) | 2006-08-18 | 2010-10-26 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7899800B2 (en) | 2006-08-18 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7680842B2 (en) | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7680836B2 (en) | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US8391463B1 (en) | 2006-09-01 | 2013-03-05 | Avaya Inc. | Method and apparatus for identifying related contacts |
US8938063B1 (en) | 2006-09-07 | 2015-01-20 | Avaya Inc. | Contact center service monitoring and correcting |
US8811597B1 (en) | 2006-09-07 | 2014-08-19 | Avaya Inc. | Contact center performance prediction |
US8855292B1 (en) | 2006-09-08 | 2014-10-07 | Avaya Inc. | Agent-enabled queue bypass to agent |
US7835514B1 (en) | 2006-09-18 | 2010-11-16 | Avaya Inc. | Provide a graceful transfer out of active wait treatment |
US20080120164A1 (en) * | 2006-11-17 | 2008-05-22 | Avaya Technology Llc | Contact center agent work awareness algorithm |
US20080155191A1 (en) * | 2006-12-21 | 2008-06-26 | Anderson Robert J | Systems and methods for providing heterogeneous storage systems |
US8286029B2 (en) | 2006-12-21 | 2012-10-09 | Emc Corporation | Systems and methods for managing unavailable storage devices |
US7593938B2 (en) | 2006-12-22 | 2009-09-22 | Isilon Systems, Inc. | Systems and methods of directory entry encodings |
US20080162246A1 (en) * | 2007-01-03 | 2008-07-03 | International Business Machines Corporation | Method and system for contract based call center and/or contact center management |
US8767944B1 (en) | 2007-01-03 | 2014-07-01 | Avaya Inc. | Mechanism for status and control communication over SIP using CODEC tunneling |
US7509448B2 (en) * | 2007-01-05 | 2009-03-24 | Isilon Systems, Inc. | Systems and methods for managing semantic locks |
US8966080B2 (en) | 2007-04-13 | 2015-02-24 | Emc Corporation | Systems and methods of managing resource utilization on a threaded computer system |
US7900015B2 (en) | 2007-04-13 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods of quota accounting |
US7779048B2 (en) | 2007-04-13 | 2010-08-17 | Isilon Systems, Inc. | Systems and methods of providing possible value ranges |
US7747705B1 (en) | 2007-05-08 | 2010-06-29 | Avaya Inc. | Method to make a discussion forum or RSS feed a source for customer contact into a multimedia contact center that is capable of handling emails |
US7882068B2 (en) * | 2007-08-21 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for adaptive copy on write |
US8504534B1 (en) | 2007-09-26 | 2013-08-06 | Avaya Inc. | Database structures and administration techniques for generalized localization of database items |
US8856182B2 (en) | 2008-01-25 | 2014-10-07 | Avaya Inc. | Report database dependency tracing through business intelligence metadata |
US8385532B1 (en) | 2008-05-12 | 2013-02-26 | Avaya Inc. | Real-time detective |
US8831206B1 (en) | 2008-05-12 | 2014-09-09 | Avaya Inc. | Automated, data-based mechanism to detect evolution of employee skills |
JP5088234B2 (en) * | 2008-05-23 | 2012-12-05 | 富士通株式会社 | Message association processing apparatus, method, and program |
US10375244B2 (en) * | 2008-08-06 | 2019-08-06 | Avaya Inc. | Premises enabled mobile kiosk, using customers' mobile communication device |
US8116237B2 (en) | 2008-09-26 | 2012-02-14 | Avaya Inc. | Clearing house for publish/subscribe of status data from distributed telecommunications systems |
US8621011B2 (en) * | 2009-05-12 | 2013-12-31 | Avaya Inc. | Treatment of web feeds as work assignment in a contact center |
US8964958B2 (en) | 2009-05-20 | 2015-02-24 | Avaya Inc. | Grid-based contact center |
US8644491B2 (en) * | 2009-08-21 | 2014-02-04 | Avaya Inc. | Mechanism for multisite service state description |
US8385533B2 (en) | 2009-09-21 | 2013-02-26 | Avaya Inc. | Bidding work assignment on conference/subscribe RTP clearing house |
US8565386B2 (en) | 2009-09-29 | 2013-10-22 | Avaya Inc. | Automatic configuration of soft phones that are usable in conjunction with special-purpose endpoints |
US9516069B2 (en) | 2009-11-17 | 2016-12-06 | Avaya Inc. | Packet headers as a trigger for automatic activation of special-purpose softphone applications |
JP5515810B2 (en) * | 2010-02-05 | 2014-06-11 | 日本電気株式会社 | Load control device |
US20110197206A1 (en) * | 2010-02-11 | 2011-08-11 | International Business Machines Corporation | System, Method And Program Product For Analyses Based On Agent-Customer Interactions And Concurrent System Activity By Agents |
US8306212B2 (en) | 2010-02-19 | 2012-11-06 | Avaya Inc. | Time-based work assignments in automated contact distribution |
US20120278513A1 (en) * | 2011-02-01 | 2012-11-01 | Michel Prevost | Priority scheduling for multi-channel context aware communication technology |
US8675860B2 (en) | 2012-02-16 | 2014-03-18 | Avaya Inc. | Training optimizer for contact center agents |
CA2783339A1 (en) * | 2012-06-04 | 2013-12-04 | Source Evolution | Priority scheduling for multi-channel context aware communication technology |
US8566414B2 (en) | 2012-10-12 | 2013-10-22 | Freedomone Mobile, Inc. | Systems and methods for subscription management in a multi-channel context aware communication environment |
US11100092B2 (en) * | 2019-06-17 | 2021-08-24 | Bank Of America Corporation | Database tool |
US11379267B1 (en) * | 2020-03-31 | 2022-07-05 | Teradata Us, Inc. | Automatic resource allocation design for satisfying service level goals of mixed workload queries in a database system |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5911134A (en) * | 1990-10-12 | 1999-06-08 | Iex Corporation | Method for planning, scheduling and managing personnel |
US5325292A (en) * | 1990-10-12 | 1994-06-28 | Crockett Gary B | Tour/schedule generation for a force management system |
US5289368A (en) * | 1990-10-12 | 1994-02-22 | Iex Corporation | Force management system user interface |
US5185780A (en) * | 1990-10-12 | 1993-02-09 | Tex Corporation | Method for predicting agent requirements in a force management system |
US5504894A (en) | 1992-04-30 | 1996-04-02 | International Business Machines Corporation | Workload manager for achieving transaction class response time goals in a multiprocessing system |
DK0645702T3 (en) * | 1993-09-24 | 2000-11-06 | Siemens Ag | Method of load equalization in a multiprocessor system |
US5537542A (en) * | 1994-04-04 | 1996-07-16 | International Business Machines Corporation | Apparatus and method for managing a server workload according to client performance goals in a client/server data processing system |
US5473773A (en) | 1994-04-04 | 1995-12-05 | International Business Machines Corporation | Apparatus and method for managing a data processing system workload according to two or more distinct processing goals |
US5675739A (en) * | 1995-02-03 | 1997-10-07 | International Business Machines Corporation | Apparatus and method for managing a distributed data processing system workload according to a plurality of distinct processing goal types |
US5603029A (en) * | 1995-06-07 | 1997-02-11 | International Business Machines Corporation | System of assigning work requests based on classifying into an eligible class where the criteria is goal oriented and capacity information is available |
US5974462A (en) * | 1997-03-28 | 1999-10-26 | International Business Machines Corporation | Method and apparatus for controlling the number of servers in a client/server system |
-
1998
- 1998-06-03 US US09/089,848 patent/US6226377B1/en not_active Expired - Lifetime
-
1999
- 1999-03-05 CA CA002264464A patent/CA2264464C/en not_active Expired - Fee Related
- 1999-03-05 GB GB9905212A patent/GB2338093B/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
GB2338093A (en) | 1999-12-08 |
US6226377B1 (en) | 2001-05-01 |
GB9905212D0 (en) | 1999-04-28 |
CA2264464A1 (en) | 1999-09-06 |
GB2338093B (en) | 2002-12-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2264464C (en) | Prioritized transaction server allocation | |
US6496580B1 (en) | Method and apparatus for servicing queued requests | |
US7200219B1 (en) | Dynamically allocating server resources to competing classes of work based upon achievement of service goals | |
US6771760B1 (en) | Callback imitation as incoming calls | |
USRE46467E1 (en) | Method and system for distributing outbound telephone calls | |
CA2265248C (en) | Dynamic staffing of service centers to provide substantially zero-delay service | |
US6766012B1 (en) | System and method for allocating agent resources to a telephone call campaign based on agent productivity | |
USRE44979E1 (en) | System and method for common account based routing of contact records | |
US7386850B2 (en) | Arrangement for scheduling tasks based on probability of availability of resources at a future point in time | |
US6718330B1 (en) | Predictive internet automatic work distributor (Pre-IAWD) and proactive internet automatic work distributor (Pro-IAWD) | |
US7761323B2 (en) | Method and system for scheduling a customer service callback | |
US7817796B1 (en) | Coordinating work assignments for contact center agents | |
US20060015388A1 (en) | Method and apparatus for supporting individualized selection rules for resource allocation | |
US8036372B2 (en) | Methods and apparatus for dynamically reallocating a preferred request to one or more generic queues | |
US20040057570A1 (en) | Method and apparatus for assigning priorities by applying dynamically-changeable business rules | |
US20030158883A1 (en) | Message processing | |
CN113127171A (en) | Techniques for behavioral pairing in a task distribution system | |
US6636599B1 (en) | Reserving resources for anticipated work items via simulated work items | |
US6813636B1 (en) | Method and apparatus for routing a transaction within a network environment | |
US6973176B1 (en) | Method and apparatus for rotating auto reserve agents | |
US10860371B2 (en) | Techniques for adapting behavioral pairing to runtime conditions in a task assignment system | |
GB2400210A (en) | Allocating resources in a call centre | |
CN115244554A (en) | Techniques for sharing control of distributed tasks between an external pairing system and a task distribution system having an internal pairing system | |
US8782313B2 (en) | Method and apparatus for enterprise brokering of user-controlled availability | |
CN115428424A (en) | Techniques for distributing tasks in a task distribution system having an external pairing system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |