WFM long-term forecast — incorporating seasonal patterns for retail

We are building a long-term WFM forecast that needs to account for Black Friday, Christmas, and summer seasonality.

The GC WFM forecast tool only looks back 6 weeks. How do we incorporate seasonal patterns from last year into this year’s forecast?

Export last year’s daily volumes from the analytics API and manually seed the WFM forecast.

The native GC forecast uses a 6-week window, which misses annual patterns. Supplement it by creating a custom seasonal adjustment layer:

1. Pull daily volumes for the same period last year
2. Calculate the seasonal multiplier (holiday volume / normal volume)
3. Apply the multiplier to the GC baseline forecast

def calculate_seasonal_multiplier(current_year_baseline, last_year_holiday, last_year_normal):
    multiplier = last_year_holiday / last_year_normal
    seasonal_forecast = current_year_baseline * multiplier
    return seasonal_forecast

# Black Friday 2024: last year saw 3.2x normal volume
bf_forecast = calculate_seasonal_multiplier(
    current_baseline=500,  # Normal daily calls
    last_year_holiday=1600,
    last_year_normal=500)
# bf_forecast = 1600 calls expected

From an Erlang modeling perspective, seasonal forecasting requires separate shrinkage assumptions.

During holiday periods, unplanned shrinkage increases (agents calling in sick to extend their vacation). Apply a 5-8% additional shrinkage buffer for the week surrounding major holidays.

We A/B tested manual seasonal adjustment vs the native GC forecast during Black Friday.

The hybrid approach outperformed both standalone methods.

In CXone, the WFM module has a native ‘seasonal planning’ feature that imports multi-year historical data.

GC lacks this native capability. You have to build the seasonal layer externally. This is one of the most frequently requested WFM enhancements on the Genesys Ideas portal.

For our APAC deployment, seasonal patterns vary dramatically by country.

Australian holiday patterns (Christmas in summer) are opposite to Northern Hemisphere patterns. Japanese Golden Week creates a unique spike. Each country needs its own seasonal model. Don’t apply a US-centric seasonal curve to a global deployment.

Under European Working Time Directive, seasonal staffing must still comply with maximum hour regulations.

Even during a 300% volume spike, agents cannot exceed 48 hours per week. Your seasonal staffing plan must either hire temporary staff or redistribute shifts across the week to comply.

We integrate the seasonal forecast with our Salesforce pipeline data.

If the sales pipeline shows a large deal closing in Q4, our seasonal model adjusts for the expected increase in onboarding support calls. The WFM team gets a 6-week heads-up to prepare staffing for the new client go-live.

From a callback perspective, seasonal spikes require separate callback capacity planning.

During Black Friday, our callback queue fills up 5x faster than normal. Without seasonal adjustment, the callback SLA (return call within 2 hours) stretches to 8 hours. Pre-allocate dedicated callback agents during peak periods.

# AWS CloudWatch alarm for seasonal volume threshold
SeasonalVolumeAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: seasonal-volume-breach
    MetricName: InteractionsOffered
    Namespace: GenesysCloud/WFM
    Statistic: Sum
    Period: 3600
    EvaluationPeriods: 1
    Threshold: 800  # 1.6x normal baseline of 500
    ComparisonOperator: GreaterThanThreshold
    AlarmActions: [!Ref WFMAlertTopic]