Implementing Back-Office Work Item Forecasting Models for Non-Real-Time Task Queues

How-To-Articles
1

Implementing Back-Office Work Item Forecasting Models for Non-Real-Time Task Queues

What This Guide Covers

This guide details the architectural and mathematical implementation of forecasting models for asynchronous, non-real-time back-office work items in Genesys Cloud CX. You will configure historical data extraction, apply time-series decomposition to isolate trend and seasonality, and deploy these predictions into Workforce Management (WFM) to drive accurate staffing for tasks such as claims processing, email support, and case resolution. The end result is a WFM model that treats non-real-time work with the same statistical rigor as voice traffic, eliminating the common pitfall of flat-line staffing and ensuring optimal agent utilization during peak processing windows.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX WFM License (Enterprise or Ultimate tier). The standard WFM license includes the forecasting engine, but advanced custom model tuning requires access to the WFM API.
  • Roles:
    • WFM Administrator: Full access to Workforce Management > Forecasting.
    • WFM Analyst: Access to edit forecast templates and view historical data.
    • Admin: Required to configure external data sources if integrating CRM volume data via API.
  • API Permissions:
    • wfm:forecast:read and wfm:forecast:write for programmatic model adjustment.
    • analytics:report:read for extracting raw historical volume data for validation.
  • Data Requirements:
    • Minimum of 12 months of historical interaction data for the specific Work Item types.
    • Cleaned data where “Handled” status is accurately reflected in the Interaction History.
    • Defined Work Item types (e.g., Claim_Adjustment, Billing_Inquiry) mapped to specific Queues or Groups in the WFM model.

The Implementation Deep-Dive

1. Architectural Foundation: Defining the Work Item Model

Voice forecasting relies on Erlang C, which assumes immediate service and Poisson distribution. Back-office work items violate both assumptions. Agents do not process cases in real-time; they pull from a queue, and the duration varies significantly. Therefore, the forecasting model must shift from Arrival Rate to Volume and Average Handling Time (AHT).

The first step is to ensure your WFM model distinguishes between Real-Time (Voice/Chat/SMS) and Non-Real-Time (Email/Case) channels. In Genesys Cloud WFM, this is handled by creating separate Forecast Templates for each channel type.

Configuration Steps:

  1. Navigate to Workforce Management > Forecasting > Templates.
  2. Create a new template named BackOffice_Email_Claims.
  3. Set the Channel Type to Email or Task.
  4. Under Model Type, select Volume rather than Interval. Voice models often use 15-minute intervals; back-office models should use Hourly or Daily granularity depending on shift length. For most back-office roles, Daily is sufficient if the work is distributed evenly, but Hourly is required if there are distinct “drop-off” times (e.g., end-of-day processing bursts).

The Trap: Using Voice Intervals for Back-Office
The most common architectural failure is applying a 15-minute interval model to email queues. This creates noise because email arrivals are not uniformly distributed in 15-minute blocks in the same way voice calls are. A 15-minute interval model for back-office work forces the algorithm to chase micro-trends that do not exist, leading to overfitting. The result is a jagged forecast that causes WFM to recommend excessive staffing for short, insignificant spikes. Always validate that your interval length matches the operational reality of the work. If agents check email every 30 minutes, a 15-minute forecast is statistically meaningless.

Architectural Reasoning:
By decoupling the channel types, you allow the WFM engine to apply different smoothing algorithms. Voice traffic requires aggressive smoothing to handle call center variability. Back-office traffic requires trend analysis to handle seasonal business cycles (e.g., tax season, holiday returns).

2. Data Ingestion and Historical Cleaning

The accuracy of the forecast is strictly bounded by the quality of the historical data. Genesys Cloud WFM pulls historical data from the Interaction History. However, raw data is rarely clean.

Configuration Steps:

  1. Navigate to Workforce Management > Forecasting > Historical Data.
  2. Review the Data Sources for the BackOffice_Email_Claims template.
  3. Ensure that the Work Item Type filter is strictly applied. If you are forecasting “Claims,” do not include “General Inquiries” in the same data source unless they are handled by the same skill group with similar AHT.
  4. Check for Outliers. Select a 12-month view and look for spikes that do not align with known business events.

