Architecting WFM Scenario Models to Evaluate Headcount and Outsourcing Strategies

How-To-Articles
1

Architecting WFM Scenario Models to Evaluate Headcount and Outsourcing Strategies

What This Guide Covers

This guide details the architectural configuration of Workforce Management (WFM) Scenario models to simulate the impact of internal hiring initiatives and external outsourcing injections. The end result is a validated scenario plan that provides deterministic projections of Service Level (SL), Adherence, and Cost-to-Serve deltas compared to a locked baseline forecast, enabling data-driven decisions on labor strategy.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 3 or WFM Add-on License. Scenario modeling requires the WFM module enabled.
  • Permissions:
    • WFM > Scenario > Edit
    • WFM > Plan > Edit
    • WFM > Labor > Edit
    • WFM > Cost > View
  • OAuth Scopes:
    • wfm:scenario:write
    • wfm:scenario:read
    • wfm:plan:read
    • wfm:labor:write
  • External Dependencies:
    • A completed and optimized Baseline Plan.
    • Defined Skill Groups with accurate Service Level goals.
    • Configured Shrinkage Profiles (Internal and External).
    • Cost Configuration with Direct and Indirect cost mappings.

The Implementation Deep-Dive

1. Baseline Locking and Scenario Initialization

Scenario modeling relies on a deterministic delta calculation. The scenario engine computes the difference between the Scenario state and the Baseline state. If the Baseline mutates, the Scenario data becomes invalid, and the comparison metrics diverge from reality. We must enforce a strict immutability pattern on the Baseline Plan before initializing any Scenario.

The Trap: Baseline Mutation Drift
The most common failure mode occurs when an analyst modifies the Baseline Plan (e.g., adjusting forecast volume or adding holidays) after a Scenario has been created. The Scenario retains the snapshot of the Baseline at creation time. Subsequent Baseline changes create a silent divergence. The Scenario Comparison view will show deltas that no longer reflect the current operational reality, leading to erroneous ROI calculations. We prevent this by locking the Baseline Plan via API or enforcing a naming convention and governance policy that prohibits edits to plans marked PRODUCTION_BASELINE.

Architectural Reasoning
We initialize scenarios via the API to ensure version control and auditability. The UI is sufficient for ad-hoc analysis, but for hiring and outsourcing strategy evaluation, we require reproducible models. The API allows us to inject metadata tags (e.g., strategy=hiring_wave_3 or strategy=outsource_pilot) that facilitate programmatic retrieval and comparison across multiple strategy variants.

Implementation
Create the Scenario by referencing the immutable Baseline Plan ID. The payload must specify the scenario type and inherit the current labor model structure.

POST /api/v2/wfm/scenarios

{
  "name": "STRATEGY_EVAL_HIRING_Q4_2024",
  "description": "Evaluation of 50 FTE hiring in Skill Group: Technical Support. Inherited from PRODUCTION_BASELINE_Q4.",
  "planId": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "scenarioType": "WHAT_IF",
  "metadata": {
    "tags": [
      "hiring",
      "technical_support",
      "q4_strategy"
    ]
  }
}

Verify the response returns a scenarioId. This ID becomes the context for all subsequent labor and cost modifications. The system clones the labor structure from the baseline. We do not modify the baseline labor; we modify the scenario labor exclusively.

2. Configuring Labor Models for Internal Hiring Scenarios

When evaluating internal hiring, we must adjust the labor count while preserving skill allocations and shift patterns. The architectural decision here is whether to model hiring at the Group level or the Employee level. Group-level modeling is appropriate for aggregate headcount changes where individual identity does not impact the calculation. Employee-level modeling is required when hiring involves specific shift patterns or skill exceptions that deviate from the group norm.

The Trap: The Skill Coverage Mismatch
A frequent misconfiguration is increasing headcount in a Group without verifying the Skill coverage matrix. If the Group contains multiple skills with different weightings, adding generic headcount may disproportionately fill low-value skills while leaving high-value skills understaffed. The engine distributes additional labor based on the existing skill ratio. If the hiring strategy targets a specific skill, we must adjust the skill allocation explicitly. Failing to do so results in a projected SL improvement that masks a critical shortage in the targeted skill.

Architectural Reasoning
We use Scenario Labor updates to inject headcount. We calculate the required headcount based on the forecast volume and desired SL, then apply that count to the scenario. We must also validate that the new headcount adheres to the Labor Model constraints, such as maximum shift length and break rules. The engine recalculates adherence and availability based on the new labor count.

