Abstract:
A system for allocating contact center resources among geographically distributed sub-centers of an enterprise comprises a processing system. The processing system is configured to create a distributed campaign for the enterprise, create a workload forecast of events for the distributed campaign, wherein the processing system, to create the workload forecast, is configured to treat the geographically distributed sub-centers as being co-located in a virtual contact center, execute a discrete event-based simulation utilizing the virtual contact center to allocate the events to the contact center resources, wherein the processing system, to execute the discrete event-based simulation, is configured to treat the contact center resources as being co-located in the virtual contact center, and determine recommended allocations of the contact center resources among the geographically distributed sub-centers based on a relative distribution of the events allocated to the contact center resources at the geographically distributed sub-centers.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of co-pending U.S. utility application having Ser. No. 11/385,499 filed on Mar. 21, 2006, all of which is entirely incorporated herein by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention is generally related to contact center allocation of resources. 
       BACKGROUND 
       [0003]    Resource allocation and planning, including the generation of schedules for employees, is a complex problem for enterprises. Telephone call center resource allocation and scheduling is an example of a problem with a large number of variables. Variables include contact volume at a particular time of day, available staff, skills of various staff members, call type (e.g., new order call and customer service call), and number of call queues, where a call queue may be assigned a particular call type. A basic goal of call center scheduling is to minimize the cost of agents available to answer calls while maximizing service. 
         [0004]    Traditionally, call center scheduling is performed by forecasting incoming contact volumes and estimating average talk times for each time period based on past history and other measures. These values are then correlated to produce a schedule. However, due to the number of variables that may affect the suitability of a schedule, many schedules need to be evaluated. 
         [0005]    Recently, call centers have evolved into “contact centers” in which the agent&#39;s contact with the customer can be through many contact media. For example, a multi-contact call center may handle telephone, email, web callback, web chat, fax, and voice over internet protocol. Therefore, in addition to variation in the types of calls (e.g., service call, order call), modern contact centers have the complication of variation in contact media. The variation in contact media adds complexity to the agent scheduling process. 
         [0006]    Additional complexity results when multiple sites are involved. That is, multiple geographically distributed call centers may be owned by a single organization, or calls may be distributed to multiple locations depending on whether a contact is for technical support, sales, etc. 
       SUMMARY 
       [0007]    Systems and methods for allocating resources, e.g., contact center agents, among geographically distributed sites are provided. In this regard, an exemplary embodiment of such a method comprises: creating a workload forecast, such as contact volume and average handle, resolution, interaction and/or order/purchase fulfillment time, of events for a specified time frame, such as hours, days, week, months, quarters and/or years, as if the geographically distributed sites were co-located, performing discrete event-based simulation to assign the events to the contact center resource(s) as if at least a portion of the total contact center resources were co-located, and determining recommended allocations of the contact center resources among the geographically distributed sites based on a relative distribution of events expected, forecasted, simulated or assigned to contact center resources at each of the geographically distributed sites. In addition to time, requirements can further include other operational constraints of the sites, including, for example, network bandwidth. 
         [0008]    An exemplary embodiment of a system for allocating contact/support center resources, such as agents, servers, computers, databases, recorders (including, among others, TDM, VoIP and/or wireless recorders), administrative staff, customer services personnel, supervisors, managers, marketers, cross-sellers, supplies and other logistical resources involved in the operations of point of contact centers, including contact or customer support centers, back office or support centers, retailing and banking centers, comprises: a forecasting system configured to create a workload forecast, such as volume, peak time, low time, average volume, static and dynamic volume, including requirements per hour (including minutes and seconds), day, week, month, quarter and/or year, with such requirement including, for example, voice, messenger chat, email, and direct contact channels of communication, and average handle, resolution and/or transactional time forecast of events for a specified or predetermined time frame, schedule and/or campaign, as if the geographically distributed resources or sites were co-located, a simulation system configured to perform discrete event-based simulation to assign the events to the resource(s) (for example, contact center agents) as if the resource were co-located, and an analysis system configured to determine recommended allocations of resources among the geographically distributed sites based on a relative distribution of events expected, forecasted or simulated for the center and/or assigned to resource(s) at each of the geographically distributed sites 
         [0009]    Other systems, methods, features, and advantages of the present invention will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present invention, and be protected by the accompanying claims. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, there is no intent to limit the disclosure to the embodiment or embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications and equivalents. 
           [0011]      FIG. 1  is a schematic diagram illustrating an exemplary embodiment of a system for distributing events, such as contact/support center events, according to recommended allocations of resources, such as contact center agents. 
           [0012]      FIG. 2  is a schematic diagram illustrating an embodiment of a computer-implemented system that can be used for determining recommended allocations of resources, such as contact center agents, utilized in  FIG. 1 . 
           [0013]      FIG. 3  is a flowchart illustrating functionality (or method steps) that can be performed by an embodiment of a system according to  FIG. 2  to create recommended allocations of resources, such as contact center agents, for use in the system of  FIG. 1 . 
           [0014]      FIG. 4  is a diagram illustrating a distributed campaign according to  FIG. 3 . 
           [0015]      FIG. 5  is a diagram illustrating a sub-campaign from  FIG. 4 . 
           [0016]      FIG. 6  is a flowchart illustrating determination of recommended allocations by the system in  FIG. 2 . 
           [0017]      FIG. 7  is a flowchart illustrating the multi-scheduling algorithm of  FIG. 6 . 
           [0018]      FIG. 8  is a flowchart illustrating the calculation of sub-campaign allocations of  FIG. 6 . 
           [0019]      FIG. 9  is a flowchart illustrating the discrete event-based simulation of  FIG. 8 . 
       
    
    
     DETAILED DESCRIPTION 
       [0020]    Disclosed herein are systems and methods for determining recommendations for the allocation of resources, such as call center agents, retailers or bankers. In particular, the allocation of resources can be achieved using discrete event-based simulations that perform allocations on multiple distributed sites as if the resources were not distributed. Recommended allocations are based on a relative distribution, e.g. percentages, of events, such as customer calls, inquiries, purchases and other transactional and operational events, for each site in accordance with the resource to which the simulation assigned the events. More generally though, the systems and methods of the present invention can be deployed or utilized in allocating contact/support center resources, such as agents, servers, computers, databases, recorders (including, among others, TDM, VoIP and/or wireless recorders), administrative staff, customer services personnel, supervisors, managers, marketers, cross-sellers, supplies and other logistical resources involved in the operations of point of contact centers, including contact or customer support centers, back office or support centers, retailing and banking centers. 
         [0021]    An ideal system for distributing events to multiple sites would be a system that could analyze every available site for any available resource located at any of the available sites. After location of an available resource, such a system would route the event to that resource regardless of that resource&#39;s geographical location. Thus, although the contact center is a virtual center, the system would distribute events as if the contact center were one large contact center. Such efficiency, however, is difficult to attain. Typically, contact centers operate on preset allocations of events for a particular time frame. The equipment costs for analyzing all available sites and routing events accordingly can be very expensive. By comparison, equipment costs for routing defined percentages of events is currently preferable. With preset allocations, a distributed site essentially operates as an independent site that knows what volume of events to expect and, thus, is able to schedule staffing, and other resources, accordingly. 
         [0022]    The disclosed systems for determining allocations for distributed multi-site contact centers provide recommended allocations of contact center resources, such as agents, based on simulations that utilize virtual contact centers. Statistical information based on existing work flow management (WFM) data are used to create a workload forecast of events for contact volume data and average handle times. A contact volume forecast is the number of events forecast for a certain time interval. An average handle time forecast is the response time required per event. In conjunction with agent schedules and other agent rules, randomly distributed contact arrival events are created based on the WFM data. A discrete event-based simulation then routes the events to available agents as if they were assigned to a non-distributed or virtual contact center. Recommended allocations for the various sites are then calculated based on the agents to which the events were assigned. 
         [0023]    Exemplary systems are first discussed with reference to the figures. Although these systems are described in detail, they are provided for purposes of illustration only and various modifications are feasible. After the exemplary systems have been described, examples of recommended allocations are provided to explain the manner in which the scheduling and allocation of the call center agents can be achieved. 
         [0024]    Referring now in more detail to the figures,  FIG. 1  is a schematic diagram illustrating an exemplary embodiment of a system for distributing events according to recommended allocations of resources, such as contact center agents. The system  100  comprises one or more customer premises  102 . The customer premise  102  includes, for example but not limited to, telephones, cellular phones and computing devices. Customer premises  102  communicate with a network  106  (e.g., PSTN and/or cellular) that communicates with a contact center  110 . In  FIG. 1  the contact center  110  is shown connected through a network  112  (e.g., local area network (LAN) or wide area network (WAN) or virtual private network (VPN)) to various sub-centers  114 ,  116  and  118 . Each sub-center  114 ,  116  and  118 , has multiple contact center agents  120 ,  122 ,  124 ,  126 ,  128 ,  130 ,  132 ,  134  and  136 . It should be noted that the number of sub-centers  114 ,  116  and  118 , may vary according to the requirements of the contact center  110 . Typically, there will be at least two sites (sub-centers). Of course, the number of contact center agents  120  et al., will also vary according to the recommended allocations for each sub-center  114 ,  116 ,  118 . Hereafter, unless two different contact center agents are discussed, references to a generic contact center agent or to generic contact center agents will refer to contact center agent  120 . Also, for purposes of illustration, the discussion to follow focuses on the allocation of contact center agents  120 , though the contact center resources could just as likely be servers, computers, databases, recorders (including, among others, TDM, VoIp and/or wireless recorders), administrative staff, customer services personnel, supervisors, managers, marketers, cross-sellers, supplies and other logistical resources involved in the operations of point of contact centers, including contact or customer support centers, back office or support centers, retailing and banking centers. 
         [0025]    Events, such as a call  104 , to customer support are placed from a customer premise  102  through the network  106  to the contact center  110 . The customer initiates the event with no regard as to where the contact center agent  120  is actually located. The event is routed to the next available contact center agent  120  by the contact center  110  in accordance with recommended allocations provided to the contact center  110  from an allocation system  111 . A contact center agent  120  utilizes computing devices (not shown) such as, for instance, desktop computers (PCs) or Macintosh computers that can, if necessary, be connected to communication devices, such as a headset, microphones, and headphones, among others. 
         [0026]      FIG. 2  is a schematic diagram illustrating an exemplary embodiment of a computer-implemented allocation system  111  that can be used for determining recommended allocations of contact center agents  120 . It should be noted that the allocation system  111  could be located in the contact center  110  or at a location connected to the contact center via a network such as the network  112  or the Internet, among others. Generally, the allocation system  111  includes a processing device  138 , memory  140 , user interface devices  148 , input/output devices (I/O)  150  and networking devices  152 , each of which is connected to local interface  146 . The local interface can include, for example but not limited to, one or more buses or other wired or wireless connections. The local interface may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among aforementioned components. The processor may be a hardware device for executing software, particularly software stored in memory. 
         [0027]    The processing device  138  can be any custom made or commercially available processor, a central processing unit (CPU) or an auxiliary processor among several processors associated with the allocation system  111 , a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: a PA-RISC series microprocessor from Hewlett-Packard® Company, an 80×86 or Pentium® series microprocessor from Intel® Corporation, a PowerPC® microprocessor from IBM®, a Sparc® microprocessor from Sun Microsystems®, Inc, or a 68xxx series microprocessor from Motorola® Corporation. 
         [0028]    The memory can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory (as well as various other components) can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processing device  138 . Additionally, memory  140  can also include an operating system  142 , as well as instructions associated with various subsystems, such as a multi-site allocation recommendation system  144 . 
         [0029]    The software in memory  140  may include one or more separate programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In this regard, a non-exhaustive list of examples of suitable commercially available operating systems is as follows: (a) a Windows® operating system available from Microsoft® Corporation; (b) a Netware® operating system available from Novell®, Inc.; (c) a Macintosh® operating system available from Apple® Computer, Inc.; (d) a UNIX operating system, which is available for purchase from many vendors, such as the Hewlett-Packard® Company, Sun Microsystems®, Inc., and AT&amp;T® Corporation; (e) a LINUX operating system, which is freeware that is readily available on the Internet 100; (f) a run time Vxworks® operating system from WindRiver® Systems, Inc.; or (g) an appliance-based operating system, such as that implemented in handheld computers or personal data assistants (PDAs) (e.g., PalmOS® available from Palm® Computing, Inc., and Windows CE® available from Microsoft® Corporation). The operating system  142  can be configured to control the execution of other computer programs and provides scheduling, input-communication control, file and data management, memory management, and communication control and/or related services. 
         [0030]    A system component embodied as software may also be construed as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When constructed as a source program, the program is translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory  140 , so as to operate properly in connection with the operating system  142 . 
         [0031]    When the allocation system  111  is in operation, the processing device  138  is configured to execute software stored within the memory  140 , to communicate data to and from the memory  140 , and to generally control operations of the allocation system  111  pursuant to the software. Software in memory  140 , in whole or in part, is read by the processing device  138 , perhaps buffered, and then executed. The allocation system  111  accesses WFM data from a WFM database  154  through I/O device  150 . Multi-site allocation recommendations  144  are determined and made available to the contact center  110  through a networking device  152 . 
         [0032]      FIG. 3  is a flowchart illustrating functionality associated with the embodiment of the system of  FIG. 2 . Specifically, the functionality depicted in  FIG. 3  is associated with the multi-site allocation recommendations system  144 . In this regard, the functionality begins by assimilating WFM data  160  from forecasted call volume data  156  and other site data  158 . Examples of other site data would include employees, work schedules, time off preferences, event type priorities, etc. The WFM data could be retrieved from a WFM database  154  (see  FIG. 2 ) and processed by the processing device  138  (see  FIG. 2 ) for use in the multi-site allocation recommendations system  144 . Forecasted contact volume data  156  is made up of a contact volume for some period of time and an average interaction time forecast. As a non-limiting example, a contact volume forecast could be the reception of 25 customer support calls over a 15 minute window from 9:00 A.M. to 9:15 A.M. The time window could, of course be adjusted to suit the particular circumstance and/or other requirements. Average interaction time forecast, as a non-limiting example, could be that an average sales call requires two minutes and forty-five seconds of contact center agent  120  support. Of course, different type events would require different levels of interaction time and/or follow-up time that could also be included in the forecast. The contact volume and average interaction time forecast is an attempt to forecast the total incoming contact volume and the total time required to handle that contact volume at the top level, being the distributed centralized level. The WFM history available enables the allocation system  111  to forecast the incoming workload that must be distributed to the available sub-centers  114 ,  116  and  118 . 
         [0033]    Block  162  shows the creation of distributed queues, sub-queues and distributed campaigns. A distributed campaign is an entire operation, while a distributed queue includes events related to that operation. A distributed campaign could have more than one distributed queue. As a non-limiting example, when a distributed campaign involves a particular product, a distributed queue could entail a stream of events related to that product. In block  164 , sub-campaigns are created for each distributed campaign. Sub-campaigns are a portion of the entire operation including sub-queues and employees. Sub-queues are derived from a distributed queue and are a stream of events routed to a particular sub-center. An event from the sub-queue is distributed to the employees or agents available to handle that event. In block  166 , for each sub-campaign, the sub-queues, skills, organizations and employees are linked to that sub-campaign. Finally, the multi-site algorithm is applied in block  168 . 
         [0034]    Within a distributed campaign, events are routed from a distributed queue through sub-queues to various sub-centers and then to individual agents. Sub-campaigns comprise various sub-queues as input streams of events to a sub-center and the contact center agents assigned to that sub-center. The queues overlap with the campaigns based on agent availability and capability. 
         [0035]      FIG. 4  illustrates an example of a distributed campaign such as created in block  162 . One or more distributed queues  170 ,  172  stream into the contact center  110 . A distributed queue  170 ,  172  is a centralized incoming stream of events coming into the contact center  110  to be distributed to some sub-center  114 ,  116 ,  118 . The event could be a phone call, voice over internet protocol or email, among others. 
         [0036]      FIG. 4  shows events distributed to sub-center  114  through sub-queues  174 ,  176 . Likewise events are shown distributed to sub-center  116  through sub-queues  178 ,  180  and events are shown distributed to sub-center  118  through sub-queue  182 . 
         [0037]    As a non-limiting example, distributed queue  170  could include phone calls for customer support and the contact center agents  120  specializing in customer support might be located at sub-center  114  and at sub-center  116 . The customer support events would be routed through sub-queue  174  to sub-center  114  and through sub-queue  178  to sub-center  116 . Further, the customer support events might be directed toward different types of support issues, for example installation issues and technical support issues. The sub-queues could be directed toward specific types of events. Installation issues could be routed through sub-queue  174  to sub-center  114  and sub-queue  178  to sub-center  116 . Technical support issues could be routed through sub-queue  176  to sub-center  114  and sub-queue  180  to sub-center  116 . A contact center agent  120  at each sub-center would receive events related to their specific skill-set. Notably, a contact center agent  120  could have multiple skill-sets such that a single contact center agent  120  could handle events related to both installation issues and technical support issues in this example. Additionally, distributed queue  172  could include phone calls for sales and the contact center agent(s)  120  specializing in sales might be located at sub-center  118 . The sales events would be routed through sub-queue  182  to sub-center  118 . 
         [0038]      FIG. 5  illustrates a sub-campaign as created in block  164 . One or more sub-queues  174 ,  176  stream into the sub-center  114 . Similarly, at least one sub-queue streams into each sub-center. A sub-queue  174 ,  176  is a centralized incoming stream of events coming into the sub-center  114  to be distributed to contact center agents  120 ,  122  and  124 . Of course, the number of contact center agents  120  varies with each contact center in accordance with actual and recommended allocations.  FIG. 5  shows events  184 ,  186  distributed to contact center agent  120 . Likewise events  188  are shown distributed to contact center agent  122  and events  190 ,  192  are shown distributed to contact center agent  124 . Notably, a sub-center  114  can receive different streams of events, for example, from sub-queue  174  and sub queue  176 , and a contact center agent  120  can receive events from a single sub-queue  174  or from multiple sub-queues  174 ,  176 . Thus, event  184  to contact center agent  120  could derive from sub-queue  174  while event  186  could derive from sub-queue  176 . 
         [0039]      FIG. 6  is a flowchart illustrating an exemplary process for determination of recommended allocations by the allocation system  111  in  FIG. 2 . Specifically, the functionality depicted in  FIG. 6  provides greater detail of the flowchart in  FIG. 3  associated with the multi-site allocation recommendations system  144 . In block  162  distributed queues, sub-queues and distributed campaigns are created. In block  164 , sub-campaigns are created for each distributed campaign. In block  166 , for each sub-campaign, the sub-queues, skills, organizations and employees are linked to that sub-campaign. 
         [0040]    Next, a multi-site algorithm is applied to the distributed campaign using a virtual contact center. The WFM data  160  is used to create contact volume, average interaction time forecasts and service goals in block  194  for the distributed campaign. The forecast is for total incoming event volume and the total time it will take to handle that event volume at the distributed centralized level. The goal is to forecast the workload that is coming in to the contact center  110  and that must be distributed to the sub-centers  114 ,  116 ,  118 . The forecast is processed as if the distributed campaign were a virtual (non-distributed) campaign. A non-distributed or virtual campaign assumes that all contact center agent(s)  120  are in one location. The next step  196  determines whether schedules have been set in each sub-campaign. If the contact center agent(s)  120  in a sub-campaign have not been assigned schedules, then a multi-site scheduling program is executed in block  198  (see  FIG. 7 ). Otherwise, if scheduling is already set, then the sub-campaign allocations are calculated in block  200  (see  FIG. 8 ) as if all contact center agents  120  are in a virtual environment. This allocation assumes that an event could be routed to any available contact center agent  120  regardless of the actual sub-center  114 ,  116  and  118  in which that contact center agent  120  is actually located. 
         [0041]    A discrete event-based simulation is performed to achieve allocations. Many simulations can be performed and then averaged together. The results are then analyzed in block  202  to determine to which sub-center the events were routed according to which contact center agents  120  received the event. The results could signify that for a certain time period, a particular percentage of calls were routed to the contact center agent(s)  120  at sub-center  114 . For example, if  17 % of events go to sub-center  114 ,  38 % of events go to sub-center  116  and the remaining events go to sub-center  118 , then it would be recommended that sub-center  114  will receive  17 % of the routed events and should staff accordingly. 
         [0042]      FIG. 7  is a flowchart illustrating an embodiment of a multi-scheduling algorithm such as used in block  198  of  FIG. 6 . The multi-scheduling algorithm is performed such as when there is no schedule available for the contact center agents  120 . A sub-center schedule, or partial schedule, is used if available. The multi-scheduling algorithm begins at block  204  by treating contact center agent(s)  120  as suitably skilled for the distributed queue if they are skilled for any sub-queue of the distributed queue. For example, in block  206 , the forecasts for contact volume, average interaction times and service goals are set to apply directly to the distributed queue instead of to any sub-queue. Finally, in block  208 , the contact center agents  120  are scheduled using algorithms for non-multi-site operations applied to the distributed queue while also meeting contact center agent  120  work rules, time-off requirements and other preferences. The scheduling system operates as if all contact center agents  120  are available at one site, or a virtual center. The resulting schedule is the schedule that would be available in a virtual center. That schedule is then applied to the sub-centers for determining the recommended allocations. 
         [0043]    In an alternative embodiment, contact center systems may also account for scheduled training of contact center agents  120 . In the system  100  (see  FIG. 1 ), additional WFM capability may include a learning component that allows a contact center manager to develop training lessons for and assign lessons to contact center agents  120 . The learning component provides automated training processes by identifying, scheduling, and delivering online learning directly to contact center agent  120  desktops. The lesson content can include recorded interactions, which can be used to create a library of best practices for training agents and other personnel. Using actual interactions, a contact center  110  can develop E-learning content specific to the organization. In an enhancement, these training lessons can include assessments to help track and measure agent performance, skill acquisition, and knowledge retention. 
         [0044]    The learning component can also deliver targeted learning sessions over a network, using e-mail, or a hyperlink to a Web site, or directly to the agent desktop. Supervisors can select the appropriate training sessions from a library of courseware or create sessions themselves using a contact editing feature. Then supervisors can assign course material and monitor completion automatically. 
         [0045]    When creating a schedule for a multi-site contact center  110 , the multi-site scheduling algorithm will include training events, in addition to shift assignments, breaks and other preferences. Thus, scheduling for multiple sites also includes the scheduling of training events for the individual agents at the individual sites. If the learning sessions are pre-scheduled, then the multi-site scheduling algorithm and/or the discrete event-based simulation will take the learning sessions into account as training events. Alternatively, the training events could be considered along with other events in the discrete event-based simulation discussed in greater detail below. 
         [0046]    In addition to scheduled training of contact center agents  120 , integrated workforce optimization platforms can also integrate other capabilities in support of a greater customer service strategy: (1) Quality Monitoring/Call Recording—voice of the customer; the complete customer experience across multimedia touch points; (2) Workforce Management—strategic forecasting and scheduling that drives efficiency and adherence, aids in planning, and helps facilitate optimum staffing and service levels; (3) Performance Management—key performance indicators (KPIs) and scorecards that analyze and help identify synergies, opportunities and improvement areas; (4) e-Learning—training, new information and protocol disseminated to staff, leveraging best practice customer interactions and delivering learning to support development; and/or (5) Analytics—deliver insights from customer interactions to drive business performance. These five segments can become part of an interwoven and interoperable solution, enabling contact centers to transition from reactive cost centers to proactive, information-rich departments that deliver strategic value to the organization. Workforce optimization is discussed in greater detail in the U.S. Patent Application entitled “Systems and Methods for Workforce Optimization,” filed Feb. 22, 2006, and assigned application Ser. No. 11/359,356, which is entirely incorporated herein by reference. 
         [0047]    In a non-limiting example of integration with other workforce optimization capabilities, contact center agent  120  allocations could be compared against actual event distribution to determine whether the allocations were satisfactory. Other integration points with workforce optimization capabilities may also be useful in context of the allocation and scheduling of contact center agents. 
         [0048]      FIG. 8  is a flowchart illustrating an embodiment of the calculation of sub-campaign allocations of  FIG. 6 . The sub-campaign allocation algorithm  200  preferably is performed once the contact center agents&#39;  120  schedule is set. If there is no schedule, then the sub-campaign allocation algorithm  200  is run after the multi-site scheduling algorithm. The sub-campaign allocation algorithm  200  begins at block  210  by treating contact center agents  120  as suitably skilled for the distributed queue if they are skilled for any sub-queue of the distributed queue. In block  212 , the forecasts for contact volume, average interaction times and service goals are set to apply directly to the distributed queue instead of to any sub-queue. In block  214 , a discrete event-based simulation (discussed in greater detail below) is performed on the pseudo-virtual campaign. Events are routed to available contact center agents  120  as if they are in the same location. In block  216 , allocation recommendations are made for each sub-campaign of a distributed queue and time interval. 
         [0049]    In an alternative embodiment, training events may also be included along with events during the calculation of sub-campaign allocations. Training events, or learning sessions, may be included along with other qualifications limiting the availability of the contact center agents  120 . 
         [0050]      FIG. 9  is a flowchart illustrating an embodiment of a discrete event-based simulation  214  as in  FIG. 8 . Multiple WFM data input parameters are available for the discrete event-based simulation  214 . Block  220  shows that parameters related to the contact center agent  120 , such as agent skills and agent schedules, are input. Additionally, for each distributed queue, the contact volume and average interaction time forecast are also available as inputs. Block  222  shows that randomly distributed event arrival times are created based on the contact volume and average interaction times. 
         [0051]    As a non-limiting example, if the contact volume and average interaction time forecast indicates that between 8:00 A.M. and 9:00 A.M. the contact center  110  expects to receive ten events that are expected to require two minutes on average, then a random distribution will be created for the events during that time interval. 
         [0052]    Block  224  shows that contact center agent  120  schedule events are created for changes in the contact center agent  120  availability. Schedule events for a contact center agent  120  could correspond to arrival, meeting, lunch breaks and departure, among others. A contact center agent  120  changing from one status to another is considered an agent schedule event. 
         [0053]    Block  226  shows that for each event, the discrete event-based simulation  214  determines whether it is a contact arrival event or an agent schedule event. For the arrival of an event, as shown in block  230 , the event is routed to a contact center agent  120 . The discrete event-based simulation  214  finds an unoccupied contact center agent  120 , routes the event to the contact center agent  120  and marks the contact center agent  120  occupied for the duration of the event. When an event is processed, the discrete event-based simulation  214  records to which contact center agent  120  the event was routed. For an agent schedule event, as shown in block  228 , the discrete event-based simulation  214  changes the contact center agent&#39;s  120  availability status from one state to another. The contact center agent&#39;s  120  status could be as simple as available state versus unavailable state. Of course, other states could also be set dependent upon contact center requirements. 
         [0054]    The discrete event-based simulation  214  continues until all events are processed. After all events are processed, the allocations are analyzed to determine what percentage of events went to contact center agents  120  of the respective sub-centers. Even though the discrete event-based simulation  214  performed the simulation as if all contact center agents  120  were present in a non-distributed contact center, the percentage distribution is calculated based on the contact center to which the contact center agents  120  are assigned. Multiple passes of the discrete event-based simulation  214  can be performed to determine average percentages of event distribution. The average distribution can then be used for recommended allocations to the various sub-centers as shown in block  232 . 
         [0055]    It should be noted that many available simulators are well known in the art and could be utilized to perform the discrete event-based simulation  214 . The emphasis is on the simulation rather than the simulator itself. The discrete event-based simulation  214  treats the allocation of events as if the sub-centers, and thus the contact center agents  120  are not distributed. 
         [0056]    The various sub-centers may keep the recommended allocation as provided by the allocation system  111  and adjust staff for the sub-campaign according to the percentage of events expected during the time accounted for by the simulation. Additionally, the sub-center may adjust the staffing and re-execute the allocation system  111  for new recommendations based on the adjusted staffing. Any change to the forecast or to the contact center agents  120  will affect the recommended allocations since the allocation system  111  treats the distributed campaign as one contact center. An iterative process of creating recommended allocations and then sub-centers adjusting the forecast and/or agents allows convergence to an optimal staffing. 
         [0057]    It should be noted that the flowcharts included herein show the architecture, functionality and/or operation of implementations that may be configured using software. In this regard, each block can be interpreted to represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. 
         [0058]    It should be noted that any of the executable instructions, such as those depicted functionally in the accompanying flowcharts, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium could include a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), and a portable compact disc read-only memory (CDROM) (optical). In addition, the scope of the certain embodiments of this disclosure can include embodying the functionality described in logic embodied in hardware or software-configured mediums. 
         [0059]    It should be emphasized that the above-described embodiments are merely possible examples of implementations, merely set forth for a clear understanding of the principles of this disclosure. Many variations and modifications may be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure.