Designing Multi-Skill Forecasting Models that Account for Cross-Trained Agent Availability

Designing Multi-Skill Forecasting Models that Account for Cross-Trained Agent Availability

What This Guide Covers

This guide details the architectural methodology for configuring NICE CXone Workforce Management (WFM) to handle complex multi-skill routing scenarios where agent cross-training directly impacts shrinkage and availability calculations. You will learn how to structure skill groups, configure multi-skill agent profiles, and tune the forecasting engine to prevent overstaffing in primary queues while ensuring secondary queues remain serviceable during peak variance.

Prerequisites, Roles & Licensing

  • Licensing Tier: CXone WFM Standard or Premium license. The Premium tier is required for advanced multi-skill optimization algorithms and real-time adherence reporting against multi-skill shifts.
  • Granular Permissions:
    • WFM > Schedule > Edit
    • WFM > Forecast > Edit
    • WFM > Agent > Edit
    • WFM > Skill > Manage
  • External Dependencies:
    • A fully configured IVR or Web Chat routing structure that maps to specific CXone Skills.
    • Historical interaction data (minimum 12 months) segmented by skill to establish baseline arrival rates.
    • Defined Service Level Agreements (SLAs) per skill group, including distinct targets for primary and secondary skills.

The Implementation Deep-Dive

1. Architecting the Skill Hierarchy and Agent Profiling

The foundation of multi-skill forecasting is not the forecast itself, but the definition of how capacity translates across skill boundaries. In a single-skill environment, one agent hour equals one hour of capacity for one queue. In a multi-skill environment, one agent hour must be dynamically allocated based on priority, proficiency, and real-time demand.

The Trap: Defining cross-trained agents with equal proficiency levels for all skills. If an agent is marked as “Expert” in both “Billing” and “Technical Support,” the WFM engine treats them as interchangeable resources with zero penalty for switching contexts. This leads to the “Chaos of Equal Priority,” where the scheduler assigns agents to the queue with the highest immediate demand, ignoring the cognitive load and handling time variance associated with switching domains. This results in inflated Average Handle Time (AHT) and degraded First Contact Resolution (FCR).

The Architectural Approach:

You must implement a tiered proficiency model within CXone WFM. This involves creating distinct skill levels (e.g., L1, L2, L3) and assigning agents to these levels based on actual performance data, not just training completion.

  1. Create Skill Levels:
    Navigate to WFM > Configuration > Skills. For each primary skill (e.g., Billing), create sub-levels:

    • Billing_L1: Junior agents. Higher AHT, lower compliance risk.
    • Billing_L2: Standard agents. Baseline AHT.
    • Billing_L3: Expert agents. Lower AHT, authorized for complex escalations.
  2. Assign Multi-Skill Profiles:
    When assigning an agent to multiple skills, you must enforce a “Primary/Secondary” logic.

    • Set Billing as the Primary skill for Agent A.
    • Set Technical_Support as the Secondary skill for Agent A, but restrict it to Technical_Support_L2 or L3 only if Agent A has demonstrated proficiency.
  3. Configure Routing Priorities in CXone Studio:
    The WFM forecast is useless if the telephony layer does not respect the capacity model. In CXone Studio, ensure your Skill-Based Routing nodes prioritize Primary Skill matches over Secondary Skill matches. Use the Affinity settings to bias the router toward the agent’s primary skill unless the primary queue is idle.

Why this matters for forecasting:
The WFM forecasting engine uses historical AHT data. If you do not separate skills by proficiency level, the engine averages the AHT of experts and novices. When you forecast for a period where only novices are available (because experts are pulled to a secondary skill), the forecasted capacity will be higher than the actual effective capacity, leading to understaffing. By segmenting skills, the forecast engine can apply the correct AHT multiplier for the specific agent mix assigned to that shift.

2. Configuring the Multi-Skill Forecasting Model

CXone WFM allows for “Multi-Skill Forecasting,” but it requires explicit configuration of how skills interact. The default behavior often assumes independence between skills, which is incorrect in a cross-trained environment.

The Trap: Using independent forecasts for each skill and summing the headcount requirements. If Billing requires 10 agents and Tech Support requires 8 agents, a naive model requests 18 agents. However, if 5 agents are cross-trained, the actual requirement is likely 13 or 14, not 18. Conversely, if you simply take the max (10), you will starve the secondary queue during its peak. This is the “Summation Fallacy.”

The Architectural Approach:

You must utilize the Multi-Skill Optimization feature in CXone WFM, which requires defining “Skill Groups” and “Capacity Sharing Rules.”

  1. Define Skill Groups:
    Group related skills that share a common agent pool.

    • Create a Skill Group named Customer_Service_Core.
    • Add Billing, Tech_Support, and General_Inquiries to this group.
  2. Configure Capacity Sharing Rules:
    Within the Skill Group configuration, define the rules for how capacity flows:

    • Rule 1: Agents assigned to Billing may be pulled to Tech_Support only if Billing queue length < 5 AND Tech_Support wait time > 30 seconds.
    • Rule 2: Agents assigned to Tech_Support may NOT be pulled to Billing (due to compliance/training constraints).

    This asymmetry is critical. The forecasting engine must know that capacity can flow one way but not the other.

  3. Tune the Shrinkage Model per Skill:
    Cross-trained agents often experience higher shrinkage due to context switching fatigue.

    • Create a custom Shrinkage Profile named Multi_Skill_Cross_Trained.
    • Increase the “Personal Shrinkage” and “Meeting Shrinkage” percentages by 10-15% compared to single-skill agents.
    • Assign this profile to agents with >1 primary skill assignment.
  4. Execute the Forecast:
    When running the forecast, select the Multi-Skill Optimization option. The engine will now:

    • Calculate the independent demand for each skill.
    • Identify overlapping demand periods.
    • Apply the Capacity Sharing Rules to determine the minimum headcount required to meet SLAs for the entire group.
    • Output a “Blended” headcount requirement that accounts for the efficiency gains of cross-training while penalizing for the shrinkage overhead.

The Mathematical Implication:
The engine solves a linear programming problem where:
Minimize(Total_Agents)
Subject to:
Capacity_Skill_A(t) >= Demand_Skill_A(t) / AHT_A
Capacity_Skill_B(t) >= Demand_Skill_B(t) / AHT_B
Capacity_Skill_A(t) + Capacity_Skill_B(t) <= Total_Agents_Available(t)

By defining the sharing rules, you constrain the feasible region of this equation, forcing the engine to find the optimal intersection point rather than the union or the sum.

3. Scheduling with Multi-Skill Constraints

The final step is translating the forecasted headcount into actual shift schedules. This is where the theoretical model meets operational reality.

The Trap: Allowing the scheduler to assign agents to shifts without enforcing “Skill Balance.” The scheduler might assign 10 agents to a shift, all of whom are primarily Billing agents, because that is the largest pool. If Tech_Support demand spikes, these agents cannot effectively handle the load due to the proficiency gap defined in Step 1.

The Architectural Approach:

  1. Define Skill Requirements per Shift:
    In the Scheduling module, do not just request “10 Agents.” Request:

    • Billing_L2: 8 Agents
    • Tech_Support_L2: 5 Agents
    • Cross_Trained_Billing_Tech: 2 Agents
  2. Use “Must-Have” vs. “Nice-to-Have” Skills:
    Configure the scheduling rules to treat Primary Skills as “Must-Have” and Secondary Skills as “Nice-to-Have” or “Buffer.”

    • Set a constraint: Minimum_Billing_Coverage = 80% of Forecasted_Billing_Demand.
    • Set a constraint: Minimum_Tech_Coverage = 50% of Forecasted_Tech_Demand (allowing more flexibility for overflow).
  3. Implement “Float” Roles:
    Create a specific role or schedule type called Float_Cross_Trained. These agents are not assigned to a specific queue for the majority of their shift. Instead, they are assigned to a “General” skill that can be dynamically routed by CXone Studio based on real-time queue depth.

    • In WFM, forecast these agents as a separate resource pool.
    • Allocate 10-15% of your total headcount to this float pool.
    • This pool absorbs variance in both skills, reducing the need for overtime in either queue.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Primary Skill Starvation” Event

The Failure Condition:
During a peak period for Billing, the system pulls all cross-trained agents into Billing because the Tech_Support queue is quiet. Suddenly, a burst of Tech_Support calls arrives. The queue explodes because no agents are available, even though there are idle agents in Billing.

The Root Cause:
The routing configuration in CXone Studio is too aggressive in pulling agents away from secondary skills. The “Threshold” for pulling an agent is set too low (e.g., wait time > 10 seconds).

The Solution:
Adjust the Skill Priority and Thresholds in CXone Studio.

  1. Increase the wait time threshold for secondary skill activation to 60-90 seconds.
  2. Implement a “Soft Pull” mechanism: Agents remain logged into their primary skill but are “available” for secondary calls only if the primary queue is empty for >2 minutes.
  3. In WFM, review the Utilization Report. If Primary Skill utilization is >85% and Secondary Skill SLA is <50%, you have a routing imbalance. Reduce the forecasted headcount for the Primary Skill slightly to force more agents into the Secondary/Float pool.

Edge Case 2: The “Shrinkage Cascade”

The Failure Condition:
The forecast predicts 20 agents are needed. You schedule 20 agents. However, 3 agents call in sick, and 2 are in mandatory training. The system shows 15 agents available. The WFM engine did not account for the fact that these 5 absent agents were cross-trained, creating a disproportionate impact on the secondary skill queue.

The Root Cause:
The shrinkage model is applied globally, not per-skill. When a cross-trained agent is absent, they remove capacity from two skills simultaneously. A global shrinkage rate averages this out, masking the specific risk to the secondary skill.

The Solution:

  1. Enable Skill-Specific Shrinkage in WFM.
  2. Create a “Cross-Training Penalty” in the shrinkage model. If an agent is assigned to 2 skills, their individual shrinkage factor is multiplied by 1.1 for each additional skill.
  3. When generating the schedule, force the system to overstaff the secondary skill by 10% above the forecasted requirement to buffer against the higher variance caused by cross-trained agent absences.

Edge Case 3: The “AHT Drift” Anomaly

The Failure Condition:
The forecast is accurate, staffing is accurate, but the Service Level (SL) drops. Investigation reveals that agents handling secondary skills have an AHT 20% higher than the historical average used in the forecast.

The Root Cause:
The historical data used for forecasting included periods where agents were highly proficient in secondary skills. Recently, a new process change or system update increased complexity, but the WFM forecast was not retrained with recent data. The “Secondary Skill AHT” variable in the forecast model is stale.

The Solution:

  1. Navigate to WFM > Forecast > Historical Data.
  2. Filter the data by Skill = Tech_Support_L2 and Agent_Type = Cross_Trained.
  3. Compare the AHT from the last 30 days against the 12-month average.
  4. If the variance is >10%, trigger a Manual Forecast Adjustment. Increase the AHT for the secondary skill in the forecast model by the observed delta.
  5. Re-run the optimization. The system will likely recommend more headcount or a shift in the Primary/Secondary ratio to compensate for the lower efficiency.

Official References