Implementation
Update the labor for the target Group. We increase the count and verify the skill mapping. If the hiring targets a specific skill, we adjust the skill distribution ratio.

PUT /api/v2/wfm/scenarios/{scenarioId}/labor

{
  "groupId": "grp_tech_support_01",
  "labor": [
    {
      "skillId": "skill_tech_l1",
      "count": 60,
      "unit": "HEADCOUNT"
    },
    {
      "skillId": "skill_tech_l2",
      "count": 10,
      "unit": "HEADCOUNT"
    }
  ]
}

In this example, the baseline had 50 L1 and 10 L2. The scenario adds 10 L1 hires. We must ensure the count reflects the total headcount after hiring, not the delta. The API replaces the labor configuration for the group within the scenario.

Shrinkage Validation
Internal hires may have different shrinkage profiles compared to tenured staff. New hires often experience higher training shrinkage. We must apply a Shrinkage Override to the new labor if the standard shrinkage profile does not account for ramp-up time.

PUT /api/v2/wfm/scenarios/{scenarioId}/groups/{groupId}/shrinkage

{
  "shrinkageProfileId": "prof_new_hire_ramp",
  "overrides": [
    {
      "shrinkageCodeId": "code_training",
      "value": 0.15
    }
  ]
}

This override increases the training shrinkage to 15% for the group in this scenario, ensuring the available labor calculation reflects the reduced productivity of new hires.

3. Injecting Outsourcing Variables and Cost Structures

Outsourcing scenarios require distinct architectural handling because external labor introduces variable costs, different shrinkage behaviors, and often separate skill constraints. We model outsourcing by creating a dedicated Outsourcer Group or by modifying an existing group to represent the external provider. The critical differentiator is the Cost Configuration and the Shrinkage Profile.

The Trap: The Shrinkage Blind Spot
Outsourcers frequently exhibit higher attrition and no-call/no-show rates than internal staff. Applying the internal shrinkage profile to outsourced labor underestimates the required headcount. The scenario will project that 100 outsourcers are available, but the shrinkage profile assumes only 10% loss. If the actual outsourcer shrinkage is 25%, the production SL will breach significantly. We must define a separate Shrinkage Profile for outsourcers that includes elevated codes for Attrition, NoCallNoShow, and Quality Assurance.

Architectural Reasoning
We isolate outsourcer labor in a dedicated Group to enable granular cost and shrinkage control. This isolation also allows us to simulate partial outsourcing strategies (e.g., 30% outsourced, 70% internal) without polluting the internal labor model. We assign a Cost per Hour to the outsourcer group that reflects the blended rate charged by the vendor, including any management fees.

Implementation
First, ensure the Outsourcer Group exists in the WFM configuration. Then, update the scenario labor to include the outsourcer headcount. We must also update the cost configuration to apply the outsourcer rate.

PUT /api/v2/wfm/scenarios/{scenarioId}/labor

{
  "groupId": "grp_outsourcer_vendor_a",
  "labor": [
    {
      "skillId": "skill_voice_gen",
      "count": 40,
      "unit": "HEADCOUNT"
    }
  ]
}

Next, apply the outsourcer-specific shrinkage profile.

PUT /api/v2/wfm/scenarios/{scenarioId}/groups/{groupId}/shrinkage

{
  "shrinkageProfileId": "prof_outsourcer_vendor_a",
  "overrides": []
}

Finally, validate the cost impact. The scenario engine aggregates costs based on the Cost Configuration. We must ensure the Cost Configuration maps the outsourcer group to the correct cost center and rate.

GET /api/v2/wfm/cost/configurations

Review the response to verify that grp_outsourcer_vendor_a is mapped to cost_center_ops_outsource with the correct hourly rate. If the mapping is missing, the scenario cost calculation will default to zero or an incorrect internal rate, invalidating the ROI analysis.

Cost-to-Serve Calculation
The scenario comparison includes Projected Cost. This value is derived from:
Sum(Labor Count * Available Hours * Cost Rate) + Indirect Costs

We must verify that Indirect Costs (e.g., facility, software licenses) are allocated correctly. Outsourcer labor may not incur internal indirect costs, or may incur different indirect costs. We adjust the indirect cost allocation in the Cost Configuration to reflect the true cost structure.

