How does the Performance Dashboard actually calculate Queue Occupancy when wrap-up time gets added to the mix? The ops team is doing jack all to reconcile a 15% gap between reported occupancy and what the agents see on their desktops. Payroll audits can’t clear because the dashboard shows 82% occupancy, but the timesheet logs won’t pull past 68%. Running Genesys Cloud version 2023-07-26, org timezone set to Asia/Tokyo. The dashboard is pulled from the standard Performance > Queue Activity view, filtered to the last 30 days. shows the Occupancy column hovering right at 84% for the Tokyo Sales queue. The Conversation Detail view breaks down the same day differently. Does the metric count after-call work or just talk time? Is there a known rounding issue when handling multiple transfers in a single span? It’s throwing a metric_calculation_mismatch error code in the analytics preview. Console logs show a 403 on the /v2/analytics/details endpoint when drilling past the 24-hour mark. The export just hangs there.
The dashboard aggregation logic tends to smooth out wrap-up windows differently than the desktop agent view does. We ran into the exact same discrepancy when syncing interaction durations to ServiceNow tickets. Here’s what we checked first:
- Verified the Queue Occupancy metric definition in the dashboard settings. Failed to find a toggle that excludes post-call work from the numerator.
- Ran a direct query against the standard Performance report. The numbers still drifted by about 12% when comparing against agent login logs.
- Swapped the time filter to real-time instead of historical. Failed to close the gap. Pointed to a data sampling issue rather than a timezone offset.
Wrap-up windows are messy. The dashboard just averages them out. Instead of relying on the pre-built Queue Activity report, you’ll get a tighter match by pulling the raw interaction details and calculating occupancy yourself. The analytics endpoint lets you isolate postCallWork and talkTime explicitly. Here’s a curl request that bypasses the dashboard aggregation:
curl -X POST "https://api.mypurecloud.com/api/v2/analytics/icd/details" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"interval": "2023-11-01T00:00:00Z/2023-11-01T23:59:59Z",
"groupBy": ["interactionId", "agentId"],
"metrics": ["talkTime", "postCallWork", "queueWaitTime"],
"filter": {
"type": "equal",
"field": "routingType",
"value": "QUEUE"
}
}'
You’ll need the view:analytics:icd scope on your OAuth token. Once you pull that payload, sum the talkTime and postCallWork for each agent, then divide by their total availability. The desktop usually caps wrap-up at the maxWrapUpTime threshold defined in the skill group. Anything bleeding past that gets dropped from the agent’s local calculation. The dashboard counts it anyway.
Are you pulling the timesheet data through the WFM API or just exporting the agent login logs manually? The availability metric usually hides the gap if the export doesn’t include loginBreak durations. Check the maxWrapUpTime threshold on the skill group.