Predictive Routing Capacity Calculation Discrepancy in Performance Dashboard

Genesys Cloud Routing
1

Trying to make sense of why the Predictive Routing Capacity metric in the Performance Dashboard shows a 15% variance against the actual agent occupancy during peak hours in the Europe/Paris timezone. The queue configuration uses standard skill-based routing with no custom scripts, yet the dashboard indicates available capacity when agents are fully occupied. Is there a known latency in how the predictive engine reports real-time availability compared to the standard queue metrics?

2

If I recall correctly, the Predictive Routing capacity calculation does not rely on real-time agent state updates in the same manner as the standard queue metrics. The engine uses a historical performance model based on Average Handle Time (AHT) and historical answer rates to project availability. A 15% variance during peak hours in Europe/Paris often stems from a mismatch in how wrap-up time is recorded versus how the PR engine forecasts post-call availability. Check if the agents are manually extending wrap-up time or if there is a delay in the “Available” status transition due to SIP registration keep-alives from your BYOC trunks. Ensure that the ‘Available’ status is explicitly set in the flow before the interaction ends, otherwise the PR engine assumes the agent is still occupied. You might need to adjust the confidence level in the PR settings or increase the buffer for AHT calculations. This discrepancy is usually resolved by aligning the flow logic with the PR forecasting model rather than expecting real-time parity with the dashboard.

3

The simplest way to resolve this is…

  • Align dashboard polling with PR engine refresh cycles via CLI
  • Verify wrap_up_time consistency in agent profiles
  • Check timezone offset handling in dashboard filters
4

yeah, that variance is totally expected if you’re comparing real-time agent state against the predictive model’s projected capacity. the PR engine doesn’t just look at who is available right now. it runs a forecast based on historical AHT and answer rates to predict how many calls it can handle in the next 10-15 minutes. if your agents are manually extending wrap-up or the historical AHT is stale, the model thinks they’ll be free sooner than they actually are.

the 15% gap during peak hours usually means the historical data hasn’t caught up to the current call complexity. the dashboard shows “available capacity” because the model predicts agents will finish their current interactions and become available within the routing window, even if they are currently in-call or wrap-up.

if you want to debug this, check the analytics endpoint for the specific queue. pull the predictive_routing_capacity metric and compare it against agent_occupancy.

import requests
import pandas as pd

# get the last 24 hours of predictive capacity vs occupancy
url = "https://{{org}}.mygenesys.com/api/v2/analytics/queues/realtime"
params = {
 "dateRange": "now-24h..now",
 "metrics": ["predictive_routing_capacity", "agent_occupancy"],
 "groupBy": "interval_5m"
}

resp = requests.get(url, params=params, auth=auth)
data = resp.json()

df = pd.DataFrame(data['results'])
# check correlation between predicted capacity and actual occupancy
print(df[['predictive_routing_capacity', 'agent_occupancy']].corr())

if the correlation is low, your historical AHT is probably off. go into the queue settings and check the averageHandleTime used for predictive routing. it’s often auto-calculated but can drift if there’s a lot of blended work (chat/voice). forcing a manual AHT update or enabling dynamicAHT might help the model align closer to reality. the engine is probabilistic, not deterministic, so some variance is normal. just make sure the wrap_up_time isn’t being artificially inflated by agents.

5

confirmed. turning off manual wrap-up extensions in the queue settings closed the gap. the dashboard numbers finally matched actual occupancy.