Method and System for Scalable Contact Center Agent Scheduling Using Automated AI Modeling and Multi-Objective Optimization

JP7864113B2Active Publication Date: 2026-05-22GENESIS CLOUD SERVICES CO LTD
View PDF 7 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
GENESIS CLOUD SERVICES CO LTD
Filing Date
2021-07-26
Publication Date
2026-05-22

AI Technical Summary

Technical Problem

Contact center scheduling is an NP-hard problem that is difficult to solve optimally due to competing goals of providing excellent customer service while minimizing labor costs, and existing methods struggle to efficiently handle large workloads with complex constraints.

Method used

A system using automated AI modeling and multi-objective optimization through column generation to generate optimized contact center agent schedules, incorporating workload forecasting, staffing requirements, and constraint programming to balance service levels and cost efficiency.

Benefits of technology

The system provides scalable and efficient agent scheduling that optimizes workload coverage while adhering to labor laws and employee preferences, reducing costs and improving service quality.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007864113000039
    Figure 0007864113000039
  • Figure 0007864113000040
    Figure 0007864113000040
  • Figure 0007864113000041
    Figure 0007864113000041
Patent Text Reader

Abstract

According to one embodiment, a system for performing contact center agent scheduling includes at least one processor and at least one memory containing a plurality of instructions stored thereon, the instructions, upon execution by the at least one processor, causing the system to: generate a workload forecast indicative of demand introduced to the contact center in a future planning period based on a workload forecast model and time series data; generate a staffing requirements forecast indicative of the number of agents needed to handle the workload forecast based on the workload forecast, one or more service goals, and a staffing requirements model; and perform schedule optimization using column generation to generate an optimized contact center agent shift schedule for a plurality of agents based on the staffing requirements forecast and one or more constraints.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority and benefit based on U.S. Provisional Application No. 63 / 055,934, filed on July 24, 2020, entitled "Method and System for Scalable Contact Center Agent Scheduling Utilizing Automated AI Modeling and Multi - Objective Optimization", the content of which is hereby incorporated by reference in its entirety into this specification.

Background Art

[0002] Contact centers are operated under competing goals, that is, while desiring to provide the best possible service to customers, it is also desired to save costs. To that end, contact centers typically employ agents and create schedules for the agents to handle the expected workload. The times during which these agents can work are restricted by labor laws, individual contract agreements, and / or other factors.

[0003] Inappropriately estimating the workforce can lead to a decline in service levels and long waiting times, so it is important to find a good match between the predicted workload and the scheduled workforce. One way to avoid this is to schedule a sufficiently large number of employees. However, since contact centers also have to meet economic goals (e.g., minimizing labor costs), it is generally not desirable to over - schedule employees. Therefore, the cost reduction obtained from leveraging scheduling techniques can be significant.

[0004] Resource scheduling is a well-known problem that has been proven to be NP-hard. Therefore, as the problem increases, the time required is likely to increase faster than a polynomial. Thus, finding a good solution to these highly constrained and complex scheduling problems in a timely manner is extremely difficult. Finding an optimal solution that minimizes costs, satisfies employee preferences, distributes shifts equally among employees, and satisfies all workplace / business constraints is even more challenging. [Overview of the project]

[0005] One embodiment relates to a proprietary system, components, and method for performing contact center agent scheduling. Other embodiments relate to apparatus, systems, devices, hardware, methods, and combinations thereof for performing contact center agent scheduling.

[0006] According to one embodiment, a system for performing contact center agent scheduling may include at least one processor and at least one memory containing a plurality of stored instructions, the instructions causing the system to perform, in response to execution by at least one processor, a workload forecast indicating the demand to be introduced into the contact center in a future planning period based on a workload forecast model and time series data; a staffing requirements forecast indicating the number of agents required to process the workload forecast based on the workload forecast, one or more service objectives and staffing requirements models; and a schedule optimization using column generation to generate an optimized contact center agent shift schedule for multiple agents based on the staffing requirements forecast and one or more constraints.

[0007] In some embodiments, each column added during column generation may correspond to an expected shift schedule.

[0008] In some embodiments, one or more constraints may include at least one of the maximum shift duration, the earliest shift start time, or the latest shift end time.

[0009] In some embodiments, the instructions may further cause the system to automatically generate either a batch processing workload prediction model or an ad-hoc workload prediction model based on automated call distribution data from the contact center.

[0010] In some embodiments, automatically generating one of either a batch processing workload prediction model or an ad-hoc workload prediction model may include receiving historical time series data to be predicted, performing hierarchical time dimension extraction, performing outlier detection and pattern recognition, and comparing prediction methods across multiple validation periods using cross-validation with multiple splits.

[0011] In some embodiments, performing outlier detection and pattern recognition may include detecting seasonality and trends in the data.

[0012] In some embodiments, performing schedule optimization using column generation may include solving a relaxed master problem and adding columns until at least one termination criterion is met.

[0013] In some embodiments, at least one termination criterion may include determining that there are no new columns available for addition, or determining that a threshold number of column generation iterations has been reached.

[0014] In some embodiments, the system may further include or be embodied as a contact center system, and the commands may further cause the system to automatically incorporate an optimized contact center agent shift schedule into the contact center system.

[0015] According to another embodiment, one or more non-temporary machine-readable storage media may include a plurality of instructions, which, in response to execution by at least one processor, can cause the system to: generate a workload forecast indicating the demand to be introduced into the contact center during a future planning period, based on a workload forecast model and time-series data; generate a staffing requirements forecast indicating the number of agents required to process the workload forecast, based on the workload forecast, one or more service objectives, and a staffing requirements model; and perform schedule optimization using column generation to generate an optimized contact center agent shift schedule for multiple agents, based on the staffing requirements forecast and one or more constraints.

[0016] In some embodiments, each column added during column generation may correspond to an expected shift schedule.

[0017] In some embodiments, one or more constraints may include at least one of the maximum shift duration, the earliest shift start time, or the latest shift end time.

[0018] In some embodiments, the instructions may further cause the system to automatically generate either a batch processing workload prediction model or an ad-hoc workload prediction model based on automated call distribution data from the contact center.

[0019] In some embodiments, automatically generating one of either a batch processing workload prediction model or an ad-hoc workload prediction model may include receiving historical time series data to be predicted, performing hierarchical time dimension extraction, performing outlier detection and pattern recognition, and comparing prediction methods across multiple validation periods using cross-validation with multiple splits.

[0020] In some embodiments, performing outlier detection and pattern recognition may include detecting seasonality and trends in the data.

[0021] In some embodiments, performing schedule optimization using column generation may include solving a relaxed master problem and adding columns until at least one termination criterion is met.

[0022] In some embodiments, at least one termination criterion may include a determination that there are no new columns available for addition or a determination that a threshold number of iterations of column generation has been reached.

[0023] According to yet another embodiment, a method of performing contact center agent scheduling includes generating, by a contact center system, a workload prediction indicative of demand to be introduced into the contact center during a future planning period based on a workload prediction model and time series data; generating, by the contact center system, a staffing requirement prediction indicative of the number of agents required to process the workload prediction based on the workload prediction, one or more service goals, and a staffing requirement model; and performing, by the contact center system, schedule optimization using column generation to generate an optimized contact center agent shift schedule for a plurality of agents based on the staffing requirement prediction and one or more constraints.

[0024] In some embodiments, each column added during column generation may correspond to a prospective shift schedule.

[0025] In some embodiments, performing schedule optimization using column generation may include solving a relaxed master problem and adding columns until at least one termination criterion is met.

[0026] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter. Further embodiments, forms, features, and aspects of the present application will become apparent from the description and figures provided herein.

Brief Description of the Drawings

[0027] The concepts described herein are illustrative by way of example and not as limitations in the accompanying drawings. For the sake of simplicity and clarity of illustration, the elements illustrated in the figures are not necessarily drawn to scale. Where appropriate, reference labels are repeated between the drawings to indicate corresponding or similar elements. [Figure 1] It is a simplified flowchart of at least one embodiment of a method for performing a periodic model building batch process. [Figure 2] It is a simplified flowchart of at least one embodiment of a method for performing contact center agent scheduling. [Figure 3] It is a simplified flowchart of at least one embodiment of a method for processing workload prediction requests. [Figure 4] It is a simplified flowchart of at least one embodiment of a method for building a workload prediction model. [Figure 5] It is a simplified flowchart of at least one embodiment of a method for building a workload prediction model. [Figure 6] It is a simplified flowchart of at least one embodiment of a method for performing a four-way "rolling target period" cross-validation. [Figure 7] It is a simplified flowchart of at least one embodiment of a method for processing staffing requirement prediction requests. [Figure 8] It is a simplified flowchart of at least one embodiment of a method for performing scheduling optimization. [Figure 9]This is a simplified flowchart of at least one embodiment of a method for performing column generation. [Figure 10] An example table is provided to identify exemplary shift constraints used in subproblems and their corresponding definitions. [Figure 11] An example table is provided to identify exemplary shift constraints used in subproblems and their corresponding definitions. [Figure 12] This is a simplified block diagram of at least one embodiment of a call center system. [Figure 13] This is a simplified block diagram of at least one embodiment of a computing system. [Modes for carrying out the invention]

[0028] While the concepts of this disclosure are susceptible to various modifications and alternative forms, specific embodiments are shown as examples in the drawings and described in detail herein. However, it should be understood that the concepts of this disclosure are not intended to be limited to any specific form disclosed, but rather to encompass all modifications, equivalents, and alternatives that are consistent with this disclosure and the appended claims.

[0029] References such as “one embodiment,” “one embodiment,” and “explanatory embodiment” indicate that the embodiments described may include certain features, structures, or characteristics, but not all embodiments may necessarily include or may not include certain features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiments. References to “preferred” components or features may indicate that certain components or features are desirable in relation to one embodiment, but it should be further understood that this disclosure does not so limit itself to other embodiments in which such components or features may be omitted. Furthermore, where certain features, structures, or characteristics are described in relation to an embodiment, implementation of such features, structures, or characteristics in relation to other embodiments, whether explicitly described or not, should be assumed to be within the knowledge of those skilled in the art. Furthermore, certain features, structures, or characteristics may be combined in any preferred combination and / or partial combination in various embodiments.

