System and method for preemptive goals based routing of contact records

RELATED PATENT APPLICATION

0001This application is a continuation-in-part of U.S. patent application Ser. No. 09/901,749 filed on Jul. 9, 2001 and entitled “Method and System for Distributing Outbound Telephone Calls.”

0002This application is a reissue of application Ser. No. 11/448,230, U.S. Pat. No. 7,158,629, which is a continuation of application Ser. No. 10/095,513, filed on Mar. 12, 2002 now U.S. Pat No. 7,103,173 entitled “System and Method for Preemptive Goals Based Routing of Contact Records” and naming Richard Rodenbusch and Daniel N. Duncan as inventors.

0003This application is a continuation of U.S. patent application Ser. No. 10/095,513, filed on Mar. 12, 2002, now U.S. Pat. No. 7,103,173 and entitled “System and Method for Preemptive Goals Based Routing of Contact Records, which is a continuation-in-part of U.S. patent application Ser. No. 09/901,749, filed on Jul. 9, 2001, now U.S. Pat. No. 7,142,662 and entitled “Method and System for Distributing Outbound Telephone Calls,” which claims the benefit of U.S. Provisional Patent Application 60/217,292, filed Jul. 11, 2000, and entitled “Method and System for Distributing Outbound Telephone Calls.”

TECHNICAL FIELD OF THE INVENTION

0004This invention relates to the field of telephony, computer networks, and customer relationship management, and more particularly to a system and method for preemptive goals based routing of contact records.

BACKGROUND OF THE INVENTION

0005Customer contact centers represent the front line for customer service, marketing operations, and debt collection for many businesses. Typical centers receive or make hundreds of telephone calls, emails, and Internet chat requests per day with the aid of automated telephony and Internet equipment. For instance, predictive dialers such as the MOSAIX Predictive Dialing System (“PDS”) manufactured by Avaya Incorporated automatically dial outbound telephone calls to contact individuals and then transfer the contacted individuals to agents so the agent can talk with the individual.

0006Devices such as dialing devices, email servers, chat servers, VOIP servers, telephony servers, and web servers allow agents to save time in contacting customers and receiving requests from customers. Dialing devices such as predictive dialers save time for the agent placing the call because the dialing device and not the agent dials the telephone number and agents' time is not wasted with unanswered calls or answering machines. Predictive dialers also spread the outbound telephone calls evenly among all the agents working from the dialing device so that the agents share the workload equally and no agents sit idle while others have too many telephone calls to place. Predictive dialers are also a significant component of customer relationship management (CRM) systems which extend the efficiency gained from predictive dialers to other contact channels such as email and live Internet chat.

0007Many businesses are increasing their marketing efforts, customer service programs, and bad debt collection efforts by having multiple customer contact centers or call centers or multiple devices located at a single site to serve more customers. Typically, when businesses have multiple sites, the centers are located in different geographic locations which makes coordination of customer contact strategies difficult.

0008Thus businesses generally manage call centers individually, with separate staffing, calling strategies, goals, and functions. Generally, a contact list is divided into as many parts as there are call centers or dialers with each call center receiving its own section of the calling list. Although this segmentation distributes work, coordination of strategy for outbound calling is difficult since each call center is responsible for its own section of the calling list and has no knowledge of the other call centers' progression with their own calling lists. For instance, if a call center goes down and cannot make outbound telephone calls, the other call centers cannot typically address the downed call center's calling list goals and priorities because the other call centers do not have access to the calling list including the telephone numbers actually called.

0009A similar problem occurs with a single call center having multiple CRM systems having multiple devices. Work load segmentation typically occurs at a host level, where each device is assigned a portion of the work load. A host downloads the segmented contact list to the individual dialing devices. If one device fails, the other devices do not know the status of the contacts in the failed device's segment.

0010Difficulties also arise in the routing of outbound calls, call records, or contact records to the agents in a single calling center or multiple calling centers. Typically when routing calls, a call center employs categorization and prioritization routing or load leveling routing. With categorization and prioritization routing, the calls are categorized and prioritized before being sent to the call centers. All of the available call records are organized into distinct groups or pools and each pool of call records is prioritized according to a particular prioritizing scheme. A typical scheme often used at contact centers is to prioritize the inbound calls with the highest priority, live Internet chats second, outbound calls third, and email or other requests last. The agents are segregated into distinct teams and each team receives call records from a particular pool based on the prioritization of the call records.

0011Load leveling routing of call records allows multiple agent teams to work on the same group or pools of records whether the agents are located in the same call center or if the agents are located across multiple call centers. Load leveling routing eliminates the restriction of categorization and prioritization that requires distinct groups of records for agents not working from the same dialing device. This allows for the movement of call records between the agents and call centers.

0012However, none of the above call record routing techniques adjusts the agent and pool workload based on the performance or the performance goals of the call record pools. Generally, if a call record pool is not maintaining a desired performance, manual intervention by a system administrator is required to adjust for the under performing call record pool. In order to address the under performing call record pool, agents must move from one team to another in order to have the ability to access call records from the under performing pool and thereby improve the call record pool performance. But this is a slow process that typically results in agent and call center downtime and often cannot be made quickly enough to respond to current call record pool performance.

0013In addition, such manual intervention decisions to correct under performing call records pools typically require guess work and making decisions without considering all the available options and the effect on the other call record pools. The system administrator must guess as to the effects on the other call record pools when agents are moved from pools maintaining or achieving performance requirements to under performing pools. If agent moves are made incorrectly, then additional pools may start under performing due to the agents that were moved to the under performing pool. Therefore the performance of the call record pools requires constant supervision to ensure that by the end of the calling day the performance requirements for the highest priority pools are satisfied.

SUMMARY OF THE INVENTION

0014Therefore, a need has arisen for a system and method that distributes contact records based on the performance of the pools of contact records.

0015A further need has arisen for a system and method that automatically monitors the performance of the pools and automatically adjusts the distribution of contact records based on the performance of the pools.

0016In accordance with the present invention, a system and method for distributing contact records utilizing goals based routing is provided which substantially eliminates or reduces disadvantages and problems associated with previously developed systems and methods for distributing contact records. A goal module monitors the performance of one or more pools of contact records and automatically modifies the distribution of the contact records from the pools based on the performance of each pool.

0017In accordance with one aspect of the present invention, distribution of contact records utilizing goals based routing is accomplished by a distribution module interfaced with a plurality of devices. The distribution module includes a plurality of pools and a plurality of queues. The distribution module places contact records into the pools, transfers less than all of the contact records to the queues from the pools, and transfers the queues to the devices. Associated with the distribution module is a goal module. The goal module monitors the performance of each pool and modifies which queues the pools transfer contact records to based upon the performance of the pools.

0018In one embodiment, the goal module defines one or more levels of effort for each queue. The levels of effort determine the percentage of contact records that transfers from a pool to a particular queue. The goal module also determines a goal for each pool that reflects the performance of the pool and prioritizes the pools relative to each other. As the agents access the contact records from the queues, the goal module monitors the performance of the pools by calculating a goal status for each pool. The goal module uses the goal status to determine a goal state for each pool. The goal state indicates whether a pool is satisfying the goal. Based upon the goal states for each pool, the goal module modifies which queues the pools transfer contact records to by transferring the levels of effort between the pools and the queues.

0019In an alternate embodiment, the goal states and one or more goal strategies allow for the optimization of the transfer of contact records from the pools to the queues and determine how the goal module modifies which queues the pools transfer contact records to. The goal strategies control how levels of effort between the pools and queues are transferred when a pool is not satisfying the goal. A goal strategy may require the transfer of levels of effort to pools not satisfying their goals or the transfer of levels of effort away from pools not satisfying the goal. The goal module transfers levels of effort in accordance with the goal strategies so that pools having the highest priority maintain or achieve the goals throughout the day.

0020The present invention provides a number of important technical advantages. One important technical advantage is the distribution of contact records based on the performance of the pools. The ability to distribute contact records based on the performance of the pools of contact records allows a call center to operate more efficiently because the call center recognizes when a pool is not sufficiently performing and redistributes the contact record workload to allow for more efficient operation thereby allowing higher priority pools to satisfy performance requirements.

0021Another important technical advantage of the present invention is the distribution of contact records based on the performance of the pools without manual intervention. The goal module monitors the performance of each pool and determines whether a pool is ahead, at, or behind the goal. When a pool is not satisfying a goal, the goal module automatically takes action to modify how the pools transfer contact records to so that the highest priority pools achieve or maintain the goals. Therefore, no manual intervention is required and pools are not adversely affected by the changes. In addition, because no manual intervention is required, there is reduced agent or device downtime when the goal module distributes the contact records based upon the performance of the pools.