4. Executing Comparative Analysis and Validation

Once the labor and cost configurations are set, we execute the scenario comparison. The engine recalculates the schedule and metrics based on the scenario labor. This process can be computationally intensive for large scenarios. We monitor the scenario status via the API until the status transitions to READY.

The Trap: The Metric Silo
Analysts often focus exclusively on Service Level (SL) improvements. A scenario may achieve 95/80 SL by adding excessive labor, but the Cost-to-Serve may increase by 40%. Conversely, a cost-reduction scenario may cut labor but degrade SL to unacceptable levels. We must evaluate the SL Delta and Cost Delta simultaneously. We define acceptable thresholds for both metrics. A valid strategy must meet the SL target while staying within the budget constraint.

Architectural Reasoning
We use the Compare endpoint to retrieve the delta metrics. This endpoint returns the baseline metrics, scenario metrics, and the calculated differences. We parse the JSON to extract serviceLevel, cost, headcount, and adherence. We then apply business logic to determine if the scenario meets the strategic criteria.

Implementation
Retrieve the comparison data.

GET /api/v2/wfm/scenarios/{scenarioId}/compare

The response includes a comparison object.

{
  "comparison": {
    "baseline": {
      "serviceLevel": 0.82,
      "cost": 125000.00,
      "headcount": 150
    },
    "scenario": {
      "serviceLevel": 0.92,
      "cost": 145000.00,
      "headcount": 175
    },
    "delta": {
      "serviceLevel": 0.10,
      "cost": 20000.00,
      "headcount": 25
    }
  }
}

We analyze the delta. The scenario improves SL by 10% at a cost increase of $20,000. We calculate the Cost per SL Point to evaluate efficiency.

Cost per SL Point = Cost Delta / SL Delta = 20000 / 0.10 = 200,000

This metric allows us to compare multiple scenarios. A scenario with a lower Cost per SL Point is more efficient. We also review the Adherence Delta. If adherence drops significantly, the SL improvement may be fragile and dependent on perfect adherence, which is unrealistic.

Sensitivity Analysis
We run multiple scenarios to test sensitivity. We vary the outsourcer shrinkage by +/- 5% and observe the impact on SL and Cost. This reveals the risk profile of the strategy. If a small shrinkage change causes a SL breach, the strategy is too risky. We document these findings in the scenario metadata.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The Recursive Shrinkage Loop

Failure Condition: The scenario calculation fails to converge, or the status remains CALCULATING indefinitely.
Root Cause: A shrinkage code depends on headcount, and headcount depends on shrinkage. For example, if Attrition is calculated as a percentage of new hires, and new hires are determined by the required headcount after attrition, a circular dependency can occur. This is common when using dynamic shrinkage profiles in scenarios.
Solution: Ensure shrinkage codes are static percentages or fixed values in the scenario context. Avoid using shrinkage codes that reference scenario variables. If dynamic shrinkage is required, use the Shrinkage Override with a fixed value derived from external logic, rather than letting the engine compute it recursively. Check the shrinkageProfile configuration for circular references.

Edge Case 2: Skill Overlap in Outsourcing

Failure Condition: The scenario projects higher SL than expected, but the skill coverage report shows gaps.
Root Cause: The outsourcer group has skills that overlap with the internal group. The engine counts coverage from both groups for the overlapping skill. If the forecast volume is allocated to both groups, the total available labor may exceed the required labor, creating phantom coverage.
Solution: Validate the Skill Coverage report for the scenario. Ensure that the forecast volume is correctly allocated to the groups. If the outsourcer handles a portion of the volume, the forecast must be split. Use the Forecast Allocation feature to assign specific volume percentages to the outsourcer group. Verify that the sum of allocations equals 100%.

Edge Case 3: Cost Configuration Scope Mismatch

Failure Condition: The scenario cost delta is zero or incorrect, despite labor changes.
Root Cause: The Cost Configuration scope does not match the scenario date range or the group/skill hierarchy. Cost configurations are often scoped to specific date ranges or organizational units. If the scenario date range falls outside the cost configuration scope, the engine cannot apply the cost rates.
Solution: Review the Cost Configuration date range. Ensure it covers the scenario date range. Extend the cost configuration dates if necessary. Also, verify that the group and skill IDs in the scenario match the IDs in the cost configuration mappings. Use the Cost Validation tool to check for unmapped labor.

Official References