CA2264464C - Prioritized transaction server allocation - Google Patents

Prioritized transaction server allocation Download PDF

Info

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
Application number
CA002264464A
Other languages
French (fr)
Other versions
CA2264464A1 (en
Inventor
Norman J. Donaghue, Jr.
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avaya Inc
Original Assignee
Mosaix Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mosaix Inc filed Critical Mosaix Inc
Publication of CA2264464A1 publication Critical patent/CA2264464A1/en
Application granted granted Critical
Publication of CA2264464C publication Critical patent/CA2264464C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation 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/5038Allocation 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/5021Priority

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.
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.

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
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.
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.
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.
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.
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.
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.
CA002264464A 1998-03-06 1999-03-05 Prioritized transaction server allocation Expired - Fee Related CA2264464C (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

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