0022Another important technical advantage of the present invention is the ability to quickly respond to current pool performance levels. Because the goal module constantly monitors the performance of the pools, the goal module may instantly react to any change in the performance of the pools throughout the day. And because the goal module monitors the performance of all the pools and has the goal states for every pool, when the goal module modifies the distribution of contact records, the goal module takes into account the effects of the modification on the goals for all of the pools so that the highest priority pools achieve or maintain the goals. Therefore, the guess work in distributing contact records based on the performance of the pools is reduced and there are no unexpected results at the end of the day.

BRIEF DESCRIPTION OF THE DRAWINGS

0023For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features, and wherein:

0024<figref idref="DRAWINGS">FIG. 1</figref> depicts a block diagram of plural dialing devices interfaced with a distribution module;

0025<figref idref="DRAWINGS">FIG. 2</figref> illustrates a block diagram of another embodiment of the present invention employing two distribution modules;

0026<figref idref="DRAWINGS">FIG. 3</figref> depicts a flow diagram of a method for distribution outbound telephone calls;

0027<figref idref="DRAWINGS">FIGS. 4a and 4b</figref> illustrate a flow diagram for the population of the pools and queues with call records;

0028<figref idref="DRAWINGS">FIG. 5</figref> depicts a flow diagram of a method for goals based routing of contact records employing a meet-goals goal strategy; and

0029<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flow diagram of a method for goals based routing of contact records employing an exceed-goals goal strategy.

DETAILED DESCRIPTION OF THE INVENTION

0030Preferred embodiments of the present invention are illustrated in the figures, like numeral being used to refer like and corresponding parts of the various drawings.

0031Under previous systems and methods for routing contact records, the redistribution of contact records among the devices and agents based upon the performance of the of the different pools of contact records required manual intervention often involving guesswork as to the effects of performance based changes, the shutting down of the devices, starting a new job on the device, or moving agents between the devices. The goal module of the present invention allows for the routing of contact records across one or more than one device based on the performance of the individual pools of contact records quickly and without manual intervention. The goals based routing of contact records allows for dynamically modifying the distribution of contact records based on the performance of the pools of contact records throughout the day without manual intervention, down time, and guesswork.

0032The present invention allows for the routing and distribution of contact records among a plurality of devices and agents based upon the performance of the different pools of contact records. Contact records include such customer contacts as outbound telephone calls, inbound telephone calls, call records, emails, Internet chat requests, online chat requests, and any other appropriate form of customer contact. Devices include such call center or contact center devices as dialing devices including predictive dialers, email servers, Internet chat servers, VOIP servers, telephony servers, web servers, and any other appropriate call center or contact center devices. In the figures below, reference is made to call records and dialing devices but the present invention equally applies to the other types of contact records and devices listed above.

0033<figref idref="DRAWINGS">FIG. 1</figref> depicts a block diagram for an outbound distribution system <b>100</b> for distributing outbound telephone calls employing goals based routing. A distribution module <b>102</b> interfaces with a first call center <b>104</b>a and a second call center <b>104</b>n. For simplicity, reference is made hereafter to “call center 104” in a generic sense to refer to any instance of a call center, 104a-104n. System <b>100</b> allows call centers <b>104</b>a and <b>104</b>n to operate as a single group of resources rather than two decentralized units, with distribution module <b>102</b> controlling the strategy, workload, and calling efforts for call centers <b>104</b> from a single, central location. In alternative embodiments, distribution module <b>102</b> interfaces with multiple dialing devices at one or more call centers, or one dialing device located in one call center.

0034Call centers <b>104</b> are geographically distributed, each having one or more dialing devices that place telephone calls using information in the call records. Distribution module <b>102</b> operates on a SOLARIS, Linux, or an any other appropriate operating system server and communicates with call centers <b>104</b> via standardized communications links such as Ethernet, the Internet with protocols such as FTP, CORBA, API, and sockets over TCP/IP, asynchronous transfer mode (“ATM”), or any other appropriate communication link.

0035Call centers <b>104</b> each have one or more dialing devices <b>108</b>108a-108n. For simplicity, reference is made hereafter to “dialing devices 108” in a generic sense to refer to any instance of a dialing device 108a-108n. Dialing devices <b>108</b> are predictive dialers such as the MOSAIX PDS manufactured by Avaya Incorporated or other appropriate predictive dialers. In the embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, interfaced to dialing device <b>108</b>a in call center <b>104</b>a are three agents <b>110</b>a, <b>110</b>b, and <b>110</b>c with dialing device <b>108</b>n of call center <b>104</b>n also having three agents <b>110</b>d, <b>110</b>e, and <b>110</b>f interfaced to it. For simplicity, reference is made hereafter to “agents 110” in a generic sense to refer to any instance 110a-110f of an agent. Agents <b>110</b> are workstations where operators or agents speak to the individuals, chat with individuals online, complete emails to, or otherwise contact individuals who are contacted by dialing devices <b>108</b>.

0036Dialing device <b>108</b> dials telephone numbers extracted from the call records. If an individual answers the telephone, dialing device <b>108</b> transfers the telephone call to one of agents <b>110</b> so that the agent can speak with the individual. Dialing devices <b>108</b> therefore improve telephone calling efficiency by dialing the telephone number and transferring the call to an agent only if an individual answers the telephone.

0037System <b>100</b> functions by first having distribution module <b>102</b> acquire the call records that dialing devices <b>108</b> will call. There are several different ways that distribution module <b>102</b> acquires the call records.

0038For instance, host <b>112</b>, which is associated with dialing devices <b>108</b>, stores raw call records. The raw call records contain information including telephone number, account number, individual name and address, and any other appropriate personal information. For example, a raw call record for Joe Smith includes Joe Smith's telephone number, mailing address, account status, account number, account passwords, gender, marital status, number of children, employment status, and yearly income.

0039Host <b>112</b> transfers the raw call records for that day along path <b>114</b>a to call center <b>104</b>a and dialing device <b>108</b>a and along path <b>114</b>b to call center <b>104</b>n and dialing device <b>108</b>n. Distribution module <b>102</b> contacts dialing device <b>108</b>a within call center <b>104</b>a via path <b>116</b>a and dialing device <b>108</b>n within call center <b>104</b>n via path <b>116</b>b. Distribution module <b>102</b> downloads from dialing devices <b>108</b> to call record database <b>118</b> the call records. The call records may contain some but not all of the information from the raw call records. Downloading less than all of the information from the raw call records saves bandwidth and allows for efficient operation of distribution module <b>102</b> because it handles smaller amounts of data. For instance, distribution module <b>102</b> downloads as the call record an individual's name, telephone number, and account number. So the call record for Joe Smith contains Joe Smith's name, his telephone number, and account number.

0040In an alternative embodiment, host <b>112</b> stores the raw call records. Instead of transferring the raw call records to dialing devices <b>108</b>, distribution module <b>102</b> downloads the call records from host <b>112</b> to call record database <b>118</b> via path <b>120</b>.

0041Alternatively, dialing devices <b>108</b> store the raw call records. Therefore, distribution module <b>102</b> contacts call center <b>104</b>a and dialing device <b>108</b>a via path <b>116</b>a and call center <b>104</b>n and dialing device <b>108</b>n via path <b>116</b>b to download the call records to call record database <b>118</b>.

0042Scheduling module <b>122</b> operates to develop and provide optimal calling strategies for the call records including resource optimization, automated statistical modeling and flexible strategy management. For instance, one such scheduling module <b>122</b> is described in U.S. Pat. No. 5,802,161, entitled “Method and System for Optimized Scheduling” issued Sep. 1, 1998, and is hereby incorporated by reference.

0043The integration of scheduling module <b>122</b> is not required for the operation of distribution module <b>102</b> but it affects how distribution module <b>102</b> downloads the call records and what information is contained in the call records. For instance, host <b>112</b> transfers the raw call records to call center <b>104</b>a and dialing device <b>108</b>a via path <b>114</b>a and call center <b>104</b>n and dialing device <b>108</b>n via path <b>114</b>b. Scheduling module <b>122</b> downloads from dialing device <b>108</b>a in call center <b>104</b>a via path <b>124</b>a and from dialing device <b>108</b>n in call center <b>104</b>n via path <b>124</b>b the raw call records. Scheduling module <b>122</b> develops call schedules for the raw call records. Distribution module <b>102</b> downloads the call records including the call schedule from scheduling module <b>122</b> via path <b>124</b>c and stores the call records in call record database <b>118</b>.

0044Alternative embodiments also employ scheduling module <b>122</b> in the delivery of call records to distribution module <b>102</b>. Scheduling module <b>122</b> downloads the raw call records from host <b>112</b> via path <b>126</b>. As before, scheduling module <b>122</b> adds call schedules to the raw call records before distribution module <b>102</b> downloads the call records from scheduling module <b>122</b> via path <b>124</b>c to call record database <b>118</b>.

0045Once distribution module <b>102</b> stores the call records in call record database <b>118</b>, distribution module <b>102</b> organizes and transfers the call records from call record database <b>118</b> to pools <b>128</b>128a, 128b, and/or 128c, which are interfaced with distribution module <b>102</b>. For simplicity, reference is made hereafter to “pool 128” in a generic sense to refer to any instance of a pool 128a-128c. The pools are sets of callable call records specified by distribution module <b>102</b>. Each pool <b>128</b> represents a specific and ordered group of call records. In the embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, there are three pools <b>128</b>a, <b>128</b>b, and <b>128</b>c. In alternative embodiments there can be more than three or less than three pools.

0046Distribution module <b>102</b> then transfers less than all of the call records from pools <b>128</b> to queues <b>130</b>130a, 130b, 130c, and 130d. For simplicity, reference is made hereafter to “queue 130” in a generic sense to refer to any instance of a queue 130a-130d. Interfaced with pools <b>128</b> are queues <b>130</b>a, <b>130</b>b, <b>130</b>c, and <b>130</b>d. A queue is a set of rules for selecting call records from pools having the necessary and sufficient information describing the exact method of transferring call records to dialing devices <b>108</b> and any call records assigned to but not yet transferred to dialing devices <b>108</b> for dialing devices <b>108</b> to call. Distribution module <b>102</b> attaches each queue <b>130</b> to a particular dialing device <b>108</b> and monitors each dialing device. As necessary, distribution module <b>102</b> transfers call records from pools <b>128</b> in accordance with the configuration of queues <b>130</b> which includes selection rules, time of day, time of week, number of calls completed, and number of call records sent. Queues <b>130</b> then transfer the call records to their assigned dialing devices <b>108</b>. For instance, distribution module <b>102</b> transfers call records according to the configuration of queues <b>130</b>a and <b>130</b>b to dialing device <b>108</b>a of call center <b>104</b>a and according to the configuration of queues <b>130</b>c and <b>130</b>d to dialing device <b>108</b>n of call center <b>104</b>n.

0047In addition, each queue <b>130</b> is associated with a single campaign for the dialing device to which it is assigned. A campaign is an outbound job calling on dialing device <b>108</b> that can receive additional call records for calling while the outbound calling job is active. Normally, a campaign on dialing device <b>108</b> continues to run until manually stopped or when it runs out of call records to dial.

0048Pools <b>128</b> can satisfy transfer requests for call records for one or more than one queue <b>130</b>. For example, pool <b>128</b>a transfers call records to queue <b>130</b>a, pool <b>128</b>b transfers call records to queues <b>130</b>b and <b>130</b>c, and pool <b>128</b>c transfers call records to queue <b>130</b>d. In addition, distribution module <b>102</b> can change the queues which request call records from pools <b>128</b> throughout the day and in the middle of outbound calling campaigns. For instance, if dialing device <b>108</b>n located in call center <b>104</b>n calls all the call records in pool <b>128</b>c, then distribution module <b>102</b> can request that pools <b>128</b>a and <b>128</b>b transfer call records to queue <b>130</b>d.

0049Distribution module <b>102</b> transfers the call records to pools <b>128</b>, transfers less than all of the call records from pools <b>128</b> to queues <b>130</b>, and transfers queues <b>130</b> to dialing devices <b>108</b> before dialing devices <b>108</b> begin their daily calling routines. At the beginning of the day, distribution module <b>102</b> transfers enough call records from pools <b>128</b> to queues <b>130</b> to allow for dialing devices <b>108</b> to place calls for fifteen, thirty, sixty minutes, or an appropriate amount of time to place calls. Distribution module <b>102</b> monitors the calls placed by dialing devices <b>108</b> as well as the number of call records remaining to be called to determine how busy dialing devices <b>108</b> are and when and how many additional call records to transfer from pools <b>128</b> to queues <b>130</b>. The monitoring of queues <b>130</b> and the transferring of additional call records from pools <b>128</b> to queues <b>130</b> allows for real-time movement of call records from distribution module <b>102</b> to dialing devices <b>108</b> throughout the day. For instance, as soon as dialing device <b>108</b>a is about to finish calling the call records in the campaign assigned to queue <b>130</b>a, distribution module <b>102</b> transfers additional call records from pool <b>128</b>a to queue <b>130</b>a so that dialing device <b>108</b>a maintains a steady and level flow of work.

0050Dialing devices <b>108</b> also track the call attempt results of every call placed by dialing devices <b>108</b>. The call attempt results include whether or not a call resulted in a right party contact, a wrong party contact, no answer, or an answering machine. For example, the objective of a call record for Joe Smith is to talk with Joe Smith. If agent <b>110</b> speaks with Joe Smith, that is a right party contact and a successful call attempt result. If Joe's babysitter answers the phone and Joe is not home, that is a wrong party contact and an unsuccessful call attempt result. If no one answers the phone or an answering machine answers the phone, that is an unsuccessful call attempt result since the desired party was not contacted. Therefore throughout the day, distribution module <b>102</b> queries dialing devices <b>108</b> for call attempt results and uploads the call attempts results. If a call attempt result is unsuccessful, then distribution module <b>102</b> updates the call record in pools <b>128</b> so that a dialing device <b>108</b> may call the call record again at a later time in the day.

0051An advantage to system <b>100</b> is that distribution module <b>102</b> controls the transfer of the call records which results in a level work flow for dialing devices <b>108</b>. To enable better work flow control, queues <b>130</b> include selection rules that determine how distribution module <b>102</b> transfers call records from pools <b>128</b> to queues <b>130</b>. The selection rules allow for the optimization of the transfer of call records from pools <b>128</b> to queues <b>130</b> and include priority rules, percentage rules, quotas, queuing theory rules, or any other appropriate rules for optimizing the transfer of call records from pools <b>128</b> to queues <b>130</b>. The selection rules can be modified on an as needed basis.

0052Priority rules result in distribution module <b>102</b> transferring call records from pools <b>128</b> to queues <b>130</b> based upon an assigned priority for each pool <b>128</b>. For example, queue <b>130</b>a receives call records from pools <b>128</b>a and <b>128</b>b with pool <b>128</b>a having priority over pool <b>128</b>b. Queue <b>130</b>b receives call records from pools <b>128</b>a and <b>128</b>b with pool <b>128</b>b having priority over pool <b>128</b>a. Assume that pool <b>128</b>a arrives at 8:00 AM while pool <b>128</b>b arrives at 9:00 AM. Initially, both queues <b>130</b>a and <b>130</b>b receive call records from pool <b>128</b>a. At 9:00 AM when pool <b>128</b>b arrives, queue <b>130</b>a continues to receive call records from pool <b>128</b>a while queue <b>130</b>b receives call records from pool <b>128</b>b.

0053Percentage rules result in distribution module <b>102</b> simultaneously transferring call records from pools <b>128</b> to queues <b>130</b>. For example, queue <b>130</b>c has a percentage configuration with pools <b>128</b>b and <b>128</b>c and queue <b>130</b>d has a percentage configuration with pools <b>128</b>b and <b>128</b>c. In this configuration, queue <b>130</b>c and <b>130</b>d receive call records simultaneously from pools <b>128</b>b and <b>128</b>c. With pool <b>128</b>b arriving at 8:00 AM and pool <b>128</b>c arriving at 9:00 AM, at 8:00 AM both queues <b>130</b>c and <b>130</b>d receive call records from pool <b>128</b>b. At 9:00 AM, queues <b>130</b>c and <b>130</b>d alternatively receive call records from pools <b>128</b>b and <b>128</b>c. The percentages are variable for instance so that queue <b>130</b>c receives 80% of its call records from pool <b>128</b>b and 20% of its call records from pool <b>128</b>c while queue <b>130</b>d receives 60% of its call records from pool <b>128</b>b and 40% of its call records from pool <b>128</b>c.

0054The selection rules can also incorporate the execution of an optimization module which will determine the optimal mix of call records from each of the available pools <b>128</b> based on the optimization constraints and the number of call records needed at the current time.

0055The selection rules can also incorporate pool quotas which are limits set on each pool controlling a maximum activity level such as number of records transferred, number of successful call attempts, and other appropriate indicators of call record activity. When distribution module <b>102</b> transfers call records to pools <b>128</b>, distribution module <b>102</b> can also set quotas on how many call records dialing devices <b>108</b> will call from pools <b>128</b>. In the percentage rule example above, distribution module <b>102</b> can place a quota on pool <b>128</b>b. When dialing devices <b>108</b> satisfy the quota for pool <b>128</b>b, queues <b>130</b>c and <b>130</b>d no longer receive call records from pool <b>128</b>b and only receive call records from pool <b>128</b>c.

