Architecting What-If Scenario Planning Tools for Evaluating Staffing Model Alternatives

How-To-Articles
1

Architecting What-If Scenario Planning Tools for Evaluating Staffing Model Alternatives

What This Guide Covers

This guide details the architectural implementation of a dynamic “What-If” scenario engine within NICE CXone Workforce Management (WFM) or Genesys Cloud WFM to evaluate staffing model alternatives. You will build a configurable tool that allows planners to simulate changes in shrinkage, service level targets, and arrival patterns, then quantify the impact on headcount requirements and labor cost without altering the live forecasting model.

Prerequisites, Roles & Licensing

  • Licensing:
    • Genesys Cloud: WFM Module (Standard or Premium tier recommended for advanced scenario branching).
    • NICE CXone: WFM Module with “Scenario Planning” capability enabled.
  • Permissions:
    • Genesys Cloud: wfm:forecast:edit, wfm:schedule:edit, wfm:scenario:create.
    • NICE CXone: WFM Forecasting > Edit, WFM Scheduling > Edit, WFM Scenarios > Manage.
  • API Access:
    • Genesys Cloud: OAuth2 with scopes wfm:forecast:read, wfm:scenario:write.
    • NICE CXone: REST API credentials with WFM_Forecast and WFM_Schedule scopes.
  • Dependencies:
    • A stable historical forecast model with at least 12 months of data.
    • Defined shrinkage profiles (voluntary and involuntary) mapped to roles.

The Implementation Deep-Dive

1. Establishing the Baseline Forecast and Shrinkage Profile

Before introducing variables, you must anchor your scenarios to a deterministic baseline. A common failure mode is building scenarios on top of a volatile or unapproved forecast. The baseline must be a “locked” forecast version where the arrival patterns and service level targets are fixed.

In both Genesys Cloud and NICE CXone, the forecast is not a static number; it is a time-series projection of demand. The “What-If” engine relies on the delta between the baseline demand and the modified demand.

The Trap: Using the “Current” forecast view as a baseline. The current view updates in real-time as new historical data is ingested. If you build a scenario today and review it tomorrow, the baseline may have shifted by 2-5% due to auto-adjustments, invalidating your comparison.

Architectural Reasoning: We use a versioned snapshot. In Genesys Cloud, this is achieved by exporting the forecast to a specific version ID. In NICE CXone, we use the “Save as Scenario” feature which creates an immutable copy of the forecast data at the time of creation.

Implementation Step:

  1. Navigate to the Forecast module.
  2. Select the primary skill group or department (e.g., “US_Support_Tier1”).
  3. Ensure the forecast horizon is set to the planning period (e.g., next 4 weeks).
  4. Genesys Cloud: Click Export Forecast and save as a named version (e.g., “Baseline_v1”). Note the forecastId.
  5. NICE CXone: Click Create Scenario from the active forecast. Name it “Baseline_v1”.

API Reference (Genesys Cloud):
To programmatically lock the baseline, you retrieve the forecast ID and store it in a configuration object.

GET /api/v2/wfm/forecast/{forecastId}
Authorization: Bearer {access_token}

Response payload includes id, version, and skillId. Store id and version in your scenario metadata.

2. Defining Variable Parameters for Scenario Injection

A “What-If” tool is only as valuable as the variables it allows you to manipulate. In contact center architecture, the three critical levers are:

  1. Arrival Pattern Modification: Simulating a marketing campaign or a system outage.
  2. Shrinkage Adjustment: Modeling unexpected absenteeism or training gaps.
  3. Service Level Target Shift: Evaluating the cost of increasing SLA from 80/20 to 90/20.

You must structure these variables as modular inputs. Hardcoding values into the scenario logic prevents reuse.

The Trap: Modifying the shrinkage profile globally. If you change the shrinkage percentage in the main profile to test a scenario, you corrupt the baseline for all other planners. Shrinkage changes must be isolated to the scenario instance.

Architectural Reasoning: We treat shrinkage as a multiplier applied to the required labor hours. By isolating the shrinkage adjustment within the scenario object, we preserve the integrity of the master shrinkage profile. This allows for parallel testing: one planner can test “High Absenteeism” while another tests “Low Utilization” on the same baseline.

Implementation Step:

  1. Create a new Scenario object.
  2. Link it to the Baseline_v1 forecast ID.
  3. Define the variable parameters:
    • shrinkage_delta: Percentage point change (e.g., +5%).
    • arrival_multiplier: Factor applied to hourly arrivals (e.g., 1.2 for 20% increase).
    • sla_target: New service level percentage (e.g., 90).

API Reference (Genesys Cloud):
When creating a scenario, you pass the baseline forecast ID and the initial parameters.

POST /api/v2/wfm/scenarios
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "name": "Scenario_HighVolume_LowShrinkage",
  "description": "20% volume increase with 5% shrinkage reduction",
  "forecastId": "abc-123-def",
  "parameters": {
    "arrivalMultiplier": 1.2,
    "shrinkageDelta": -5.0,
    "slaTarget": 80
  }
}

API Reference (NICE CXone):
NICE CXone uses a slightly different structure, embedding the variables in the scenario definition.