[0030] Furthermore, please understand that items included in a list in the form of "at least one of A, B, and C" can mean (A), (B), (C), (A and B), (B and C), (A and C), or (A, B, and C). Similarly, please understand that items enumerated in the form of "at least one of A, B, or C" can mean (A)(B), (C), (A and B), (B and C), (A and C), or (A, B, and C). Furthermore, with respect to the claims, the use of words and phrases such as “one (a),” “one (an),” “at least one,” and / or “at least one portion” should not be interpreted as limiting to only one of such elements unless otherwise stated, and the use of phrases such as “at least a portion,” and / or “a portion,” should be interpreted as encompassing both embodiments that include only a portion of such elements and embodiments that include the whole of such elements, unless otherwise stated.

[0031] The disclosed embodiments may, depending on the circumstances, be implemented in hardware, firmware, software, or a combination thereof. The disclosed embodiments may also be implemented as instructions executed or stored in one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media that can be read and executed by one or more processors. The machine-readable storage media may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., volatile or non-volatile memory, media disk, or other media device).

[0032] Drawings may show certain structural or methodological features in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not always be necessary. Rather, in some embodiments, such features may be arranged in a different way and / or order than those shown in the illustrative drawings, unless otherwise indicated. Furthermore, the inclusion of structural or methodological features in a particular drawing does not mean that such features are required in all embodiments; in some embodiments, they may be omitted or combined with other features.

[0033] As described above, as contact center scheduling problems grow, scheduling optimization models may become too large to solve in a reasonable amount of time using conventional techniques. Therefore, the techniques described herein leverage automated and validated AI prediction and modeling in conjunction with column generation to create a scalable, multi-purpose agent scheduling system that can handle very large cases and a variety of objectives. More specifically, in some embodiments, the techniques leverage a state-of-the-art solver (e.g., IBM ILOG CPLEX) with a contact center scheduling algorithm that takes workload and staffing requirement predictions generated by an AI model as input and uses column generation along with linear programming (LP) to optimize a set of specific objective master problems (e.g., service performance, agent preferences, payment costs, etc.) and constraint programming (CP) to solve subproblems to find potential candidates for the best agent shifts. Furthermore, in illustrative embodiments, a high-leverage modeling language (e.g., Optimization Programming Language, OPL) is used, which allows for seamless expansion with more features and capabilities (e.g., new constraints, automatic self-scheduling, etc.).

[0034] As described below, the techniques described herein include: determining the expected number of workload interactions (e.g., calls, emails, chats, back-office tasks, etc.) during a planned period, and the service time (e.g., average processing time) associated with those interactions; converting the workload forecasts from the first phase into staffing or personnel requirements for future planned periods; and performing scheduling that satisfies the personnel requirements by staffing personnel throughout the planned period according to shift and schedule constraints. The final output is a schedule or worksheet that optimizes (or near-optimizes) workload coverage by staffed agents.

[0035] In some embodiments, the system can leverage a big data infrastructure (e.g., using Apache Hadoop and Spark) to automatically build and validate both workload prediction models and staffing requirement models. In this process, the system can ingest archived event and historical aggregate data from a contact center platform (e.g., contact center system 1200) and use data from the start of a time period to the present time to batch build models for all customers and all queue streams. Batch building may be performed nightly (or according to another period), providing a closed feedback loop for continuous model improvement. These models can then be used during inference when API requests are processed by the corresponding services.

[0036] Referring to Figure 1, when in use, the system may perform method 100, which performs a batch process for constructing a period model. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or a system / device thereof. It should be understood that certain blocks of method 100 are illustrated as examples, and such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0037] An illustrative method 100 begins with block 102, where the system receives automatic call distribution (ACD) data. For example, the ACD data may include contact volume, average processing time, full-time equivalency (FTE), capture rate, contact processing data by contact type, contact processing data by personnel type, and / or other relevant ACD data for a specified time interval.

[0038] In block 104, the system constructs one or more contact center models for use when performing contact center scheduling. In particular, in block 106, the system may generate a workload forecasting model, and in block 108, the system may generate a staffing model. It should be understood that the workload forecasting model and / or staffing model may be generated according to any preferred algorithm and / or technique. For example, in some embodiments, the workload forecasting model may be generated according to a method similar to the method described with reference to method 400 in Figures 4-5. Furthermore, the workload forecasting model and / or staffing model may be formatted or represented in any way that can be used by a system as described herein. In some embodiments, the workload forecasting model may be embodied as a model representing a forecast of how the contact center workload (e.g., across a contact center system 1200) may change over time. Furthermore, it should be understood that the workload forecasting model may include multiple different time granularities (e.g., 15 minutes, 30 minutes, etc.). In some embodiments, the staffing model may be embodied as a model representing a forecast of how staffing requirements will be adjusted to meet various workloads.

[0039] In block 110, the system determines whether the batch period has elapsed. If it has, method 100 returns to block 102, where the system again receives a new batch of ACD data to process as described above. For example, the batch period may be one day, two days, an hourly period, or another predetermined period. In other embodiments, method 100 may be re-executed depending on whether one or more other criteria are met. In an illustrative embodiment, it should be understood that the system performs method 100 as part of nightly batch processing.

[0040] Although blocks 102-110 are described in a relatively serial manner, it should be understood that various blocks of Method 100 can be implemented in parallel in some embodiments.

[0041] Referring here to Figure 2, when in use, the system may perform method 200 for scheduling contact center agents. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or such system / device. It should be understood that certain blocks of method 200 are illustrated as examples, and such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0042] An illustrative method 200 begins in block 202 where the system receives an API request (e.g., for an optimized contact center agent schedule). In block 204, one or more input data (e.g., ACD data, API request data, and / or other data) may be preprocessed. In block 206, the system retrieves a relevant workload prediction model, and in block 208, the system generates a workload prediction based on the workload prediction model. For example, in some embodiments, the system may perform method 300 in Figure 3, described below, to retrieve a workload prediction model and generate a workload prediction. However, in other embodiments, the system may retrieve a relevant model and / or generate a workload prediction in a different manner.

[0043] In block 210, the system retrieves relevant staffing models, and in block 212, the system generates staffing requirement predictions based on the staffing models. For example, in some embodiments, the system may perform method 700 in Figure 7, described below, to retrieve staffing models and generate staffing requirement predictions. However, in other embodiments, the system may retrieve relevant models and / or generate staffing requirement predictions in other ways.

[0044] In block 214, the system performs scheduling optimization to generate an optimized contact center agent schedule. It should be understood that in some embodiments, the system may perform this by the method 800 shown in Figure 8, which is described below. However, it should be understood that in other embodiments, the system may perform scheduling optimization in other ways.

[0045] Although blocks 202-214 are described in a relatively serial manner, it should be understood that various blocks of Method 200 may be implemented in parallel in some embodiments.

[0046] Referring here to Figure 3, when in use, the system may perform method 100 for processing workload forecasting requests. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or such system / device. It should be understood that certain blocks of method 300 are illustrated as examples, and such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0047] Illustrative Method 300 begins with block 302, in which the system determines whether a batch-generated workload prediction model is available. It should be understood that, as described above with reference to Method 100 in Figure 1, the system may periodically (e.g., nightly) perform batch processing to build / update the workload prediction model based on available ACD data. However, under certain circumstances, the workload prediction model from the previous night's batch processing may be unavailable (e.g., due to errors, changes in the configuration of the contact center system queue, systemic changes in the routing strategy, etc.). A workload prediction model can be defined as the best method to apply to time-series data and the optimal set of parameters that yield the best key performance indicator (KPI) metrics used to validate the accuracy of the prediction. These models may then be stored in a data persistence tier (e.g., AWS S3 or DynamoDB) for use for any workload prediction requests to be processed the following day.

[0048] If the system determines in block 304 that a batch generation workload prediction model is available, method 300 proceeds to block 306, where the system searches for the best available batch generation model. However, if the system determines in block 304 that a batch generation workload prediction model is not available, method 300 proceeds to block 308, where the system generates an ad-hoc workload prediction model. It should be understood that the core algorithm for the ad-hoc generation process may be the same as the algorithm executed during nightly batch processing, for example, to ensure consistency in the quality of results from both processes. In some embodiments, the system may perform method 400 as shown in Figures 4-5 to generate an ad-hoc workload prediction model. However, it should be understood that in other embodiments, the ad-hoc workload prediction model may be generated by a different method.

[0049] In block 310, the system calculates n-step workload forecasts for the planning period, and in block 312, the system returns the best forecast for all hierarchical time dimensions in the planning period. In other words, the system forecasts the workload or demand to be introduced into the contact center system (e.g., contact center system 1200) in future planning periods. It should be understood that the basic forecast may be specified as a sequence of metrics corresponding to time intervals (e.g., volume provided and average handle time (AHT)) and may be generated for various time granularities (e.g., 5-minute intervals, 15-minute intervals, 30-minute intervals, or 1-hour intervals). As described below, the workload forecast may be translated into staffing requirement forecasts used in the scheduling process.

[0050] Although blocks 302-312 are described in a relatively serial manner, it should be understood that various blocks of Method 300 may be implemented in parallel in some embodiments.

[0051] Referring here to Figures 4 and 5, the system may, when in use, perform Method 400 to construct a workload prediction model. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or a system / device thereof. Certain blocks of Method 400 are illustrated as examples, and it should be understood that such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0052] An illustrative method 400 begins in block 402 of Figure 4, where the system receives historical time series data to be predicted, along with causal and / or correlated time series, for example, as drivers or predictors for the prediction results. For example, in some embodiments, the causal series may include the number of subscribers on which the call volume prediction is based (as the number of subscribers increases, so do the expected calls made by those subscribers).

[0053] In block 404, the system performs hierarchical time dimension extraction. In other words, each time a workload forecasting request is made, multiple hierarchies of time-series streams (in terms of time dimension) may be created. For example, to obtain better accuracy, time-series input data may be summarized and then forecast at different time hierarchies (or granularities). In particular, as shown in the illustrative embodiments in Figures 4-5, data may be forecasted weekly 406, daily 408, and / or other interval distributions 410 (e.g., hourly, 5-minute, 10-minute, 30-minute granularities). It should be understood that lower-granularity streams (e.g., weekly) may be used both to find long-term seasonal and trend patterns, and as a baseline for higher-granularity forecasts (e.g., daily and interval levels) via distributions. For example, daily forecasts may be performed as distributions from weekly to daily rather than forecasting raw numerical values. Each of the different time streams may undergo processing similar to that outlined herein.

[0054] In block 412, the system performs various data cleanup and data preprocessing. For example, in some embodiments, feature engineering and preprocessing may be performed on each of the time-series data streams. In various embodiments, data cleanup and preprocessing may include one or more of the following: data cleanup such as data summarization and aggregation, missing data imputation, daylight saving time correction, sparse data normalization, data transformation (e.g., log normalization), cold-start data problem, and / or other data cleanup and preprocessing functions.

[0055] Outliers can cause significant problems in model building by resulting in highly skewed models; therefore, in block 414, the system performs outlier detection, for example, to identify data points that differ significantly from other observations. Thus, detecting and normalizing outliers is a crucial step in obtaining appropriate and accurate predictions. Outliers occurring on specific calendar days (e.g., the effects of holidays and trading days) can also be detected. In some embodiments, the system may utilize a seasonal hybrid (ESD) algorithm built on a general-purpose ESD algorithm to detect anomalies / outliers in the data. Furthermore, in some embodiments, the system may leverage iterative outlier detection, which is a custom technique tailored to contact center data aimed at iteratively detecting outliers. By repeatedly recalibrating the outlier detection model, the accuracy of outlier detection in the data can be improved. It should be understood that in various embodiments, the system may utilize any suitable algorithm and / or technique to identify outliers. Furthermore, the system may discard data points identified as outliers.

[0056] In block 416 of Figure 5, after cleaning the data (e.g., removing outlier data), the system may perform pattern recognition to ensure data integrity, for example, and an appropriate method may be selected for optimization. For example, in block 418, the system may detect seasonality in the data. In particular, for this purpose, the system may transform the data from the time domain to the frequency domain using an appropriate transformation (e.g., Fourier transform). It should be understood that the resulting periodogram shows the "power" of each possible frequency. Spectral analysis may then be performed to find the most prominent frequencies (e.g., repeatable patterns) that may indicate seasonality in the data. In block 420, the system may detect trends in the data. For example, the system may utilize linear trend estimation by relating observations to the time they occurred. Furthermore, in block 422, the system may apply one or more static methods to the data.

[0057] In block 424, the system compares various prediction methods based on the identified patterns. In block 426, in some embodiments, the system may perform cross-validation with multiple splits over multiple validation periods. In other words, depending on which patterns are detected, a number of statistical prediction methods that are classified and applied according to the discovered patterns can be applied, validated, and compared with one another (e.g., ARIMA, classical regression, dynamic regression, Holt-Winters, and custom proprietary prediction methods).

[0058] In block 428, the system can select and return the best prediction method for each time dimension. In particular, the system may select the single best method and its optimal hyperparameters that minimize prediction error, while considering both the short-term and long-term cross-validation strategies described herein. In other embodiments, a combination or ensemble of methods may be selected by optimizing the weighting coefficients of each method to yield the best prediction. For example, in some embodiments, the ensemble may consist of the five best methods (or any number of methods provided by the user or system) found during the cross-validation process.

[0059] Although blocks 402-428 are described in a relatively serial manner, it should be understood that various blocks of Method 400 may be implemented in parallel in some embodiments.

[0060] Referring here to Figure 6, a simplified method 600 is shown that performs four-part “rolling period” cross-validation of the data. As described above, the best method may be selected using multiple-part (e.g., k-part) cross-validation for different validation periods. The criteria used may be based on custom scoring, which is a combination of short-term accuracy metrics at 1 to 4 steps ahead (e.g., 1 to 4 weeks ahead) and long-term accuracy over the entire period (e.g., 6 months or 1 year ahead), depending on the available data. In some embodiments, depending on the size of the data, up to 10 short-term periods may be run, while up to 4 long-term periods may be run. Furthermore, this is done in “rolling intervals,” and the data is split into “training data” where the hyperparameters for the method are optimized and fine-tuned to best “fit” the training data pattern, and “test data” where the best-fitting method and its optimized parameters are “projected out” and their accuracy against the test data is evaluated. Method 600 in Figure 6 illustrates a four-part version of this process. It should be understood that the process helps ensure that the selected method yields workload forecasts that are good for both short-term and long-term timeframes. Therefore, in some embodiments, the resulting forecasts can be used not only for short-term tactical planning such as scheduling, but also for long-term strategic planning such as employment and capacity planning.

[0061] Referring here to Figure 7, when in use, the system may perform method 700 for processing staffing requirement prediction requests. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or a system / device thereof. It should be understood that certain blocks of method 700 are illustrated as examples, and such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0062] The illustrative method 700 begins with block 702, in which the system determines whether a batch-generated staffing model is available. It should be understood that, as described above with reference to method 100 in Figure 1, the system may periodically (e.g., nightly) perform batch processing to build / update staffing models. However, as described above, under certain circumstances, the staffing model from the previous night's batch processing may be unavailable (e.g., due to errors, changes in the configuration of the contact center system queues, systemic changes in the routing strategy, etc.).

[0063] If the system determines in block 704 that a batch-generated staffing model is available, method 700 proceeds to block 706, where the system searches for the best available batch-generated model. However, if the system determines in block 704 that a batch-generated staffing model is unavailable, method 700 proceeds to block 708, where the system generates an ad-hoc workload prediction model. It should be understood that the core algorithm for the ad-hoc generation process may be the same as the algorithm executed during nightly batch processing, for example, to ensure consistency in the quality of results from both processes. In some embodiments, to generate an ad-hoc staffing model, the system may perform a method similar to method 400 in Figures 4-5 for generating an ad-hoc workload prediction model (with appropriate modifications). However, it should be understood that the ad-hoc staffing model may be generated in other embodiments by other methods.

[0064] In block 710, the system calculates the staffing requirements for the planning period, and in block 712, the system returns the requested entities and the staffing requirements for the planning period.

[0065] Although blocks 702-712 are described in a relatively serial manner, it should be understood that various blocks of Method 700 can be implemented in parallel in some embodiments.

[0066] In other words, for example, after the workload and agent processing time (AHT) for a planned period have been predicted, the system may determine how many agents are needed to handle the predicted workload based on specific KPI targets (e.g., service level, average speed of answer (ASA), abandonment rate, customer satisfaction score, etc.). In some embodiments, this is done at the same granularity as the schedule operates (e.g., often in 15-minute / 30-minute / 60-minute cycles). In some embodiments, such staffing requirements are generated for each planning group. In some embodiments, inputs for determining staffing requirements may include workload predictions, the routing configuration of the contact center system, and / or other inputs.

[0067] It should be understood that the system can utilize various methods to generate staffing forecasts. In particular, in some embodiments, the system may apply heuristics to determine staffing levels, for example, by assuming steady-state arrivals at each time interval and smoothing the demand curve. While this approach allows for significant control, the heuristic can only support what is input to it, and this often results in suboptimal solutions because it cannot consider all valid combinations and permutations of potential solutions in the problem space. In another embodiment, the system may utilize discrete-event simulations that take into account many practical factors. However, such approaches are often computationally expensive and time-consuming. Sometimes, queuing models and simulations are combined to obtain ideal staffing requirements. In yet another embodiment, the system may utilize the Erlang C queuing model, which often works well for many contact center applications. While queuing models are elegant and can provide good theoretical and analytical results, it should be understood that they often fall short in terms of accuracy in real-world conditions when considering multi-skill agents, abandonment (e.g., Erlang C assumes no one will abandon a call), complex routing strategies, non-voice interactions, and / or other real-world conditions.

[0068] However, in an exemplary embodiment, the system utilizes custom mathematical modeling via a data-driven, machine learning-based approach validated against historical ACD data by combining the best of the options described above. A robust and mathematically proven optimal solution can be obtained by combining customer patience profiles, supporting different routing configurations for voice, chat, callbacks, email, casework, and / or back-office interactions, with a queuing model.

[0069] Similar to workload forecasting, a big data infrastructure is leveraged, and an automated nightly batch process is executed to build and validate a steady-state contact center model using the latest available historical ACD data (e.g., the past 90 days). The generated model is then used to calculate staffing requirements for scheduling purposes. As shown above, the nightly batch process provides a closed feedback loop to improve model accuracy by taking into account new ACD interactions throughout the day.

[0070] In an illustrative embodiment, the process of generating staffing requirements for each planning period begins by taking workload forecasts and KPI targets (e.g., service level, ASA, abandonment rate, etc.) as input. The system may leverage a service performance computer built using a validated and optimized contact center model that takes workload forecasts and agent counts to generate a set of predicted KPIs. To obtain the optimal staffing requirement level, the agent count may be iteratively increased (e.g., using a binary algorithm) until the KPIs predicted by the computer meet the desired specified KPI targets. In some embodiments, if there are multiple KPI targets, all targets must be met. After all optimal staffing requirements for each planning period have been calculated, the system may optimize shift scheduling to match the available staffing to anticipated needs or requirements, as described below.

[0071] Referring here to Figure 8, the system may, when in use, perform method 800 for scheduling optimization. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13), and / or a contact center system (e.g., contact center system 1200 in Figure 12), or such system / device. Certain blocks of method 800 are illustrated as examples, and it should be understood that such blocks may be combined, divided, added, removed, and / or rearranged, in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0072] After staffing requirements are known from previous phases, the system can derive shifts that can handle the requirements. Thus, the illustrative method 800 begins with block 802, where the system receives / retrieves a list of agents and staffing requirement forecasts (in addition to, for example, the number of weeks / days to be scheduled). It should be understood that the list of agents may include, for example, the work rules associated with the agent (e.g., work hours, regulatory requirements), the capabilities of each agent (e.g., expertise in various fields), and / or other relevant criteria useful for deriving shifts from the staffing requirements and available agents. In other words, shift scheduling balances the question of what shifts each employee should work on in order to meet workload requirements and achieve specific KPI targets, with compliance with various work planning constraints and state / national labor regulations (e.g., maximum shift duration, earliest shift start time, latest shift end time, etc.). Depending on constraints, agent preferences, and availability, the pool of feasible shifts can range from just a few possible combinations and permutations to billions of possible combinations and permutations.

[0073] As shown above, modern contact center agent scheduling solutions also take into account the fact that not all interactions can be handled by a single agent, and that each agent has a different skill set and qualifications. In addition, shift start times, shift lengths, breaks, and meals should typically vary to obtain a "good" shift that adequately covers workforce requirements. Often, based on the number of available agents and various (often competing) constraints, shifts will be overstaffed (i.e., exceeding requirements) in certain time intervals and understaffed in others. It should be understood that these nuances add complexity to the scheduling optimization problem.

[0074] The system performs optimization based on a list of agents, staffing requirement forecasts, and / or other relevant data to generate a shift schedule with the desired optimal (or near-optimal) output. It should be understood that the optimization problem can be represented as a matrix where each row corresponds to a constraint and each column corresponds to a decision variable. Standard optimization approaches, such as linear planning and discrete optimization, typically attempt to solve all decision variables at once, which introduces scalability problems. However, in illustrative embodiments, the system leverages column generation techniques to employ a “divide and conquer” approach to data analysis, breaking down the original problem into smaller, more easily solvable problems with fewer decision variables. For example, in some embodiments, the problem may be divided using Dantzig-Wolfe decomposition and / or other preferred decomposition techniques.

[0075] Therefore, in block 804, the system executes a column generation algorithm to determine the optimized shift schedule. It should be understood that column generation involves solving a restricted problem (i.e., a problem having a subset of all selectable potential solutions) and iteratively finding candidate columns to be added to the potential solutions in the restricted problem until some criteria are met. The restricted problem may be referred to herein as the master problem, and the problems solved to find the columns may be referred to herein as subproblems.

[0076] To utilize column generation for scheduling, the system must have both a limited version of the problem and a method for finding the column. In an illustrative embodiment, the column is defined as a set of shifts assigned to an agent (i.e., a "shift schedule"). The master problem ensures that the selected shift schedule satisfies the requirements of each planning group, and the sub-problem finds a shift schedule that satisfies the scheduling constraints. With this technical configuration, the system can use column generation to iteratively identify good candidate shift schedules to cover the requirements (e.g., without having to enumerate all possibilities).

[0077] In an illustrative embodiment, the system employs an approach to shift scheduling via column generation, starting by finding feasible columns for each agent, and columns (e.g., three) are added to a relaxed master problem as candidates. Specifically, the illustrative system solves the master problem, finds its dual, and the dual is then used in a subproblem to further identify new columns that can benefit the coverage of the requirements. The newly identified columns are added back to the master problem and solved. In some embodiments, this cycle may be repeated until one of a given termination criteria is met, as described below. Then, in such embodiments, all agents can be given exactly one of the sought shift schedules by solving the final integer master problem. Finally, the system may perform one or more post-processing steps to improve the quality and usefulness of the schedule. Table 1, presented below, lists various column generation models that may be used in conjunction with the column generation algorithms described herein.

[0078] [Table 1]

[0079] As shown in Figure 8, in an exemplary embodiment, the execution of the column generation algorithm includes the execution of subblocks 806, 808, 810, and 812. In block 806, the system performs initialization by solving an initial subproblem. More specifically, during initialization, the system solves, for example, an initial subproblem S for each agent. init-By solving the SP, at least one valid shift schedule can be found for each agent or group of agents. In some embodiments, to speed up the process, the system may "group" agents into groups of size N and calculate the reduced cost for each agent individually. If a valid shift schedule cannot be found for a particular agent, that agent is excluded. The valid shift schedules are passed to the relaxed master problem for column generation.

[0080] In block 808, the system performs column generation to add a new column. In particular, the system may find and add a new column by solving a relaxed master problem until one or more termination criteria are met. To do so, in some embodiments, the system may perform method 900 shown in Figure 9.

[0081] Referring here to Figure 9, the system may, when in use, perform method 900 for performing column generation. It should be understood that in some embodiments, the system may be embodied as a computing device (e.g., computing device 1300 in Figure 13) and / or a contact center system (e.g., contact center system 1200 in Figure 12) or a system / device thereof. It should be understood that certain blocks of method 900 are illustrated as examples, and such blocks may be combined, divided, added or removed, and / or rearranged in whole or in part, depending on the particular embodiment, unless otherwise stated.

[0082] The illustrative method 900 begins in block 902, where the system solves the relaxed master problem MP-LP to find combinations of shift schedules according to a given objective function. It should be understood that the pool of candidate shift schedule choices grows as more columns are discovered and added. This master problem can be said to be "relaxed" because it allows for the selection of partial shifts for each agent. Such "relaxation" makes the problem linear (and thus allows it to be solved faster) and enables the computation of a dual solution. In some embodiments, the system also has a lower bound.

[0083]

number

[0084] In block 904, the system finds a column (i.e., a good shift schedule). In particular, in an exemplary embodiment, the system solves the shift scheduling subproblem S-SP for each agent or group of agents. The shift scheduling subproblem S-SP finds a good shift schedule (i.e., a column) and reduces the cost.

[0085]

number

[0086]

number

[0087] In block 908, the system evaluates one or more termination criteria associated with the termination of the “column generation loop.” For example, in an exemplary embodiment, the system may evaluate one or more “optimal” criteria that guarantee that an optimal solution has been found, and “suboptimal” criteria that limit the execution time of the algorithm if it is not guaranteed that an optimal solution has been found within a given period (e.g., if it results in a potentially suboptimal solution).