0056The selection rules can also be a combination of the percentage rules and the priority rules. For example, queue <b>130</b>b receives call records from all three pools <b>128</b>a, <b>128</b>b, and <b>128</b>c. Queue <b>130</b>b receives call records from pool <b>128</b>b until dialing device <b>108</b>a calls all the call records in pool <b>128</b>b. At that time, queue <b>130</b>b then alternately receives call records from pools <b>128</b>a and <b>128</b>c. As with the percentage rules above, queue <b>130</b>b can receive call records from pools <b>128</b>a and <b>128</b>c in any percentage breakdown. Therefore, pool <b>128</b>b has priority over pools <b>128</b>a and <b>128</b>c while pools <b>128</b>a and <b>128</b>c transfer call records using percentage rules.

0057In addition, these selection rules allow for skills-based routing between pools <b>128</b>. For example, distribution module <b>102</b> allows pool <b>128</b>a to initially transfer call records to queue <b>130</b>a and pool <b>128</b>c to initially transfer call records to queue <b>130</b>d. If pool <b>128</b>c becomes depleted and has no more call records to transfer to queue <b>130</b>d, then pool <b>128</b>a can begin transferring call records to both queues <b>130</b>a and <b>130</b>d. This allows distribution module <b>102</b> to transfer call records for easy to moderate difficulty customers to the best agents while the less skilled agents work the more difficult customers. And once the easy to moderate difficulty customers call records are depleted, the best agents can begin working the more difficult customer call records.

0058In addition, distribution module <b>102</b> may also route call records to dialing devices <b>108</b> and agents <b>110</b> based on the performance of pools <b>128</b>. Routing the call records based on the performance of pools <b>128</b> allows distribution module <b>102</b> to make modifications so that pools <b>128</b> having a higher priority are not under-performing. Goal module <b>103</b>, associated with distribution module <b>102</b> and pools <b>128</b>, monitors the performance of pools <b>128</b>. To monitor the performance of pools <b>128</b>, either a user of system <b>100</b> or goal module <b>103</b> defines a performance metric for each pool <b>128</b>. Once the performance metric is defined, goal module <b>103</b> applies the performance metric to pools <b>128</b>. The performance metric is what goal module <b>103</b> uses to measure the performance of pools <b>128</b>. For example, the performance metric for pool <b>128</b>a may be the number of right party contacts while the performance metric for pool <b>128</b>b is the number of accounts attempts and the performance metric for pool <b>128</b>c is the number of call records attempted. Each pool <b>128</b> may have a different performance metric or pools <b>128</b> may have the same performance metric. In addition, each of the pools <b>128</b> may have more than one performance metric. For instance, pool <b>128</b>a may have both a performance metric for the number of right party contacts and for the number of total accounts attempted.

0059Once goal module <b>103</b> has determined a performance metric for each pool <b>128</b>, goal module <b>103</b> defines a goal for each pool <b>128</b>. The goal can be either an absolute goal or a goal set relative to all the other pools <b>128</b>. An absolute goal is a goal tied solely to the performance of the particular pool <b>128</b> while a relative goal is tied to the performance of all pools <b>128</b>. In addition, the goal is related to the selected performance metric. For instance, pool <b>128</b>a having a performance metric of number of right party contacts may have a goal of fifty right party contacts while pool <b>128</b>c having a performance metric of number of call records attempted has a goal of one hundred call records attempted.

0060If a pool <b>128</b> has more than one performance metric, then the pool <b>128</b> will have a goal for each performance metric. For example, if pool <b>128</b>a has a performance metric for number of right party contacts and for total number of accounts attempted, pool <b>128</b>a may have a goal of 80 right party contacts and 200 accounts attempted. In addition, a pool <b>128</b> may also have a combination of goals where there pool <b>128</b> only needs to satisfy one of the goals. For instance, pool <b>128</b>b may have a goal of 75 right party contacts or 200 accounts attempted and as long as pool <b>128</b>b has at least 75 right party contacts or 200 accounts attempted, pool <b>128</b>b is considered to be satisfying its goal and experiencing satisfactory performance.

0061The goals may also be end of day goals, mid-day goals, and rate based goals. End of day goals are goals calculated based on the performance of a pool <b>128</b> at the end of the day and include such goals as total number of call records attempted and number of right party contacts. Mid-day goals are similar to end of day goals but are calculated based on the time of day. For example, pool <b>128</b>a may have a mid-day goal of twenty-five right party contacts by noon. Rate based goals are calculated as a rate of the total calls. For instance, if pool <b>128</b>a has a performance metric of right party contact rate, a rate based goal may be 15% of all the call records from pool <b>128</b>a should result in a right party contact.

0062Similar to the selection rules, goal module <b>103</b> defines or constrains levels of effort for each queue <b>130</b>. The levels of effort detail the percentage of call records that transfer from a particular pool <b>128</b> to a particular queue <b>130</b>. The levels of effort are stored in an effort map associated with goal module <b>103</b>. Table 1 shows an example effort map for system <b>100</b>. An examination of the effort map shown in Table 1 reveals that queue <b>1</b> (queue <b>130</b>a) has a level of effort of 100% to pool <b>1</b> (pool <b>128</b>a) meaning queue <b>130</b>a receives all of its call records from pool <b>128</b>a. Queue <b>2</b> (queue <b>130</b>b) has a level of effort of 100% to pool <b>2</b> (pool <b>128</b>b) meaning queue <b>130</b>b receives 100% of its call records from pool <b>128</b>b. Queue <b>3</b> (queue <b>130</b>c) has a level of effort of 100% to pool <b>2</b> (pool <b>128</b>b) meaning queue <b>130</b>c receives 100% of its call records from pool <b>128</b>b. Queue <b>4</b> (queue <b>130</b>d) has a level of effort of 100% to pool <b>3</b> (pool <b>128</b>c) meaning that queue <b>130</b>d receives 100% of its call records from pool <b>128</b>c. Therefore, 100% of the call records in pool <b>128</b>a transfer to queue <b>130</b>a, the call records in pool <b>128</b>b transfer equally to queues <b>130</b>b and <b>130</b>c, and 100% of the call records in pool <b>128</b>c transfer to queue <b>130</b>d.

0063<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Effort Map</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="70pt" align="center" /><colspec colname="3" colwidth="28pt" align="center" /><colspec colname="4" colwidth="70pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>Pool 1</entry><entry>Pool 2</entry><entry>Pool 3</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Queue 1</entry><entry>100%</entry><entry> 0%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 2</entry><entry> 0%</entry><entry>100%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 3</entry><entry> 0%</entry><entry>100%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 4</entry><entry> 0%</entry><entry> 0%</entry><entry>100%</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0064As pools <b>128</b> begin to transfer call records to queues <b>130</b> and agents <b>110</b> access the call records, goal module <b>103</b> calculates a goal status for each pool <b>128</b>. The goal status can be defined as either the absolute difference between the actual metric and the goal or the percentage that a pool <b>128</b> is either ahead or behind its goal. For instance, if each pool <b>128</b> has a goal of fifty right party contacts and pool <b>128</b>a has forty-five right party contacts, pool <b>128</b>b has forty-eight right party contracts, and pool <b>128</b>c has sixty right party contacts, then pool <b>128</b>a has a goal status of −10%, pool <b>128</b>b has a goal status of −4%, and pool <b>128</b>c has a goal status of +20% for percentage based goals. Pool <b>128</b>a has a goal status of −5, pool <b>128</b>b has a goal status of −2 and pool <b>128</b>c has a goal status of +10 for absolute difference based goals.

0065Goal module <b>103</b> uses the goal status for each pool <b>128</b> to determine a goal state for each pool <b>128</b>. Pools <b>128</b> will have a goal state for each goal. An example definition of goals states would include the designation of ahead of goal, at goal, or behind goal. Goal module <b>103</b> or a user of system of <b>100</b> determines what thresholds define each of the available goal states. For example, if the goal states have been defined as ahead of goal, at goal, or behind goal, then a goal status of +10% and above may be ahead of goal, a goal status between +10% and −5% may be at goal, and a goal status of −5% and below may be behind goal. Given these threshold percentages and the goal status for pools <b>128</b>, pool <b>128</b>a has a goal state of behind goal (−10%), pool <b>128</b>b has a goal state of at goal (−4%), and pool <b>128</b>c has a goal state of ahead of goal (+20%). Any pool <b>128</b> that has a goal state of behind goal is said to be an under-performing pool and therefore experience unsatisfactory performance.

0066Similar to the pool quotas described above, goal module <b>103</b> also identifies and defines a final goal for each pool <b>128</b>. A user of system <b>100</b> may also define the final goals for each of the pools <b>128</b>. When a pool <b>128</b> satisfies its final goal, that pool <b>128</b> is no longer active and all the queues <b>130</b> that were receiving call records from that pool <b>128</b> now receive call records from the other pools <b>128</b> that have not satisfied their final goals. For instance, pool <b>128</b>a-<b>128</b>c each have a final goal of eighty right party contacts. At 3:00 PM, pool <b>128</b>a achieves eighty right party contacts. Because pool <b>128</b>a has achieved its final goal, it becomes inactive and the call records from pool <b>128</b>a are no longer transferred to queue <b>130</b>a. To prevent queue <b>130</b>a and agents <b>110</b> who access call records from queue <b>130</b>a from becoming inactive, goal module <b>103</b> modifies which queues <b>130</b> pools <b>128</b>b and <b>128</b>c transfer call records to by allowing pools <b>128</b>b and <b>128</b>c to transfer call records to queue <b>130</b>a. Since pools <b>128</b>b and <b>128</b>c have not reached their final goals, they are still active and queues <b>130</b> and agents <b>110</b> who were receiving call records from pool <b>128</b>a now receive call records from pools <b>128</b>b and <b>128</b>c.

0067Before distribution module <b>102</b> begins to transfer queues <b>130</b> containing the call records to dialing devices <b>108</b>, goal module <b>103</b> prioritizes pools <b>128</b> relative to each other. Certain pools <b>128</b> may contain call records that are of a higher priority than other pools <b>128</b>. For example, pool <b>128</b>a may contain call records for customers who have previously purchased products, pool <b>128</b>b may contain call records for customers who have never purchased products, and pool <b>128</b>c may contain call records for customers who are delinquent in paying for products previously purchased. Since a company's highest priority may be to collect the money it is owed, goal module <b>103</b> rates pool <b>128</b>c with the highest priority while pool <b>128</b>a has the second highest priority since it contains call records for customers with whom there is a previous relationship. Pool <b>128</b>b has the lowest priority since it contains call records for potential customers. The prioritization of pools <b>128</b> enables goal module <b>103</b> to adjust the workload of agents <b>110</b> so that pools <b>128</b> having the highest priority achieve and maintain their goals throughout the day.

0068Goal module <b>103</b> modifies the distribution of call records using the goals of pools <b>128</b> by modifying which queues <b>130</b> pools <b>128</b> transfer call records to based on the performance and prioritization of pools <b>128</b>. Goal module <b>103</b> modifies which queues <b>130</b> pools <b>128</b> transfer call records to by adjusting or transferring the levels of effort between pools <b>128</b> and queues <b>130</b>. For example, pool <b>128</b>a is of a higher priority than pool <b>128</b>c and pool <b>128</b>a is behind goal. Using the effort map shown in Table 1, queue <b>130</b>a receives 100% of its call records from pool <b>128</b>a and queue <b>130</b>d receives 100% of its call records from pool <b>128</b>c. Since pool <b>128</b>a is of a higher priority, goal module <b>103</b> transfers level of effort from pool <b>128</b>c to pool <b>128</b>a so that queue <b>130</b>d receives 50% of its call records from pool <b>128</b>c and 50% of its call records from pool <b>128</b>a while queue <b>130</b>a still receives 100% of its call records from pool <b>128</b>a. The example effort map shown in Table 2 illustrates which queues <b>130</b> pools <b>128</b> supply call records to after goal module <b>103</b> modifies the distribution of call records. Transferring some of the level of effort from pool <b>128</b>c to pool <b>128</b>a allows agents <b>110</b> who work queue <b>130</b>d to work call records from pool <b>128</b>a and thereby increase the number of agents <b>110</b> accessing call records from pool <b>128</b>a so that pool <b>128</b>a may satisfy its goal.

0069<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Effort Map</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="70pt" align="center" /><colspec colname="3" colwidth="28pt" align="center" /><colspec colname="4" colwidth="70pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>Pool 1</entry><entry>Pool 2</entry><entry>Pool 3</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Queue 1</entry><entry>100%</entry><entry> 0%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 2</entry><entry> 0%</entry><entry>100%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 3</entry><entry> 0%</entry><entry>100%</entry><entry> 0%</entry></row><row><entry /><entry>Queue 4</entry><entry> 50%</entry><entry> 0%</entry><entry>50%</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0070To aid in the distribution of call records based on the performance of pools <b>128</b>, goal module <b>103</b> employs one or more goal strategies. The goal strategies allow for the optimization of the transfer of call records from pools <b>128</b> to queues <b>130</b> and help to determine how goal module <b>103</b> transfers the levels of effort between pools <b>128</b> and queues <b>130</b>. There are different goal strategies that goal module <b>103</b> may implement when distributing the call records based on the performance of pools <b>128</b>. Goal module <b>103</b> may automatically select the goal strategy based upon the call records or a user of system of <b>100</b> may select an appropriate goal strategy.

0071One goal strategy is a meet-goals strategy. With the meet-goals strategy, goal module <b>103</b> transfers levels of effort to pools <b>128</b> that are not meeting their goals (a goal state of behind goal) and therefore are experiencing unsatisfactory performance. For example, if pool <b>128</b>a is behind goal and pool <b>128</b>b is ahead of goal, goal module <b>103</b> transfers levels of effort from pool <b>128</b>b to pool <b>128</b>a so that queues <b>130</b>b and <b>130</b>c also receive call records from pool <b>128</b>a. A number of right party contacts performance metric is a performance metric that might be managed with the meet-goals goal strategy.

0072Another goal strategy is an exceed-goals strategy. With the exceed-goals strategy, goal module <b>103</b> transfers levels of effort away from pools <b>128</b> that are not meeting their goals (a goal state of behind goal) and therefore have unsatisfactory performance. For instance, if pool <b>128</b>b is behind goal and pool <b>128</b>c is at goal, goal module <b>103</b> transfers levels of effort from pool <b>128</b>b to pool <b>128</b>c so that queues <b>130</b>b and <b>130</b>c begin to receive call records from pool <b>128</b>c. A right party contact rate performance metric is a performance metric that might be managed using the exceed-goals goal strategy.

0073To insure that lower priority pools <b>128</b> do not become neglected when goal module <b>103</b> routes call records based on the performance of pools <b>128</b>, goal module <b>103</b> sets preemptive limits on how much level of effort may be transferred away from pools <b>128</b>. These preemptive limits are stored in routing tables of which each pool <b>128</b> has its own routing table stored in goal module <b>103</b>. An exemplary is routing table for pool <b>128</b>a is shown in Table 3. In the example routing table of Table 3, if pool <b>128</b>a is ahead of goal, then pool <b>128</b>a is willing to forego 75% of its total level of effort to pools <b>128</b> that are at a higher priority that need additional levels of effort. Pool <b>128</b>a is willing to forego 50% of its total level of effort to pools <b>128</b> that are at the same priority that need effort if pool <b>128</b>a is ahead of goal. Pool <b>128</b>a is willing to give up 25% of its total level of effort to pools <b>128</b> that are of lower priority if needed if pool <b>128</b>a is ahead of goal. The percentages are then set at 40%, 25% and 15% if pool <b>128</b>a is currently at goal. If pool <b>128</b>a is behind goal, pool <b>128</b>a will only give up 25% of its level of effort and only to a pool <b>128</b> of higher priority. Each pool <b>128</b> has its own routing table and the percentages may vary depending on the number of pools, the number of call records, or any other appropriate factors.

0074<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Routing Table</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="70pt" align="center" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="63pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>Ahead</entry><entry>At</entry><entry>Behind</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Higher Priority</entry><entry>75%</entry><entry>40%</entry><entry>25%</entry></row><row><entry /><entry>Same Priority</entry><entry>50%</entry><entry>25%</entry><entry> 0%</entry></row><row><entry /><entry>Lower Priority</entry><entry>25%</entry><entry>15%</entry><entry> 0%</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0075In an alternate embodiment, the goal states and one or more goal strategies are inputs to and determine the objective functions and the constraints for an optimized solution to the routing determination problem. The goal strategies control how constraints on the levels of effort between pools <b>128</b> and queues <b>130</b> are relaxed or tightened when a pool <b>128</b> is not satisfying the goal. A goal strategy may allow for the transfer of higher levels of effort to pools <b>128</b> not satisfying their goals or allow for the transfer of higher levels of effort away from pools <b>128</b> not satisfying the goal. The goal module adjusts the level of effort constraints in accordance with the goal strategies so that pools <b>128</b> having the highest priority maintain or achieve the goals throughout the day.

0076In case of a communication, dialing device, or call center outage, system <b>100</b> employs contingency modules <b>132</b> for each dialing device <b>108</b>. Contingency modules <b>132</b> are associated with dialing devices <b>108</b>. Contingency modules <b>132</b> secure the call records within their respective dialing devices <b>108</b> in case of an outage. Before distribution module <b>102</b> transfers the call records to pools <b>128</b>, distribution module <b>102</b> creates call record accounts for dialing devices <b>108</b>, locks the call record accounts to dialing devices <b>108</b>, creates a contingency download file, and stores the contingency download file in contingency modules <b>132</b>. Distribution module <b>102</b> updates the contingency download file with call attempt results which prevents dialing devices <b>108</b> from calling call records already successfully called.