POST /api/v2/wfm/scenarios
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "name": "Scenario_HighVolume_LowShrinkage",
  "forecastRef": "abc-123-def",
  "variables": {
    "arrivalPatternAdjustment": 1.2,
    "shrinkageAdjustment": -5.0,
    "serviceLevelTarget": 80
  }
}

3. Calculating the Staffing Delta and Cost Impact

The core of the What-If engine is the calculation of the staffing delta. This is not a simple addition of hours; it is an Erlang-C or Manninen calculation based on the modified arrival pattern and service level target.

The Trap: Assuming linear scalability. A 10% increase in volume does not result in a 10% increase in headcount. Due to the non-linear nature of queuing theory, a 10% volume increase might require a 15-20% headcount increase to maintain the same service level, especially near capacity limits.

Architectural Reasoning: We rely on the platform’s native Erlang-C engine. Genesys Cloud and NICE CXone both perform this calculation server-side. The API returns the requiredLaborHours for the scenario. We then compare this to the requiredLaborHours of the baseline.

The formula for headcount delta is:
Headcount_Delta = (Scenario_Required_Hours - Baseline_Required_Hours) / (Shift_Length * Utilization_Target)

However, the platform API often returns requiredAgents directly. Use this value for accuracy.

Implementation Step:

  1. Trigger the scenario calculation.
  2. Retrieve the requiredAgents for each time segment.
  3. Aggregate the total required agents for the period.
  4. Compare against the baseline aggregate.

API Reference (Genesys Cloud):
To get the staffing requirements, you query the scenario’s schedule details.

GET /api/v2/wfm/scenarios/{scenarioId}/schedule
Authorization: Bearer {access_token}

Response includes a scheduleDetails array with requiredAgents per time slot.

{
  "scheduleDetails": [
    {
      "startTime": "2023-10-01T08:00:00Z",
      "endTime": "2023-10-01T09:00:00Z",
      "requiredAgents": 12.5,
      "baselineRequiredAgents": 10.0
    }
  ]
}

Cost Calculation Logic:
To evaluate the financial impact, apply the fully loaded labor cost per agent.

Cost_Impact = (Sum(Scenario_Required_Agents) - Sum(Baseline_Required_Agents)) * Hourly_Rate * Hours_Per_Period

4. Visualizing the Trade-Offs

A raw number is insufficient for decision-making. You must visualize the trade-offs between service level, cost, and agent utilization.

The Trap: Focusing solely on cost. A scenario that saves money but drops service level to 50% is not viable. Conversely, a scenario that guarantees 95% service level but doubles headcount is unsustainable.

Architectural Reasoning: We build a dashboard that plots three axes:

  1. Service Level Achievement: Percentage of calls answered within target.
  2. Headcount Requirement: Total FTEs needed.
  3. Cost Variance: Dollar difference from baseline.

This allows planners to slide variables and see the immediate impact on all three axes.

Implementation Step:

  1. Create a dashboard widget that accepts the scenarioId.
  2. Fetch the schedule details and baseline details.
  3. Render a line chart comparing requiredAgents over time.
  4. Render a bar chart for Cost_Variance.

UI/UX Consideration:
Use color coding to indicate risk.

  • Green: Cost neutral or savings, SLA maintained.
  • Yellow: Cost increase <10%, SLA maintained.
  • Red: Cost increase >10% OR SLA breach.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Zero Arrival” Glitch

The Failure Condition:
When testing a scenario with a massive volume decrease (e.g., -90%), the required agent count drops to near zero. Some platform APIs may return 0 or null for required agents, causing division by zero errors in downstream cost calculations.

The Root Cause:
Erlang-C calculations break down when volume approaches zero. The mathematical model assumes a Poisson distribution, which is invalid for extremely low volumes.

The Solution:
Implement a floor value in your calculation logic. If requiredAgents < 1, set it to 1 for the purpose of cost estimation. This reflects the reality that you cannot schedule 0.1 agents; you must schedule at least one person to handle ad-hoc tasks or unexpected spikes.

Edge Case 2: Shrinkage Profile Mismatch

The Failure Condition:
The scenario calculation returns a required headcount that is significantly lower than expected, despite a volume increase.

The Root Cause:
The scenario inherited a shrinkage profile that is too low or does not match the role’s actual shrinkage. For example, if the baseline uses a “Seasonal” shrinkage profile (high shrinkage) but the scenario defaults to “Standard” (low shrinkage), the required headcount will be artificially deflated.

The Solution:
Explicitly map the shrinkage profile in the scenario creation step. Do not rely on defaults. When creating the scenario via API, include the shrinkageProfileId parameter.

{
  "name": "Scenario_Test",
  "forecastId": "abc-123-def",
  "shrinkageProfileId": "seasonal-profile-id",
  "parameters": { ... }
}

Edge Case 3: Timezone Drift in Multi-Region Scenarios

The Failure Condition:
The scenario shows a headcount spike at 2:00 AM local time, which is nonsensical.

The Root Cause:
The arrival pattern was modified using UTC timestamps, but the shrinkage profile or shift templates are defined in local time. The platform converts the arrival pattern to local time, causing a misalignment in the overlap calculation.

The Solution:
Always define arrival pattern adjustments in the local timezone of the skill group. When using the API, ensure the startTime and endTime in the schedule details are in the correct timezone. Genesys Cloud uses ISO 8601 with timezone offsets. NICE CXone requires explicit timezone specification in the forecast definition.

Official References