[0088] In some embodiments, one such optimal criterion may include determining that there are no new columns to add from S-SP, which indicates that there are no more columns with negative reduced costs (e.g., all “improving” shifts have been identified and the master objective cannot be reduced any further). It should be understood that the reduced cost of a single agent does not generally increase monotonically between iterations. Therefore, to find the optimal solution, the system must generally perform subproblems for all agent groupings in each iteration. To speed up the algorithm, the system may discard agents that did not add columns, and after all the remainder have been discarded, the system can check again whether any other improving shifts were missed. In some embodiments, suboptimal criteria may include determining that the maximum number of iterations of the “column generation loop” in Figure 9 has been performed (e.g., 15 iterations), and determining that the lower bound is greater than the objective value of the relaxed master problem MP-LP (i.e.,

[0089]

number

[0090] If the system determines that one or more termination criteria (e.g., the optimal criterion and / or the suboptimal criterion) are met in block 910, method 900 terminates and returns to block 810 in Figure 8. However, if the system determines that the termination criteria are not met in block 910, method 900 returns to block 902, and the system attempts to add further columns. It should be understood that in some embodiments, termination of method 900 may require the satisfaction of multiple termination criteria. Furthermore, in other embodiments, one or more different termination criteria may be used by the system to terminate method 900.

[0091] It should be understood that the “column generation loop” in Figure 9 essentially involves finding a combination of shift schedules that optimize some objective (e.g., solved by linear planning) in order to find a dual solution to be used for the objective of a subproblem, and in the subproblem, finding effective shift schedules for agents that optimize an objective constructed from a dual of a relaxed master problem (e.g., solved by a constraint programmer) in order to find effective shift schedules for each agent or some agents.

[0092] Although blocks 902-910 are described in a relatively serial manner, it should be understood that various blocks of method 900 may be implemented in parallel in some embodiments.

[0093] Returning to Figure 8, in block 810, the system solves the integer master problem MP-IP. In an exemplary embodiment, the integer master problem MP-IP is similar to the relaxed master problem MP-LP, with the addition of an integer constraint that ensures exactly one shift schedule is selected per agent. In some embodiments, the integer master problem is solved only once, and the pool of shift schedule candidate choices includes all valid shift schedules found during column generation. In some embodiments, to balance producing good (or optimal) solution quality with having a reasonable solution time, the system may implement a set of termination rules of the form "terminate if the MIP gap is less than X% within Y seconds." It should be understood that the MIP gap is the tolerance or difference between the best solution found so far and the current solution. The closer it is to 0, the more optimal the quality of the solution. Such termination criteria are shown in Table 2 below.

[0094] [Table 2]

[0095] In block 812, the system may perform one or more post-processing steps, for example, to improve the quality and usefulness of the schedule. For example, in some embodiments, the system may fix agent shifts and perform a smaller CP formulation to minimize the accumulation of activities. This can be done to minimize the number of agents performing the same activity, such as having them eat or take breaks at the same time if possible. This is usually a desirable outcome for a contact center to ensure maximum service performance.

[0096] Furthermore, in some embodiments, the system can rebalance agent assignments to planning groups using a different, smaller LP formulation to ensure that each type of interaction receives similar service KPIs. For example, in cases of overstaffing, the system may distribute the excess agents evenly to handle all interaction types. Conversely, in cases of understaffing, the system may assign a limited number of agents to interaction types that require fewer agents, ensuring they are not ignored at the expense of those that require more agents. A small increase in adding agents to handle interaction types with small requirements is far greater than assigning agents to handle interaction types with large requirements. For example, adding one agent to a requirement of 10 agents may result in a 10% increase in service level, while assigning the same agent to a requirement of 100 agents may result in only a 1% increase in service level. In block 814, the system may output an optimized shift schedule. For example, in some embodiments, the system may return the resulting schedule for display. In some embodiments, the optimized shift schedule can be automatically incorporated into one or more aspects of the contact center system 1200.

[0097] Although blocks 802-814 are described in a relatively serial manner, it should be understood that various blocks of Method 800 may be implemented in parallel in some embodiments.

[0098] It should be understood that the system can utilize various constraints when generating an optimized shift schedule. For example, the tables in Figures 10 and 11 identify various exemplary shift constraints and their corresponding definitions for use in subproblems.

[0099] Furthermore, it should be understood that the formulations described herein may be extended with additional capabilities and may expose customization options for contact centers. For example, in some embodiments, the master problem formulation may aim to solve the following:

[0100]

number

[0101]

number

[0102]

number

[0103]

number

[0104]

number

[0105] In the master problem structure described above, the index is,

[0106]

number

[0107]

number

[0108]

number

[0109]

number

[0110]

number

[0111]

number

[0112]

number

[0113]

number

[0114]

number

[0115]

number

[0116]

number

[0117]

number

[0118]

number

[0119]

number

[0120] As explained above, a master problem lower bound can be used to terminate an algorithm. In particular, the lower bound is valid for each iteration i in a column generation algorithm, and the system is determined by the current lower bound.

[0121]

number

[0122]

number

[0123]

number

[0124] It should be understood that the master problem formulation, based on parameters of labor costs and penalties for failure to meet requirements, can minimize (or reduce) shift costs and staffing shortages. In other embodiments, objectives can be replaced by appropriate modifications to lower bounds. Therefore, it should be understood that this approach can support any number of custom objectives or multi-objective optimizations (e.g., minimizing shift costs while maximizing service levels and agent preferences). Multi-objective scheduling optimization allows the system to provide several equally "optimal" shift scheduling solutions, enabling end users to select according to the objectives that are more important to their contact center.

[0125] It should be understood that the master problem can still be difficult to solve due to the capabilities of the agents and the complexity of the plan group network. Therefore, in other embodiments, the aggregation and clustering of plan groups may be performed to reduce or decrease the dimensionality of the problem, thereby potentially dividing or decomposing the problem into independent subset networks of agents and plan groups (for example, for parallel scheduling using the column generation algorithm described above).

[0126] While the formulation described above is deterministic (for example, assuming all parameters are certain), it should be understood that other types of models may be used in other embodiments. For example, in some embodiments, a probabilistic version may be formulated to incorporate uncertainties in the contact center, such as workload forecast mismatch and agent compliance rates, in order to create what-if scenarios for best and worst-case macro and / or micro economic outlooks for the contact center over the planning period.

[0127] It should be understood that the subproblem formulations described herein can similarly address a variety of purposes, based on specific constraints and assumptions. In some embodiments, the relevant sets are:

[0128]

number

[0129]

number

[0130]

number

[0131]

number

[0132]

number

[0133]

number

[0134]

number

[0135] As shown above, the dual value is not available during initial setup. Therefore, for each agent, the system may find one or more initial shifts by finding the shift that best covers the requirements. For this purpose (S init The formula for SP can be as follows:

[0136]

number

[0137]

number

[0138]

number

[0139] In some embodiments, S init Both -SP and S-SP share the same set of constraints. Furthermore, as shown above, the tables in Figures 10 and 11 enumerate various constraints and their corresponding definitions. In some embodiments, the system assumes that all shift constraints are hard constraints (i.e., they must be satisfied) and that agent constraints do not change from the start to the end of the schedule (but they can rotate between different constraints). Naturally, it should be understood that the system may utilize different constraints and / or assumptions in different embodiments.

[0140] Referring here to Figure 12, a simplified block diagram of at least one embodiment of a communications infrastructure and / or content center system is shown, which may be used in conjunction with one or more embodiments of the embodiments described herein. The contact center system 1200 may be embodied as any system capable of providing contact center services (e.g., call center services, chat center services, SMS center services, etc.) to end users and performing functions otherwise described herein. An illustrative contact center system 1200 includes a customer device 1205, a network 1210, a switch / media gateway 1212, a call controller 1214, an interactive media response (IMR) server 1216, a routing server 1218, a storage device 1220, a statistics server 1226, agent devices 1230A, 1230B, 1230C, a media server 1234, a knowledge management server 1236, a knowledge system 1238, a chat server 1240, a web server 1242, an interaction (iXn) server 1244, a universal contact server 1246, a reporting server 1248, a media service server 1249, and an analytics module 1250.The illustrative embodiment in Figure 12 includes one customer device 1205, one network 1210, one switch / media gateway 1212, one call controller 1214, one IMR server 1216, one routing server 1218, one storage device 1220, one statistics server 1226, one media server 1234, one knowledge management server 1236, one knowledge system 1238, one chat server 1240, one iXn server 1244, one universal contact server 1246, one reporting server 1248, one media service server 1249, and one analytics module. Although only module 1250 is shown, in other embodiments the contact center system 1200 may include a plurality of customer devices 1205, a network 1210, a switch / media gateway 1212, a call controller 1214, an IMR server 1216, a routing server 1218, a storage device 1220, a statistics server 1226, a media server 1234, a knowledge management server 1236, a knowledge system 1238, a chat server 1240, an iXn server 1244, a universal contact server 1246, a reporting server 1248, a media service server 1249, and / or an analytics module 1250. Furthermore, in some embodiments, one or more of the components described herein may be excluded from system 1200, one or more of the components described as independent may form part of another component, and / or one or more of the components described as forming part of another component may be independent.

[0141] In this specification, the term “contact center system” is used to refer to the system and / or its components shown in Figure 12, while the term “contact center” is used more generally to refer to the contact center system, the customer service provider operating these systems, and / or the organization or company associated therewith. Therefore, unless otherwise specified, the term “contact center” generally refers to the contact center system (such as contact center system 1200), the associated customer service provider (such as a specific customer service provider providing customer services through contact center system 1200), and the organization or company on which customer services are provided.

[0142] As background, customer service providers can offer many types of services through contact centers. Such contact centers may be staffed with employees or customer service agents (or simply "agents"), who function as an interface between a company, corporation, government agency, or organization (hereinafter interchangeably referred to as "organization" or "corporation") and people such as users, individuals, or customers (hereinafter interchangeably referred to as "individuals" or "customers"). For example, a contact center agent may assist a customer in making a purchase decision, accepting an order, or resolving an issue with a product or service already received. Within a contact center, such interactions between a contact center agent and an external entity or customer may take place via various communication channels, such as voice (e.g., telephone calls or voice over IP, i.e., VoIP calls), video (e.g., video conferencing), text (e.g., email and text chat), screen sharing, co-browsing, and / or other communication channels.

[0143] In practice, contact centers generally strive to provide high-quality service to customers while minimizing costs. For example, one way a contact center operates is to handle all customer interactions with live agents. While this approach can be quite successful from a service quality standpoint, it is likely to be prohibitively expensive due to the high cost of agent labor. For this reason, most contact centers utilize some level of automated processes instead of live agents, such as interactive voice response (IVR) systems, interactive media response (IMR) systems, internet robots, i.e., "bots," automated chat modules, i.e., "chatbots," and / or other automated processes. Often, this has proven to be a successful strategy because automated processes can be very efficient at handling certain types of interactions and can be effective in reducing the need for live agents. Such automation allows contact centers to target customer interactions that are more difficult for human agents to use, while automated processes handle more repetitive or routine tasks. Furthermore, automated processes can be structured in a way that optimizes efficiency and promotes repeatability. Human agents, i.e., live agents, may forget to answer specific questions or thoroughly pursue certain details, but such errors are typically avoided through the use of automated processes. Customer service providers are increasingly relying on automated processes to interact with customers, while the use of such technologies by customers remains far less developed. Thus, on the contact center side of the interaction, IVR systems, IMR systems, and / or bots are used to automate parts of the interaction, while customer-side actions remain performed manually by the customer.

[0144] It should be understood that the contact center system 1200 can be used by customer service providers to provide various types of services to customers. For example, the contact center system 1200 can be used to participate in and manage interactions in which automated processes (or bots) or human agents communicate with customers. As should be understood, the contact center system 1200 may be an in-house facility of a business or company for carrying out sales and customer service functions related to products and services available through the company. In another embodiment, the contact center system 1200 may be operated by a third-party service provider contracted to provide services on behalf of another organization. Furthermore, the contact center system 1200 may be deployed on equipment dedicated to the company or third-party service provider and / or in a remote computing environment such as a private or public cloud environment with infrastructure to support multiple contact centers for multiple companies, for example. The contact center system 1200 may include software applications or programs that can be run on-site, remotely, or in any combination thereof. Furthermore, it should be understood that the various components of the contact center system 1200 may be distributed across various geographical locations and are not necessarily contained in a single location or computing environment.

[0145] Unless otherwise specifically limited, it should be further understood that any of the computing elements of the present invention may be implemented in a cloud-based or cloud computing environment. As used herein and further described below in relation to computing device 1300, “cloud computing” or simply “cloud” is defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services) that can be rapidly provisioned via virtualization, released with minimal administrative effort or service provider interaction, and then scaled as appropriate. Cloud computing can comprise a variety of characteristics (e.g., on-demand self-service, wide-area network access, resource pooling, rapid resilience, measurable service), service models (e.g., Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS)), and deployment models (e.g., private cloud, community cloud, public cloud). Cloud execution models, often referred to as "serverless architectures," generally include a service provider that dynamically manages the allocation and provisioning of remote servers to achieve desired functionality.

[0146] It should be understood that any of the computer implementation components, modules, or servers described in relation to Figure 12 may be implemented via one or more types of computing devices, such as the computing device 1300 in Figure 13. As can be seen, the contact center system 1200 generally manages resources (e.g., personnel, computers, telecommunications equipment, etc.) to enable the delivery of services via telephone, email, chat, or other communication mechanisms. Such services may vary depending on the type of contact center and may include, for example, customer service, help desk functions, emergency response, telemarketing, order taking, and / or other characteristics.

[0147] A customer wishing to receive services from the contact center system 1200 may initiate inbound communication (e.g., phone, email, chat, etc.) to the contact center system 1200 via a customer device 1205. Figure 12 shows one such customer device, i.e., customer device 1205, but it should be understood that any number of customer devices 1205 may exist. A customer device 1205 may be a communication device such as a telephone, smartphone, computer, tablet, or laptop. According to the functions described herein, a customer may generally use a customer device 1205 to initiate, manage, and perform communications with the contact center system 1200, such as phone calls, emails, chats, text messages, web browsing sessions, and other multimedia transactions.

[0148] Inbound and outbound communications to and from customer device 1205 may traverse network 1210, depending on the nature of the network, which typically depends on the type of customer device being used and the form of communication. For example, network 1210 may be a telephone, cellular, and / or data services communication network. Network 1210 may be a private or public switched telephone network (PSTN), a local area network (LAN), a private wide area network (WAN), and / or a public WAN such as the Internet. Furthermore, network 1210 may include a code division multiple access (CDMA) network, a global system for mobile communications (GSM) network, or any wireless network / technology conventional in the art, including but not limited to 3G, 4G, LTE, 5G, etc.