The Trap: Including “Self-Service” Deflections in Historical Volume
Many organizations route automated resolutions or chatbot deflections into the same queue as human-handled cases for reporting purposes. If these deflected interactions are included in the historical volume data, the forecast will overpredict the required human staffing. The WFM engine sees the volume as “work to be done” and calculates AHT based on the total time, including the time the bot handled it. This dilutes the AHT metric, causing the system to underestimate the number of agents needed for the actual human-handled portion.

Solution:
Use Interaction Attributes to filter out non-human interactions. In the Historical Data configuration, add a filter for Interaction Type = Human or exclude specific Work Item Statuses that indicate automated resolution (e.g., Resolved by Bot).

Architectural Reasoning:
WFM forecasting is a regression problem. Garbage in, garbage out. If the historical data contains noise from non-human interactions, the regression line will shift downward, underestimating the true human effort required. By filtering at the ingestion stage, you ensure the model learns only from human-operational patterns.

3. Configuring the Forecasting Algorithm: ARIMA vs. Holt-Winters

Genesys Cloud WFM uses a proprietary engine that combines elements of ARIMA (AutoRegressive Integrated Moving Average) and Holt-Winters exponential smoothing. For back-office work, the choice of decomposition method is critical.

Configuration Steps:

  1. Open the BackOffice_Email_Claims template.
  2. Navigate to the Algorithm settings.
  3. Select Holt-Winters with Additive Seasonality.
    • Trend: Set to Linear if your business is growing/shrinking steadily. Set to Constant if volume is stable.
    • Seasonality: Set the Seasonal Period to Weekly (7 days) or Monthly (30/31 days) depending on the business cycle. For most back-office operations, weekly seasonality is dominant (e.g., high volume on Monday, low on Friday).
  4. Enable Holiday Adjustment. Map your company holidays to the WFM calendar.

The Trap: Ignoring Weekly Seasonality in Back-Office
Voice traffic often has intra-day seasonality (e.g., peaks at 10 AM and 2 PM). Back-office traffic often has inter-day seasonality. For example, a claims department may receive 40% more cases on Monday due to weekend accumulations. If you configure the model with only Daily aggregation and ignore Weekly seasonality, the forecast will average out the Monday spike, leading to understaffing on high-volume days and overstaffing on low-volume days.

Solution:
Always enable Weekly Seasonality in the Holt-Winters configuration for back-office models. If the data shows strong monthly patterns (e.g., end-of-month billing cycles), enable Monthly Seasonality as well. The WFM engine can handle multiple seasonal periods, but you must explicitly define them.

Architectural Reasoning:
Holt-Winters is superior to simple moving averages for back-office work because it accounts for both trend and seasonality simultaneously. ARIMA is better for complex, multi-variate time series, but WFM’s implementation of Holt-Winters is optimized for the typical contact center data structure. By explicitly setting the seasonal period, you guide the algorithm to look for patterns over the correct timeframe, reducing the error rate.

4. Integrating External Drivers: CRM Volume Data

Historical data looks backward. To forecast accurately, you must look forward. Back-office work is often driven by external events: marketing campaigns, product launches, or seasonal sales.

Configuration Steps:

  1. Navigate to Workforce Management > Forecasting > External Data.
  2. Create a new External Data Source named CRM_Campaign_Volume.
  3. Define the Format: CSV or JSON.
  4. Map the columns:
    • Date: The date of the expected volume.
    • Channel: The channel type (e.g., Email).
    • Volume: The expected number of interactions.
    • AHT: The expected Average Handling Time (optional, but recommended if the campaign changes complexity).
  5. In the BackOffice_Email_Claims template, enable External Data Influence.
  6. Set the Weight of the external data. Start with 0.5 (50% historical, 50% external) and adjust based on validation.

The Trap: Double-Counting Volume
If your external data source includes volume that is already reflected in the historical trend (e.g., a recurring annual sale), adding it as an external driver will double-count that volume. The WFM engine will add the external volume on top of the historical baseline, resulting in a forecast that is 100% too high for that period.

Solution:
Use external data only for non-recurring or known variable events. For recurring events (e.g., Black Friday), rely on the historical seasonality model. For one-time events (e.g., a new product launch), use external data. If you are unsure, set the external data weight to 0.1 initially and monitor the forecast error.

Architectural Reasoning:
External data acts as a “force function” in the time-series model. It allows you to inject known future events into the forecast. By weighting the external data, you balance the trust in historical patterns with the trust in business intelligence. This hybrid approach reduces the Mean Absolute Percentage Error (MAPE) for volatile periods.