0077Users of system <b>100</b> control the functionality of distribution module <b>102</b> and goal module <b>103</b> through a user interface. The user interface is shown as online interface <b>134</b> in <figref idref="DRAWINGS">FIG. 1</figref> but can be any appropriate type of user interface. Online interface <b>134</b> is a graphical user, platform-independent, password-protected World Wide Web (“WWW”) browser-based interface. Users use online interface <b>134</b> to control the settings for distribution module <b>102</b> including goal module <b>103</b> including application of the selection rules, number of pools, and number of call records to initially transfer to the queues, generate reports, select goal strategies, select performance metrics, select the goals for the pools, define the goal states, modify the effort map and routing tables, and create and modify enterprise parameters. Users access online interface <b>134</b> by using browser <b>136</b> to access Internet <b>138</b> to reach a specific web address. Once at the specific web address, the users enter the appropriate passwords to gain access to online interface <b>134</b>.

0078Although the embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref> contains more than one dialing device, in alternative embodiments distribution module <b>102</b> interfaces with a single dialing device. A single dialing device interfacing with distribution module <b>102</b> allows for variable control over similar lists of call records. For instance, call records may be divided into geographies such as states or time zones. Calling can be stopped automatically by distribution module <b>102</b> when a quota is reached for a particular geography. Distribution module <b>102</b> presents the similar lists of call records for different geographies as different pools but the similar lists of call records for different geographies would represent one calling job within the single dialing device.

0079<figref idref="DRAWINGS">FIG. 2</figref> illustrates a block diagram of system <b>150</b> employing two distribution modules in an alternative embodiment of the present invention. System <b>100</b> as shown in <figref idref="DRAWINGS">FIG. 2</figref> is shown with less detail than in <figref idref="DRAWINGS">FIG. 1</figref>.

0080System <b>150</b> employs two distribution modules <b>102</b> and <b>152</b>. Distribution module <b>152</b> is associated with two call centers <b>154</b> and <b>156</b>. Call centers <b>154</b> and <b>156</b> each have one dialing device <b>158</b>. Distribution module <b>152</b> provides the same functionality to call centers <b>154</b> and <b>156</b> that distribution module <b>102</b> provides to call centers <b>104</b> as described above in the discussion regarding <figref idref="DRAWINGS">FIG. 1</figref>.

0081Distribution module <b>152</b> provides redundancy and prevents distribution module <b>102</b> from being overburdened by too many dialing devices. Distribution module <b>102</b> functions effectively with more than one dialing device interfaced with it but performance and efficiency suffers when too many dialing devices are attached. Therefore, additional distribution module <b>152</b> allows for both it and distribution module <b>102</b> to achieve optimal performance and efficiency when adding additional call centers <b>154</b> and <b>156</b> with additional dialing devices <b>158</b>.

0082In system <b>150</b>, distribution modules <b>102</b> and <b>152</b> are in communication with each other including communicating which call records are in the pools and the call attempt results. Distribution modules <b>102</b> and <b>152</b> transfer call records and call attempt results between themselves just as distribution module <b>102</b> transfers call records and call attempt results between dialing devices <b>108</b>. Therefore, if dialing devices <b>158</b> are idle while dialing devices <b>108</b> are overburdened, distribution module <b>102</b> transfers call records to distribution module <b>152</b> for dialing devices <b>158</b> to call. In addition, if distribution module <b>152</b> experiences an outage, distribution module <b>102</b> transfers the high priority calls from distribution module <b>152</b> to dialing devices <b>108</b> without worry of calling the same call record a second time in the same day when the first call resulted in a right party contact.

0083The two distribution modules <b>102</b> and <b>152</b> of system <b>150</b> also each include a goal module <b>103</b> and <b>153</b>. Goal module <b>153</b> provides the same functionality to call centers <b>154</b> and <b>156</b> that goal module <b>103</b> provides to call centers <b>104</b> as described above in the discussion regarding <figref idref="DRAWINGS">FIG. 1</figref>. Goal modules <b>103</b> and <b>153</b> are in communication with each other including communicating the performance of their respective pools and queues. Through the use of distribution modules <b>102</b> and <b>152</b>, goal modules <b>103</b> and <b>153</b> can transfer levels of effort between their respective pools just as goal module <b>103</b> transfers levels of effort between pools <b>128</b>. Therefore if high priority pools <b>128</b> are not meeting their goals, then goal module <b>153</b> can transfer levels of effort from distribution module <b>152</b> so that the high priority pools <b>128</b> will achieve their goals.

0084Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, a flow diagram depicts a process for distributing outbound call records. The process begins at step <b>170</b> with the transfer of call records from host <b>112</b>, dialing devices <b>108</b>, or scheduling module <b>122</b> to distribution module <b>102</b>. In step <b>172</b>, distribution module <b>102</b> organizes and arranges the call records into pools <b>128</b>. Based upon user inputs distribution module <b>102</b> assigns queues <b>130</b> to specific dialing devices in step <b>174</b>.

0085In step <b>176</b>, distribution module <b>102</b> checks to see if the selection rules are to be applied to pools <b>128</b> and queues <b>130</b>. If the selection rules are not to be applied, then the process continues in step <b>178</b>. If selection rules are to be applied, then in step <b>180</b> distribution module <b>102</b> determines if priority, percentage, or quota rules are applied to pools <b>128</b>. If priority rules are applied, then in step <b>182</b> distribution module <b>102</b> applies the priority rules to pools <b>128</b> and queues <b>130</b> and the process continues on to step <b>178</b>. If percentage rules are applied, then in step <b>184</b> distribution module <b>102</b> applies the percentage rules to pools <b>128</b> and queues <b>130</b> and the process continues in step <b>178</b>. If the quota rules are applied, then in step <b>186</b> distribution module <b>102</b> applies the quotas to pools <b>128</b> and queues <b>130</b> and the process continues to step <b>178</b>.

0086Distribution module <b>102</b> then delivers enough call records to queues <b>130</b> for dialing devices <b>108</b> to place telephone calls for fifteen, thirty, sixty minutes, or an appropriate amount of time to place calls in step <b>178</b>. In step <b>190</b>, distribution module <b>102</b> locks the call records assigned to dialing devices <b>108</b> and creates a contingency file specific for each dialing device <b>108</b> in step <b>192</b>.

0087In step <b>194</b>, distribution module <b>102</b> transfers queues <b>130</b> containing the set number of call records to dialing devices <b>108</b>. Periodically, distribution module <b>102</b> uploads call record statistics from each queue <b>130</b> in step <b>196</b>. Distribution module <b>102</b> may upload the call record statistics from queues <b>130</b> every few seconds, every few minutes, every hour, or any other appropriate interval of time. Call record statistics include such information as how many call records remain to he called and the rate at which dialing devices <b>108</b> are depleting the call records in queues <b>130</b>. In addition to uploading call record statistics, in step <b>198</b> distribution module <b>102</b> also uploads call attempt results. Call attempt results include whether a right party contact or wrong party contact was made or whether an answering machine was reached when dialing devices <b>108</b> place a telephone call.

0088In step <b>202</b> distribution module <b>102</b> updates the contingency file with the call attempt results specific for dialing devices <b>108</b>. In step <b>204</b>, distribution module <b>102</b> uses the call record statistics gathered in step <b>196</b> to analyze the number of call records remaining to be called and the depletion rate of the call records within queues <b>130</b>. Based upon the call attempt results, distribution module <b>102</b> represents to pools <b>128</b> call records where the first attempt to make a right party contact was unsuccessful so that the call record can be called later in the day in step <b>206</b>. In addition, the call record can be made unavailable for the remainder of the day if a right party contact was made.

0089Based upon the call record statistics, distribution module <b>102</b> determines in step <b>208</b> if more call records need to be to sent from pools <b>128</b> to queues <b>130</b>. If more call records are needed, then in step <b>210</b> distribution module <b>102</b> sends additional call records from pools <b>128</b> to queues <b>130</b> and the process repeats beginning with step <b>176</b> until manually stopped. But if distribution module <b>102</b> determines that no additional call records need to be sent from pools <b>128</b> to queues <b>130</b> in step <b>208</b>, then the process repeats beginning with step <b>196</b> until manually stopped or until there are no call records remaining to be called.

0090<figref idref="DRAWINGS">FIGS. 4a and 4b</figref> illustrate a flow diagram for the population of pools <b>128</b> and queues <b>130</b> with call records. The call records in <figref idref="DRAWINGS">FIGS. 4a and 4b</figref> include scheduling information provided by scheduling module <b>122</b>.

0091Referring to <figref idref="DRAWINGS">FIG. 4a</figref>, in step <b>222</b> the call records pass through scheduling module <b>122</b> from either dialing devices <b>108</b> or host <b>112</b>. Scheduling module <b>122</b> adds call scheduling information to each call record as it passes through it. In step <b>224</b>, scheduling module <b>122</b> transfers the call records containing call scheduling information to call record database <b>118</b> within distribution module <b>102</b>. Distribution module <b>102</b> then arranges the call records into pools <b>128</b> in step <b>226</b>. When distribution module <b>102</b> places the call records into pools <b>128</b>, distribution module <b>102</b> examines each call record to determine how to extract the scheduling information, account number and telephone number from the call record. In addition, distribution module <b>102</b> flags any call records where the scheduling information or telephone number is stripped from the end of the call record before placing it in the pools <b>128</b>.

0092In step <b>228</b>, distribution module <b>102</b> splits the call records into a plurality of pools <b>128</b>. Each pool <b>128</b> holds the call record as a data string and the call records are in the same format within pools <b>128</b>. In addition, distribution module <b>102</b> arranges the call records within pools <b>128</b> so that each call record is selectable by its account number.

0093The call scheduling information provided by scheduling module <b>122</b> allows for an optimum order to call the call records. Using the call scheduling information, distribution module <b>102</b> creates hourly indices for pools <b>128</b> in step <b>230</b>. The hourly indices allow for pools <b>128</b> to take advantage of the fact that the call order and call priority of each call record changes based upon the time of day. For example, a call record might be scheduled to be the first call at 8:00 AM and if not successfully called at 8:00 AM then rescheduled to be the tenth call made at 6:00 PM. There is a hourly index created for each hour of the calling day and the hourly indices are shown in step <b>232</b>. Distribution module <b>102</b> creates an index for each hour for each pool <b>128</b>.

0094In addition to the hourly indices, distribution module <b>102</b> also creates an immediate index and an overflow index. The immediate index contains call records that are always the first to be called at the beginning of every hourly index. The call records within the immediate index allow real time call record insertion based upon previous call attempts and are often call records that resulted in no contact when called the first time. Call records contained in the overflow index are call records which were not scheduled to be called or call records that do not have call scheduling information.

0095Once the call records are arranged into pools <b>128</b> and the hourly indices are created, the process of transferring the call records from pools <b>128</b> to queues <b>130</b> begins. In step <b>234</b>, distribution module <b>102</b> selects the call records contained in the immediate index. Distribution module <b>102</b> also removes any call records that are unavailable to be called and marks the call records as unavailable in step <b>236</b>. In step <b>238</b>, distribution module <b>102</b> determines if it is ready to transfer the call records from pools <b>128</b> to queues <b>130</b> for this hour and if there are a sufficient number of call records to be transferred from the immediate index to allow for fifteen, thirty, sixty minutes, or an appropriate amount of time for calling. If there are sufficient call records, then in step <b>239</b>, distribution module <b>102</b> transfers the call records from the pool immediate index to queues <b>130</b>.

0096If there are not enough call records in the immediate index, then in step <b>240</b> distribution module <b>102</b> selects call records from the appropriate hourly index. These additional call records in combination with call records from the immediate index will allow for fifteen, thirty, sixty minutes, or an appropriate amount of time for calling. In step <b>242</b>, distribution module <b>102</b> removes any call records unavailable to be called and marks the call records as unavailable. Distribution module <b>102</b> then transfers the call records from the immediate index and the appropriate hourly index to queues <b>130</b> in step <b>239</b>.

0097In step <b>244</b>, distribution module <b>102</b> transfers queues <b>130</b> containing the call records to dialing devices <b>108</b>. After queues <b>130</b> are transferred to dialing devices <b>108</b>, in step <b>246</b> dialing devices <b>108</b> begin calling the call records.

0098Referring to <figref idref="DRAWINGS">FIG. 4b</figref>, as dialing devices <b>108</b> call the call records, distribution module <b>102</b> monitors dialing devices <b>108</b> and queues <b>130</b> for when it is time to send the next hourly index of call records from pools <b>128</b> to queues <b>130</b> in step <b>248</b>. In determining when to send the next hourly index, distribution module <b>102</b> cannot start morning hour queues before the actual hour of the hourly index and must stop evening hour queues before the hourly index hour expires. For instance, the pool morning hourly index for 10:00 AM cannot be sent from pools <b>128</b> to queues <b>130</b> before 10:00 AM and the evening hourly index for 7:00 PM must stop calling at 8:00 PM. This is in part to due to telemarketing regulations that regulate the times of day that telemarketing calls may be placed.

0099If in step <b>248</b> it is time for the next hourly index, then in step <b>250</b> distribution module <b>102</b> selects the next hourly index to be called and begins the process of transferring the call records from the appropriate hourly index to queues <b>130</b>. The process of selecting the next hourly index repeats steps <b>234</b> through <b>244</b> by first taking call records from the immediate index and adding call records from the appropriate hourly index as explained above.

0100If in step <b>248</b> it is not time for the next hour, then distribution module <b>102</b> determines queue depth and the time to go in step <b>252</b>. Queue depth is the amount of call records remaining to be called in the queue while time to go is the amount of time remaining in the hour for the hourly index. In step <b>254</b> if the depth is not too low and the time to go is not too short so that there are a sufficient amount of call records to call for the remaining time left in the hour, then additional call records are not needed in queue <b>130</b>. So in step <b>256</b>, the call attempt results regarding a right or wrong party contact are uploaded from dialing devices <b>108</b> and sent back to distribution module <b>102</b> in step <b>258</b>. The process then returns to step <b>234</b> of <figref idref="DRAWINGS">FIG. 4a</figref> to begin the next record search.

0101If in step <b>254</b> distribution module <b>102</b> determines that the depth is too low or the time to go is too short, then in step <b>260</b> distribution module <b>102</b> calculates the number of call records needed to finish out the hour for the hourly index. In step <b>262</b>, distribution module <b>102</b> selects additional call records to call by repeating steps <b>234</b> through <b>239</b> above and transferring the call records from the pools <b>128</b> to queues <b>130</b> in step <b>264</b> so that dialing devices <b>108</b> do not sit idle but finish out the hour placing telephone calls. The process then returns to step <b>234</b> of <figref idref="DRAWINGS">FIG. 4a</figref> to begin the next record search.

0102<figref idref="DRAWINGS">FIG. 5</figref> depicts a flow diagram of a method for goals based routing of contact records employing a meet-goals goal strategy. The method begins at step <b>300</b> when goal module <b>103</b> selects a performance metric for each pool <b>128</b>, determines a goal for each pool <b>128</b> and prioritizes pools <b>128</b> relative to each other. At step <b>302</b> goals module <b>103</b> calculates a goal status for each pool <b>128</b> using the goal and performance metric for each pool <b>128</b>. After goal module <b>103</b> has calculated a goal status, goal module <b>103</b> cycles through pools <b>128</b> in descending priority order at step <b>304</b>.

0103At step <b>306</b>, goal module <b>103</b> selects a target pool based on its priority. Goal module <b>103</b> selects a target pool by first selecting the pool <b>128</b> having the highest priority. Goal module <b>103</b> then determines the goal state from the goal status for the target pool to determine if the target pool is behind goal at step <b>308</b>. If the target pool is not behind goal, then at step <b>310</b> goal module <b>103</b> checks to see if there are additional pools <b>128</b> to cycle through. If there are not additional pools <b>128</b> to cycle through, then the process ends. But if there are additional pools <b>128</b> to cycle through at step <b>310</b>, then the process returns to step <b>306</b> where goal module <b>103</b> selects the pool <b>128</b> having the next highest priority to determine if that target pool is behind goal. If that target pool is not behind goal, then the process repeats until either goal module <b>103</b> locates a target pool that is behind goal at step <b>308</b> or the process ends because no target pools are behind goal.

0104If at step <b>308</b>, the target pool is behind goal, then goal module <b>103</b> cycles through donor pools from lowest to highest priority at step <b>312</b>. The donor pools include all the other pools <b>128</b> except the target pool that was selected at step <b>308</b>. At step <b>314</b>, goal module <b>103</b> selects a donor pool <b>128</b> having the lowest priority out of all the donor pools. The goal module <b>103</b> then determines if the selected donor pool is active and able <b>10</b> donate levels of effort to the target pool at step <b>316</b>. A pool <b>128</b> is active when it is still transferring contact records to queues <b>130</b> and hasn't satisfied its final goal or quota. Goal module <b>103</b> examines the routing table for the selected donor pool to determine if the donor pool is able to donate levels of effort to the target pool. Since each pool <b>128</b> has its own routing table, goal module <b>103</b> must examine the routing table to determine if the donor pool is able to donate any levels of effort. Generally, if the selected donor pool is ahead of goal or at goal, it is able to donate a percentage of level of effort to the target pool regardless of the respective pool priorities. If the donor pool is behind goal but the target pool is of a higher priority, then generally the donor pool is available to donate some percentage of level of effort. If the donor pool is behind goal and the target pool is of the same priority or lower priority, then typically the donor pool is not able to donate any level of effort to the target pool.