[0149] The switch / media gateway 1212 may be coupled to the network 1210 to receive and transmit telephone calls between the customer and the contact center system 1200. The switch / media gateway 1212 may be a telephone switch or communications switch configured to function as a central switch for agent-level routing within the center. The switch may be a hardware switching system or implemented via software. For example, the switch 1212 may be an automated call distributor, a private branch exchange (PBX), an IP-based software switch, and / or any other switch having dedicated hardware and software configured to receive internet-sourced and / or telephone network-sourced interactions from customers and route these interactions to, for example, one of the agent devices 1230. Thus, generally, the switch / media gateway 1212 establishes a voice connection between the customer and the agent by establishing a connection between the customer device 1205 and the agent device 1230.

[0150] As further shown, the switch / media gateway 1212 may be coupled to a call controller 1214 that functions as an adapter or interface between the switch and other routing, monitoring, and communication processing components of the contact center system 1200. The call controller 1214 may be configured to handle PSTN calls, VoIP calls, and / or other types of calls. For example, the call controller 1214 may include computer-telephone integration (CTI) software for interface connection with the switch / media gateway and other components. The call controller 1214 may include a SIP server for handling session initiation protocol (SIP) calls. The call controller 1214 may also extract data about incoming interactions, such as customer telephone numbers, IP addresses, or email addresses, and then communicate these with other contact center components when processing the interactions.

[0151] The two-way media response (IMR) server 1216 may be configured to enable self-help or virtual assistant functions. Specifically, the IMR server 1216 may be similar to an interactive voice response (IVR) server, except that the IMR server 1216 is not limited to voice and may cover a variety of media channels. In the example illustrating voice, the IMR server 1216 may consist of IMR scripts for querying customers about their needs. For example, a bank contact center may instruct customers via an IMR script to "press 1" if they want to look up their account balance. Through continuous interaction with the IMR server 1216, customers can receive services without having to speak to an agent. The IMR server 1216 may also be configured to determine why a customer is contacting the contact center so that communications can be routed to the appropriate resources. IMR configuration may be implemented through the use of self-service and / or assisted service tools, including web-based tools for developing IVR and routing applications that run within a contact center environment (e.g., Genesys® Designer).

[0152] The routing server 1218 may function to route incoming interactions. For example, if it is determined that an inbound communication should be handled by a human agent, the functions within the routing server 1218 may select the most appropriate agent and route the communication to that agent. This agent selection may be based on which available agent is best suited to handle the communication. More specifically, the selection of the appropriate agent may be based on a routing strategy or algorithm implemented by the routing server 1218. In doing so, the routing server 1218 may query data related to the incoming interaction, such as data related to a specific customer, available agents, and the type of interaction, which may be stored in a specific database as described herein. Once an agent is selected, the routing server 1218 may interact with the call controller 1214 to route (i.e., connect) the incoming interaction to the corresponding agent device 1230. As part of this connection, information about the customer may be provided to the selected agent via that agent device 1230. This information is intended to enhance the services that agents can provide to clients.