5. Validation and Error Analysis

Before deploying the forecast, you must validate it against known historical periods.

Configuration Steps:

  1. Navigate to Workforce Management > Forecasting > Validation.
  2. Select the BackOffice_Email_Claims template.
  3. Run a Backtest for the last 3 months.
  4. Review the MAPE (Mean Absolute Percentage Error).
    • Target MAPE: < 15% for back-office work.
    • Acceptable MAPE: 15-25%.
    • Unacceptable MAPE: > 25%.
  5. Analyze the Bias. Positive bias means the forecast is too high; negative bias means it is too low.

The Trap: Ignoring Bias in Favor of MAPE
A low MAPE does not guarantee accuracy. You can have a low MAPE with a high positive bias if the errors cancel out (e.g., overforecasting by 20% on Monday and underforecasting by 20% on Tuesday). This leads to inconsistent staffing. Always check the Bias metric. If the bias is consistently positive, the model is overestimating volume, leading to overstaffing and low utilization. If negative, you are understaffing, leading to agent burnout and SLA breaches.

Solution:
Adjust the Smoothing Parameters in the Holt-Winters model. If the bias is positive, increase the smoothing factor for the level component to make the model more responsive to recent drops in volume. If the bias is negative, decrease the smoothing factor to retain more historical weight.

Architectural Reasoning:
Validation is the feedback loop that closes the control system. Without it, you are deploying a black box. By monitoring MAPE and Bias, you can iteratively refine the model parameters. This process should be repeated monthly, as back-office work patterns can shift due to process changes or new tooling.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Zero-Volume” Day Problem

The Failure Condition:
The forecast predicts zero volume for certain days (e.g., holidays), but WFM still schedules agents, resulting in 0% utilization.

The Root Cause:
The Holt-Winters model may not fully zero out if the seasonal component is not strong enough, or if the external data is not correctly mapped to the holiday calendar. Additionally, WFM may apply a “minimum staffing” rule that overrides the forecast.

The Solution:

  1. Verify that the Holiday Calendar is correctly linked to the WFM model.
  2. Check the Minimum Staffing settings in the Scheduling template. Ensure that the minimum staffing is set to 0 for holidays for back-office queues.
  3. In the Forecast Template, ensure that Holiday Adjustment is enabled and that the holiday dates are marked as No Volume or Reduced Volume depending on the business reality.

Edge Case 2: AHT Volatility in Complex Cases

The Failure Condition:
The forecast volume is accurate, but the required staffing is wrong because the AHT varies wildly between simple inquiries and complex claims.

The Root Cause:
The WFM model uses a single average AHT for the entire queue. If 80% of cases are simple (5 min AHT) and 20% are complex (30 min AHT), the average AHT is 10 minutes. However, if the complex cases cluster on certain days, the average AHT for those days will be higher, leading to understaffing.

The Solution:

  1. Segment the Work Item Types. Create separate Forecast Templates for Simple_Inquiry and Complex_Claim.
  2. Use Interaction Attributes to classify the complexity in real-time.
  3. In WFM, assign agents to specific skills or groups based on the complexity.
  4. Forecast each segment independently. This allows the model to capture the variance in AHT more accurately.

The Solution:
Implement Skill-Based Forecasting. In Genesys Cloud, create separate Queues or Groups for different complexity levels. Map the Work Item Types to these queues based on attributes. Then, create separate Forecast Templates for each queue. This granularity allows the WFM engine to apply different AHTs and volume trends to each segment, resulting in a more accurate aggregate staffing plan.

Edge Case 3: Data Lag in Real-Time Integration

The Failure Condition:
The forecast is updated daily, but a sudden spike in volume occurs mid-week. The WFM model does not react until the next day, leading to SLA breaches.

The Root Cause:
Standard WFM forecasting is batch-processed. It does not ingest real-time interaction data. The model is static for the day.

The Solution:

  1. Enable Intraday Forecasting if available in your license tier. This allows WFM to adjust the forecast based on morning arrivals.
  2. Implement a Real-Time Alerting System using Genesys Cloud Events API. Monitor the queue length and AHT in real-time.
  3. If the queue length exceeds a threshold, trigger an alert to the WFM analyst to manually adjust the staffing plan for the remainder of the day.
  4. Use Overtime and Break Optimization features in WFM to dynamically adjust agent schedules during the day.

Official References