0105If at step <b>316</b> the donor pool is both active and able to donate a percentage of level of effort to the target pool, then at step <b>318</b> goal module <b>103</b> transfers a percentage of the level of effort from the donor pool to the target pool. Goal module <b>103</b> transfers the level of effort from the donor pool to the target pool by modifying the effort map in accordance with the limits specified in the routing table for the donor pool. To donate the level of effort from the donor pool to the target pool, goal module <b>103</b> examines the routing table for the donor pool to determine how much level of effort may be donated from the donor pool to the target pool. For instance using the example routing table in Table 3, if the target pool is of a higher priority than the donor pool and the donor pool is above its goal, then goal module <b>103</b> transfers 75% of the level of effort for the donor pool to the target pool, Therefore, if pool <b>128</b>a is the donor pool and pool <b>128</b>c is the target pool, goal module <b>103</b> transfers 75% of the level of effort for pool <b>128</b>a to pool <b>128</b>c thereby allowing queue <b>130</b>a to receive 25% of its contact records from pool <b>128</b>a and 75% of its contact records from pool <b>128</b>c instead of queue <b>130</b>a receiving 100% of its contact records from pool <b>128</b>a. Pool <b>128</b>c now supplies contact records to queues <b>130</b>a and <b>130</b>d instead of just queue <b>130</b>d which allows additional agents <b>110</b> to access contact records from pool <b>128</b>c and thereby meet the goal for pool <b>128</b>c. Goal module <b>103</b> then modifies the effort map to reflect this change in the levels of effort between pools <b>128</b>.

0106After goal module <b>103</b> transfers the level of effort, at step <b>320</b> goal module <b>103</b> determines if there are additional donor pools to cycle through. If there are additional donor pools to cycle through, then the process returns to step <b>314</b> where goal module <b>103</b> selects the donor pool having the second lowest priority and the process repeats until there are no more donor pools to cycle through at step <b>320</b>. If at step <b>316</b> the donor pool is either not active or not able to donate a percentage of level of effort to the target pool, the process proceeds to step <b>320</b> where goal module <b>103</b> determines if there are additional donor pools to cycle through as described above.

0107When at step <b>320</b> goal module <b>103</b> determines that there are no more donor pools to cycle through, the process proceeds to step <b>310</b> where goal module <b>103</b> determines if there are any additional pools <b>128</b> to cycle through. If there are no more pools <b>128</b>, then the process ends. If there are additional pools, then the process returns to step <b>306</b> where goal module <b>103</b> selects the next pool <b>128</b> based on its priority to determine if it is behind its goal.

0108The method of <figref idref="DRAWINGS">FIG. 5</figref> repeats until goal module <b>103</b> has checked every pool <b>128</b> from highest to lowest priority to see if pools <b>128</b> are behind goal. Therefore, the pools <b>128</b> having the highest priority are addressed first by goal module <b>103</b> ensuring that pools <b>128</b> having the highest priority shall achieve and/or maintain their goals by transferring levels of effort away from pools <b>128</b> having a lower priority to pools <b>128</b> having a higher priority.

0109<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flow diagram of a method for goals based routing of contact records employing an exceed-goals goal strategy. The method begins at step <b>330</b> when goal module <b>103</b> selects a performance metric for each pool <b>128</b>, determines a goal for each pool <b>128</b> and prioritizes pools <b>128</b> relative to each other. At step <b>332</b>, goal module <b>103</b> calculates a goal status for each pool <b>128</b> using the goal and performance metric for each pool <b>128</b>. After goal module <b>103</b> has calculated a goal status, goal module <b>103</b> cycles through pools <b>128</b> in an ascending priority order at step <b>334</b>.

0110At step <b>336</b>, goal module <b>103</b> selects a target pool based on its priority. Goal module <b>103</b> selects a target pool by first selecting the pool <b>128</b> having the lowest priority. Goal module <b>103</b> then determines the goal state using the goal status for target pool to determine if target pool is behind goal at step <b>338</b>. If target pool is not behind goal, then at step <b>340</b> goal module <b>103</b> checks to see if there are additional pools <b>128</b> to cycle through. If there are no additional pools <b>128</b> to cycle through, the process ends. But if there are additional pools <b>128</b> to cycle through at step <b>340</b>, then the process returns to step <b>336</b> where goal module <b>103</b> selects the pool <b>128</b> having the next lowest priority to determine if that target pool is behind goal. If that target pool is not behind goal, then the process repeats until either goal module <b>103</b> locates a target pool that is behind goal at step <b>338</b> or the process ends because no target pools are behind goal.

0111If at step <b>338</b>, the target pool is behind goal, then goal module <b>103</b> cycles through recipient pools from highest to lowest priority at step <b>342</b>. The recipient pools include all the other pools <b>128</b> except the target pool that was selected at step <b>336</b>. At step <b>344</b>, goal module <b>103</b> selects a recipient pool having the highest priority out of all the recipient pools. Goal module <b>103</b> then determines if the selected recipient pool is active and ahead of its goal at step <b>346</b>. A pool <b>128</b> is active when it is still transferring contact records to queues <b>130</b> and has not satisfied its final goal or quota.

0112If at step <b>346</b> the recipient pool is both active and ahead of its goal, then at step <b>348</b> goal module <b>103</b> transfers a percentage of the level of effort from the target pool to the recipient pool. After goal module <b>103</b> transfers the level of effort, at step <b>340</b> goal module <b>103</b> determines if there are additional pools <b>128</b> to cycle through. If there are no additional pools <b>128</b> to cycle through at step <b>340</b>, then the process ends. But if at step <b>340</b> there are additional pools <b>128</b> to cycle through, then the process returns to step <b>336</b> where goal module <b>103</b> selects the target pool having the next lowest priority.

0113If at step <b>346</b> the recipient pool is either not active or not ahead of goal, the process proceeds to step <b>350</b> where goal module <b>103</b> determines if there are additional recipient pools to cycle through. If there are additional recipient pools to cycle through at step <b>350</b>, then the process returns to step <b>344</b> where goal module <b>103</b> selects a recipient pool having the next highest priority and the process repeats as described above.

0114If at step <b>350</b> there are no more recipient pools to cycle through, the process continues to step <b>352</b>. The method only proceeds to step <b>352</b> after goal module <b>103</b> has examined all of the recipient pools to determine if the recipient pools are active and ahead of goal. At step <b>352</b>, goal module <b>103</b> cycles through recipient pools from highest to lowest priority and at step <b>354</b> goal module <b>103</b> selects the recipient pool having the highest priority. At step <b>356</b>, goal module <b>103</b> determines if the selected recipient pool is active and at goal. If the selected recipient pool is active and at goal, then at step <b>358</b> goal module <b>103</b> transfers a percentage of the level of effort from the target pool to the selected recipient pool. The process then continues on to step <b>340</b> where goal module <b>103</b> determines if there are additional pools <b>128</b> to cycle through and the process either ends or returns to step <b>336</b>.

0115If at step <b>356</b> goal module <b>103</b> determines that the selected recipient pool is either not active or not at goal, then at step <b>360</b> goal module <b>103</b> determines if there are additional recipient pools to cycle through. If there are not additional recipient pools to cycle through, then the process continues to step <b>340</b> where goal module <b>103</b> determines if there are additional pools <b>128</b> to cycle through as described above. If there are additional recipient pools to cycle through at step <b>360</b>, then the process returns to step <b>354</b> where goal module <b>103</b> selects the next recipient pool having the next highest priority and the process repeats as described above.

0116The method of <figref idref="DRAWINGS">FIG. 6</figref> repeats until goal module <b>103</b> has checked every pool <b>128</b> from lowest to highest priority to see if pools <b>128</b> are behind goal. Therefore, the pools <b>128</b> having the lowest priority are examined first to determine if they are able to donate a percentage of level of effort to pools <b>128</b> having higher priority so that the pools <b>128</b> having the highest priority exceed their goals.

0117In an alternate embodiment, the present invention applies to the different types of contacts records and devices listed above and manages other types of customer contact requests such as inbound calls, email, Internet chat, online requests for live chat in addition to outbound call records.

0118Although the present invention has been described in detail, it should be understood that various changes, substitution, and alterations can be made hereto without parting from the spirit and scope of the invention as defined by the appended claims.