[0153] It should be understood that the contact center system 1200 may include one or more mass storage devices (generally represented by storage device 1220) for storing data in one or more databases related to the functions of the contact center. For example, storage device 1220 may store customer data maintained in a customer database. Such customer data may include, for example, customer profiles, contact information, service level agreements (SLAs), and interaction history (e.g., details of previous interactions with a particular customer, including the nature of the previous interaction, disposal data, wait times, processing times, and actions taken by the contact center to resolve the customer's issue). As another example, storage device 1220 may store agent data in an agent database. Agent data maintained by the contact center system 1200 may include, for example, agent availability and agent profiles, schedules, skills, processing times, and / or other relevant data. As yet another example, storage device 1220 may store interaction data in an interaction database. Interaction data may include, for example, data relating to numerous past interactions between a customer and a contact center. More generally, unless otherwise specified, the storage device 1220 may include a database and / or be configured to store data relating to any of the types of information described herein, and it should be understood that these databases and / or data are accessible to other modules or servers of the contact center system 1200 in a manner that facilitates the functions described herein. For example, a server or module of the contact center system 1200 may query such a database to retrieve data stored in the database or to transmit data to the database for storage. The storage device 1220 may take the form of any conventional storage medium, for example, and may be housed locally or operated from a remote location.For example, a database can be a Cassandra database, a NoSQL database, or an SQL database, and may be managed by a database management system such as Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, or PostgreSQL.

[0154] The statistics server 1226 may be configured to record and aggregate data relating to the performance and operating characteristics of the contact center system 1200. Such information may be compiled by the statistics server 1226 and made available to other servers and modules, such as the reporting server 1248, which may then use the data to generate reports used to manage the operating characteristics of the contact center and to perform automated actions according to the functions described herein. Such data may relate to the status of the contact center's resources, such as average wait time, discard rate, agent occupancy rate, and other information that the functions described herein may require.

[0155] The agent device 1230 of the contact center system 1200 may be a communication device configured to interact with various components and modules of the contact center system 1200 in a manner that facilitates the functions described herein. For example, the agent device 1230 may include a telephone adapted for regular telephone calls or VoIP calls. The agent device 1230 may further include a computing device configured to communicate with the server of the contact center system 1200, perform data processing associated with its operation, and interface with customers via voice, chat, email, and other multimedia communication mechanisms according to the functions described herein. Figure 12 shows three such agent devices 1230, namely agent devices 1230A, 1230B, and 1230C, but it should be understood that in a particular embodiment, any number of agent devices 1230 may exist.

[0156] The multimedia / social media server 1234 may be configured to facilitate (non-voice) media interactions with customer devices 1205 and / or server 1242. Such media interactions may relate to, for example, email, voicemail, chat, video, text messaging, the web, social media, co-browsing, etc. The multimedia / social media server 1234 may take the form of any IP router conventional in the art, having dedicated hardware and software for receiving, processing, and forwarding multimedia events and communications.

[0157] The knowledge management server 1236 may be configured to facilitate interaction between the customer and the knowledge system 1238. Generally, the knowledge system 1238 may be a computer system capable of receiving questions, i.e., queries, and providing answers accordingly. The knowledge system 1238 may be included as part of the contact center system 1200 or operated remotely by a third party. The knowledge system 1238 may include an artificial intelligence computer system capable of answering questions presented in natural language by retrieving information from sources such as encyclopedias, dictionaries, newswire articles, literary works, or other documents submitted to the knowledge system 1238 as reference material. As an example, the knowledge system 1238 may be embodied as IBM Watson or a similar system.

[0158] The chat server 1240 may be configured to conduct, orchestrate, and manage electronic chat communications with customers. Generally, the chat server 1240 is configured to implement and maintain chat conversations and generate chat transcripts. Such chat communications may be conducted by the chat server 1240 in a manner in which the customer communicates with an automated chatbot, a human agent, or both. In an exemplary embodiment, the chat server 1240 may function as a chat orchestration server that dispatches chat conversations between chatbots and available human agents. In such a case, the processing logic of the chat server 1240 may be rules that are thus driven to leverage intelligent workload distribution among available chat resources. The chat server 1240 may further implement, manage, and streamline user interfaces (UIs) associated with the chat functionality, including user interfaces generated on either the customer device 1205 or the agent device 1230. The chat server 1240 may be configured to transfer chat between automated and human sources within a single chat session with a particular customer, for example, so that the chat session moves from a chatbot to a human agent or from a human agent to a chatbot. The chat server 1240 may also be coupled with the knowledge management server 1236 and the knowledge system 1238 to receive suggestions and answers to queries presented by the customer during the chat, for example so that links to relevant articles may be provided.

[0159] The web server 1242 may be included to provide site hosting for various social interaction sites that customers subscribe to, such as Facebook, Twitter, and Instagram. Although shown as part of the contact center system 1200, it should be understood that the web server 1242 may be provided by a third party and / or maintained remotely. The web server 1242 may also provide web pages of companies or organizations supported by the contact center system 1200. For example, a customer may browse a web page to receive information about a particular company's products and services. Within such a company's web page, a mechanism may be provided for initiating interaction with the contact center system 1200, for example, via web chat, voice, or email. An example of such a mechanism is a widget that may be deployed on a web page or website hosted on the web server 1242. As used herein, a widget refers to a user interface component that performs a particular function. In some implementation embodiments, a widget may include a graphical user interface control that can be overlaid on a web page displayed to the customer over the internet. A widget may include buttons or other controls that allow a customer to access specific functions, such as displaying information in a window or text box, sharing or opening a file, or initiating communication. In some implementations, a widget includes a user interface component having a portable portion of code that can be installed and executed within a separate web page without compilation. Some widgets may include corresponding or additional user interfaces and may be configured to access various local resources (e.g., calendar or contact information on the customer's device) or remote resources over a network (e.g., instant messaging, email, or social networking updates).

[0160] The interaction (iXn) server 1244 may be configured to manage deferred activities in a contact center and the routing of those activities to human agents for completion. As used herein, deferred activities include back-office work that can be performed offline, such as responding to emails, attending training, and other activities that do not require real-time communication with customers. For example, the interaction (iXn) server 1244 may be configured to interact with the routing server 1218 to select an agent suitable for handling each of the deferred activities. Once assigned to a specific agent, the deferred activity is pushed to that agent, and as a result, the deferred activity appears on the agent device 1230 of the selected agent. The deferred activity may appear in a workbin as a task for the selected agent to complete. The functionality of the workbin may be implemented via any conventional data structure, such as linked lists, arrays, and / or other preferred data structures. Each of the agent devices 1230 may contain a workbin. For example, the workbin may be maintained in the buffer memory of the corresponding agent device 1230.

[0161] The universal contact server (UCS) 1246 may be configured to retrieve information stored in the customer database and / or transmit information to the customer database for storage. For example, UCS 1246 may be used as part of a chat function to facilitate maintaining a history of how chats with a particular customer were handled, and this history may then be used as a reference for how future chat communications should be handled. More generally, UCS 1246 may be configured to facilitate maintaining a history of customer preferences, such as preferred media channels and the best time to contact. To do this, UCS 1246 may be configured to identify data related to each customer's interaction history, such as data on comments from agents, customer communication history, etc. Each of these data types may then be stored in the customer database 222 or other modules and retrieved when required by the functions described herein.

[0162] The reporting server 1248 may be configured to generate reports from data compiled and aggregated by the statistics server 1226 or other sources. Such reports may include quasi-real-time or historical reports and may relate to the state of contact center resources and performance characteristics, such as average latency, discard rate, and / or agent occupancy. Reports may be generated automatically or in response to specific requests from requesters (e.g., agents, administrators, contact center applications). The reports may then be used to manage the operation of the contact center in accordance with the functions described herein.

[0163] The media service server 1249 may be configured to provide audio and / or video services to support contact center functions. According to the functions described herein, such functions may include prompting for IVR or IMR systems (e.g., playing audio files), hold music, voicemail / single-party recording, multi-party recording (e.g., audio and / or video calls), speech recognition, dual-tone multi-frequency (DTMF) recognition, fax, audio and video transcoding, secure real-time transport protocol (SRTP), teleconferencing, video conferencing, coaching (e.g., support for coaches to eavesdrop on interactions between customers and agents, and for coaches to provide comments to agents without customers hearing the comments), call analysis, keyword spotting, and / or other related functions.

[0164] The analysis module 1250 may be configured to provide a system and method for performing analysis on data received from multiple different data sources, where the functionality described herein may be required. According to exemplary embodiments, the analysis module 1250 may also generate, update, train, and modify predictors or models based on collected data, such as customer data, agent data, and interaction data. The models may include customer or agent behavior models. Behavioral models may be used to predict customer or agent behavior in various situations, for example, thereby enabling embodiments of the invention to adjust interactions based on such predictions or allocate resources in preparation for predicted characteristics of future interactions, thereby improving overall contact center performance and customer experience. Although the analysis module is described as part of a contact center, it will be understood that such behavioral models may also be implemented in customer systems (or the “customer side” of interactions, as used herein) and used for the benefit of the customer.

[0165] According to an exemplary embodiment, the analytics module 1250 may have access to data stored in the storage device 1220, including a customer database and an agent database. The analytics module 1250 may also have access to an interaction database that stores data related to interactions and interaction content (e.g., transcripts of interactions and events detected therein), interaction metadata (e.g., customer identifier, agent identifier, medium of interaction, length of interaction, start and end times of interaction, department, tagged category), and application settings (e.g., interaction paths through the contact center). Furthermore, the analytics module 1250 may be configured to retrieve data stored in the storage device 1220 for use when developing and training algorithms and models, for example, by applying machine learning techniques.

[0166] One or more of the included models may be configured to predict customer or agent behavior and / or aspects related to the operation and performance of a contact center. Furthermore, one or more of the models may be used for natural language processing, including, for example, intent recognition. Models may be developed based on known first-principles equations describing a system, data yielding an experimental model, or a combination of known first-principles equations and data. When developing models for use in this embodiment, first-principles equations are often unavailable or not easily derived, so it may generally be preferable to build empirical models based on collected and stored data. In some embodiments, it may be preferable for the models to be nonlinear in order to adequately capture the relationship between the instrumental / disturbance variables and the control variables of a complex system. This is because nonlinear models may show a curvilinear relationship, rather than a linear relationship, between the instrumental / disturbance variables and the control variables, which is common in complex systems such as those considered herein. Given the requirements described above, machine learning or neural network-based approaches may be preferred embodiments for implementing the models. For example, a neural network may be developed based on empirical data using advanced regression algorithms.

[0167] The analysis module 1250 may further include an optimizer. As can be understood, the optimizer may be used to minimize a “cost function” to which a set of constraints is applied, where the cost function is a mathematical representation of the desired objective or system behavior. Since the model can be nonlinear, the optimizer may be a nonlinear programming optimizer. However, the techniques described herein are intended to be implemented by using various different types of optimization approaches, including but not limited to linear programming, quadratic programming, mixed-integer nonlinear programming, stochastic programming, global nonlinear programming, genetic algorithms, particle / swarm techniques, etc., individually or in combination.

[0168] According to some embodiments, the model and optimizer may be used together within an optimization system. For example, the analysis module 1250 may utilize the optimization system as part of an optimization process in which the performance and behavior of the contact center are optimized, or at least enhanced. This may include features related to customer experience, agent experience, interaction routing, natural language processing, intent recognition, or other functions related to automated processes, for example.

[0169] The various components, modules, and / or servers in Figure 12 (and other figures included herein) may each include one or more processors that execute computer program instructions and interact with other system components to perform various functions described herein. Such computer program instructions may be stored in memory implemented using standard memory devices such as random-access memory (RAM), or on other non-temporary computer-readable media such as CD-ROMs or flash drives. While each function of a server is described as being provided by a particular server, those skilled in the art should understand that the functions of various servers may be combined or integrated into a single server, or that the functions of a particular server may be distributed across one or more other servers without departing from the scope of the invention. Furthermore, the terms “interaction” and “communication” are used interchangeably and generally refer to any real-time and non-real-time interaction using any communication channel, including but not limited to telephone calls (PSTN or VoIP calls), email, V-mail, video, chat, screen sharing, text messages, social media messages, WebRTC calls, etc. Access to the components of the contact center system 1200 and control of the components of the control center system 1200 may be affected through a user interface (UI) that may be generated on the customer device 1205 and / or agent device 1230. As already mentioned, the contact center system 1200 may be operated as a hybrid system in which some or all of its components are remotely hosted in a cloud-based environment or a cloud computing environment. It should be understood that each device of the contact center system 1200 may be embodied, include, or form part of one or more computing devices similar to the computing device 1300 described below with reference to Figure 13.

[0170] Referring here to Figure 13, a simplified block diagram of at least one embodiment of computing device 1300 is shown. The illustrative computing device 1300 represents at least one embodiment of each of the computing devices, systems, servicers, controllers, switches, gateways, engines, modules, and / or computing components described herein (for example, for the sake of brevity herein, they may interchangeably be referred to as computing devices, servers, or modules). For example, various computing devices may be processes or threads running on one or more processors of one or more computing devices 1300 that are capable of executing computer program instructions and interacting with other system modules in order to perform various functions described herein. Unless particularly limited, functions described in relation to multiple computing devices may be integrated into a single computing device, or various functions described in relation to a single computing device may be distributed across several computing devices. Furthermore, in relation to the computing systems described herein, such as the contact center system 1200 in Figure 12, the various servers and computer devices of the system may be located on local computing devices 1300 (e.g., on-site at the same physical location as the contact center agents), remote computing devices 1300 (e.g., off-site, i.e., in a cloud-based environment, or in a cloud computing environment, e.g., in a remote data center connected via a network), or any combination thereof.In some embodiments, functions provided by a server located on an off-site computing device may be accessed and provided via a virtual private network (VPN) as if such a server were on-site, or functions may be provided using Software as a Service (SaaS) accessed over the Internet using various protocols, for example, by exchanging data via an extensible markup language (XML), JSON, and / or functions may be accessed / utilized in other ways.

[0171] In some embodiments, the computing device 1300 may be embodied as a server, desktop computer, laptop computer, tablet computer, notebook, netbook, Ultrabook®, mobile phone, mobile computing device, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, processing system, wireless access point, router, gateway, and / or any other computing device, processing device, and / or communication device capable of performing the functions described herein.

[0172] The computing device 1300 includes a processing device 1302 that executes algorithms and / or processes data according to operational logic 1308, an input / output device 1304 that enables communication between the computing device 1300 and one or more external devices 1310, and a memory 1306 that stores data received from the external devices 1310, for example, via the input / output device 1304.

[0173] The input / output device 1304 enables the computing device 1300 to communicate with the external device 1310. For example, the input / output device 1304 may include a transceiver, a network adapter, a network card, an interface, one or more communication ports (e.g., a USB port, a serial port, a parallel port, an analog port, a digital port, VGA, DVI, HDMI, FireWire, CAT5, or any other type of communication port or interface), and / or other communication circuits. Depending on the specific computing device 1300, the communication circuits of the computing device 1300 may be configured to perform such communication using any one or more communication technologies (e.g., wireless or wired communication) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, etc.). The input / output device 1304 may include hardware, software, and / or firmware suitable for performing the technologies described herein.

[0174] The external device 1310 may be any type of device that enables data to be input to or output from the computing device 1300. For example, in various embodiments, the external device 1310 may be embodied as one or more of the devices / systems and / or parts thereof described herein. Furthermore, in some embodiments, the external device 1310 may be embodied as another computing device, switch, diagnostic tool, controller, printer, display, alarm, peripheral device (e.g., keyboard, mouse, touchscreen display, etc.), and / or any other computing, processing, and / or communication device capable of performing the functions described herein. Furthermore, it should be understood that in some embodiments, the external device 1310 may be integrated with the computing device 1300.

[0175] The processing device 1302 can be embodied as any type of processor capable of performing the functions described herein. In particular, the processing device 1302 can be embodied as one or more single-core or multi-core processors, microcontrollers, or other processors or processing / control circuits. For example, in some embodiments, the processing device 1302 may include, or be embodied as, an arithmetic logic unit (ALU), a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or another suitable processor. The processing device 1302 may be of a programmable type, a dedicated hardwired state machine, or a combination thereof. The processing device 1302 having multiple processing units may, in various embodiments, utilize distributed processing, pipelined processing, and / or parallel processing. Furthermore, the processing device 1302 may be dedicated solely to performing the operations described herein, or it may be used in one or more additional applications. In an exemplary embodiment, the processing device 1302 is programmable and executes algorithms and / or processes data according to operational logic 1308 defined by programming instructions (such as software or firmware) stored in memory 1306. Additionally or alternatively, the operational logic 1308 of the processing device 1302 may be defined at least in part by hardwired logic or other hardware. Furthermore, the processing device 1302 may include one or more components of any type suitable for processing signals received from the input / output device 1304 or from other components or devices and providing a desired output signal.Such components may include digital circuits, analog circuits, or combinations thereof.

[0176] Memory 1306 may be one or more types of non-temporary computer-readable media, such as solid-state memory, electromagnetic memory, optical memory, or a combination thereof. Furthermore, memory 1306 may be volatile and / or non-volatile, and in some embodiments, part or all of memory 1306 may be portable, such as disks, tapes, memory sticks, cartridges, and / or other suitable portable memory. During operation, memory 1306 may store various data and software used during the operation of computing device 1300, such as operating systems, applications, programs, libraries, and drivers. It should be understood that memory 1306 may store data manipulated by the operational logic 1308 of processing device 1302, for example, programming instructions that define the operational logic 1308, as well as, or instead of, data representing signals received from and / or transmitted to input / output devices 1304. As shown in Figure 13, memory 1306 may be included in and / or coupled to processing device 1302, depending on the particular embodiment. For example, in some embodiments, the processing device 1302, the memory 1306, and / or other components of the computing device 1300 may form part of a system-on-a-chip (SoC) and be incorporated into a single integrated circuit chip.

[0177] In some embodiments, various components of the computing device 1300 (e.g., the processing device 1302 and the memory 1306) may be communicatively coupled via an input / output subsystem that can be embodied as circuits and / or components to facilitate input / output operations with the processing device 1302, the memory 1306, and other components of the computing device 1300. For example, the input / output subsystem may be embodied as, or include, a memory controller hub, an input / output control hub, a firmware device, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and / or other components and subsystems to facilitate input / output operations.

[0178] The computing device 1300 may, in other embodiments, include other or additional components, such as those commonly found in a typical computing device (e.g., various input / output devices and / or other components). It should be further understood that one or more components of the computing device 1300 described herein may be distributed across multiple computing devices. In other words, the techniques described herein may be employed by a computing system comprising one or more computing devices. Furthermore, although only a single processing device 1302, I / O device 1304, and memory 1306 are shown illustratively in Figure 13, it should be understood that in other embodiments, a particular computing device 1300 may include multiple processing devices 1302, I / O devices 1304, and / or memory 1306. Furthermore, in some embodiments, two or more external devices 1310 may communicate with the computing device 1300.

[0179] The computing device 1300 may be one of several devices connected by a network or connected to other systems / resources via a network. The network may be embodied as any one or more types of communication networks that can facilitate communication between various devices connected commutably via the network. Thus, the network may include one or more networks, routers, switches, access points, hubs, computers, client devices, endpoints, and / or other intervening network devices. For example, the network may be embodied as one or more cellular networks, telephone networks, local or wide area networks, publicly available global networks (e.g., the Internet), ad hoc networks, short-range communication links, or a combination thereof, or otherwise include them. In some embodiments, the network may include circuit-switched voice or data networks, packet-switched voice or data networks, and / or any other networks capable of carrying voice and / or data. In particular, in some embodiments, the network may include Internet Protocol (IP) based networks and / or asynchronous transfer mode (ATM) based networks. In some embodiments, the network may handle voice traffic (e.g., via a Voice over IP (VOIP) network), web traffic, and / or other network traffic, depending on the particular embodiment and / or the devices of the systems communicating with each other.In various embodiments, the network may include analog or digital wired and wireless networks (e.g., IEEE 802.11 networks, public switched telephone networks (PSTN), Integrated Services Digital Network (ISDN), and Digital Subscriber Line (xDSL)), third-generation (3G) mobile networks, fourth-generation (4G) mobile networks, fifth-generation (5G) mobile networks, wired Ethernet networks, private networks (e.g., intranets), radio, television, cable, satellite, and / or any other distribution or tunneling mechanism for carrying data, or any suitable combination of such networks. It should be understood that various devices / systems may communicate with each other via different networks depending on the source and / or destination devices / systems.

[0180] It should be understood that computing device 1300 may communicate with other computing devices 1300 via any type of gateway or tunneling protocol, such as secure socket layer or transport layer security. Network interfaces may include built-in network adapters, such as network interface cards, suitable for interfaceping the computing device to any type of network capable of performing the operations described herein. Furthermore, the network environment may be a virtual network environment in which various network components are virtualized. For example, various machines may be virtual machines implemented as software-based computers running on physical machines. Virtual machines may share the same operating system, or, in other embodiments, different operating systems may run on each virtual machine instance. For example, a "hypervisor" type of virtualization is used in which multiple virtual machines run on the same host physical machine, each functioning as if it had its own dedicated box. Other types of virtualization may be employed in other embodiments, for example, in networks (e.g., via software-defined networking) or functions (e.g., via network function virtualization).

[0181] Accordingly, one or more of the computing devices 1300 described herein may be embodied as one or more cloud-based systems or form part thereof. In a cloud-based embodiment, the cloud-based system may be embodied as, for example, a server-ambiguous computing solution that executes multiple instructions on demand, executes instructions only when prompted by a specific activity / trigger, and does not consume computing resources when not in use. That is, the system may be embodied as a virtual computing environment that resides "on top of" a computing system (e.g., a distributed network of devices) on which various virtual functions (e.g., lambda functions, Azure functions, Google Cloud functions, and / or other suitable virtual functions) can be executed in accordance with the functionality of the system described herein. For example, when an event occurs (e.g., data is transferred to the system for processing), the virtual computing environment may be communicated (e.g., via requests to the virtual computing environment's API), thereby allowing the API to route requests to the correct virtual function (e.g., a specific server-ambiguous computing resource) based on a set of rules. Therefore, if a request for data transmission is made by a user (for example, through a suitable user interface to the system), a suitable virtual function may be executed to perform the action before deleting the instance of the virtual function.

Claims

1. A system for performing agent scheduling for a contact center, wherein the system is At least one processor, It has at least one memory containing multiple stored instructions, In response to the execution of the aforementioned instruction, the processor: Based on contact processing data that includes at least information on the volume and processing time of contacts previously processed by the contact center, a workload forecast is generated that includes the volume and processing time of contacts expected to occur at the contact center during a predetermined future planning period. Based on the workload forecast, a personnel allocation requirement forecast is generated that indicates the number of agents required per unit time at a given time granularity for the predetermined planning period. The process involves generating a contact center agent shift schedule for multiple agents that satisfies the personnel allocation requirement forecast from among multiple shift schedule candidates that satisfy at least one of the constraints for each of the multiple agents: the maximum shift duration, the earliest shift start time, or the latest shift end time. The contact center agent shift schedule for the aforementioned plurality of agents is generated by a column generation algorithm that includes solving a problem having a subset of selectable potential solutions consisting of given shift schedule candidates, and iteratively finding new shift schedule candidates to be added to the potential solutions until predetermined criteria are met. The aforementioned workload prediction is performed based on a given prediction model. The given prediction model is Based on the aforementioned contact processing data, extract time-series data showing the trend in the volume of contacts processed by the contact center for each of the multiple time granularities that constitute a hierarchy with different lengths, and A system generated by applying cross-validation to the corresponding time series data for each of the aforementioned multiple time granularities, comparing the accuracy of multiple pre-prepared prediction methods, and thereby identifying the prediction method with the highest accuracy.

2. The system according to claim 1, wherein generating contact center agent shift schedules for the plurality of agents by executing the column generation algorithm includes adding candidates until at least one termination criterion is met.

3. The system according to claim 2, wherein the at least one termination criterion includes the criterion that there are no new candidates available for addition, or the criterion that the number of candidate generation cycles has reached a predetermined threshold.

4. One or more non-temporary machine-readable storage media containing a plurality of stored instructions, wherein the instructions, in response to execution by at least one processor, communicate to the system that, in response to the execution of the instructions, the processor... Based on contact processing data that includes at least information on the volume and processing time of contacts handled by the contact center in the past, a workload forecast is generated that includes the volume and processing time of contacts expected to occur at the contact center during a predetermined future planning period. Based on the workload forecast, generate a staffing requirement forecast indicating the number of agents required per unit time at a given time granularity for the predetermined planning period. The process involves generating a contact center agent shift schedule for multiple agents that satisfies the personnel allocation requirement forecast from among multiple shift schedule candidates that satisfy at least one of the constraints for each of the multiple agents: the maximum shift duration, the earliest shift start time, or the latest shift end time. The contact center agent shift schedule for the aforementioned plurality of agents is generated by a column generation algorithm that includes solving a problem having a subset of selectable potential solutions consisting of given shift schedule candidates, and iteratively finding new shift schedule candidates to be added to the potential solutions until predetermined criteria are met. The aforementioned workload prediction is performed based on a given prediction model. The given prediction model is Based on the aforementioned contact processing data, extract time-series data showing the trend in the volume of contacts processed by the contact center for each of the multiple time granularities that constitute a hierarchy with different lengths, and One or more non-temporary machine-readable storage media are generated by applying cross-validation to the corresponding time-series data for each of the aforementioned multiple time granularities, comparing the accuracy of a pre-prepared set of prediction methods, and thereby identifying a prediction method with high accuracy.

5. One or more non-temporary machine-readable storage media according to claim 4, wherein generating contact center agent shift schedules for the plurality of agents by executing the column generation algorithm comprises adding candidates until at least one termination criterion is met.

6. The one or more non-temporary machine-readable storage media according to claim 5, wherein the at least one termination criterion includes the criterion that there are no new candidates available for addition, or the criterion that the number of candidate generation counts has reached a predetermined threshold.

7. A method for performing contact center agent scheduling by a contact center system including a processor, wherein the processor Based on contact processing data that includes at least information on the volume and processing time of contacts previously processed by the contact center, a workload forecast is generated that includes the volume and processing time of contacts expected to occur at the contact center during a predetermined future planning period. Based on the workload forecast, a personnel allocation requirement forecast is generated that indicates the number of agents required per unit time at a given time granularity for the predetermined planning period. The process involves generating a contact center agent shift schedule for multiple agents that satisfies the personnel allocation requirement forecast from among multiple shift schedule candidates that satisfy at least one of the constraints for each of the multiple agents: the maximum shift duration, the earliest shift start time, or the latest shift end time. The contact center agent shift schedule for the aforementioned plurality of agents is generated by a column generation algorithm that includes solving a problem having a subset of selectable potential solutions consisting of given shift schedule candidates, and iteratively finding new shift schedule candidates to be added to the potential solutions until predetermined criteria are met. The aforementioned workload prediction is performed based on a given prediction model. The given prediction model is Based on the aforementioned contact processing data, extract time-series data showing the trend in the volume of contacts processed by the contact center for each of the multiple time granularities that constitute a hierarchy with different lengths, and A method generated by applying cross-validation to the corresponding time series data for each of the aforementioned multiple time granularities, comparing the accuracy of several pre-prepared prediction methods, and thereby identifying the prediction method with the highest accuracy.

8. The method according to claim 7, wherein generating contact center agent shift schedules for the plurality of agents by executing the column generation algorithm includes adding candidates until at least one termination criterion is met.