I am finding a consistent discrepancy between the wrap-up duration shown in real-time dashboard and the historical analytics reports. I use both to monitor agent performance and these numbers need to match for our workforce planning models.
Specific example: Agent user-uuid-1234 completed a call at 14:32:15 JST. The real-time queue view showed wrap-up duration of 45 seconds. But when I query the same conversation via the historical analytics API 30 minutes later, tAcw returns 68 seconds.
This is not an isolated incident. I exported 200 conversations from yesterday and compared real-time vs historical tAcw for each. The historical value is consistently 15-25 seconds higher than what the real-time view displayed.
Query I am using for historical:
{
"interval": "2025-05-14T00:00:00.000+09:00/2025-05-15T00:00:00.000+09:00",
"granularity": "PT30M",
"metrics": ["tAcw"],
"filter": {
"type": "dimension",
"dimension": "userId",
"operator": "matches",
"value": "user-uuid-1234"
}
}
I understand small differences from processing delay, but 15-25 seconds is too large. Is there a known methodology difference between how real-time and historical calculate tAcw?
This is not a bug - the two views intentionally measure different things and Genesys does a terrible job of documenting it.
The real-time queue view calculates ACW duration from the moment the conversation disconnects until the agent clicks “End ACW” or the auto-wrap timer expires. This is the wall-clock time the agent spent in the After Call Work state.
The historical tAcw metric includes the wall-clock ACW time PLUS any time the agent spent in the ACW state that was interrupted by a supervisor force-status-change or a system event. If a supervisor manually changed the agent from ACW to Available before the timer expired, and then the system logged an additional reconciliation event, that reconciliation window gets added to the historical tAcw.
But the most common cause of the 15-25 second discrepancy is the auto-wrap-up configuration. Check your queue settings under Admin > Contact Center > Queues > [Queue] > After Call Work. If “Auto End After Call Work” is enabled with a timeout, the historical metric counts from disconnect until the auto-end fires. The real-time view counts from disconnect until the agent manually ends ACW or until the UI refreshes - whichever comes first. The UI refresh interval is typically 15 seconds, which explains your exact gap.
This real-time vs historical divergence is one of the top 5 complaints I hear during enterprise RFP evaluations. Every CCaaS platform has some version of this problem, but Genesys Cloud’s is particularly confusing because the metric names are identical.
If you need a single source of truth for workforce planning, always use the historical analytics API. The real-time view is designed for supervisor situational awareness, not for data warehousing.
One additional gotcha: if your agents handle multiple media types (voice + chat), the tAcw metric in a queue-level aggregate will include ACW time from ALL media types routed through that queue. If you are comparing agent-level ACW to queue-level ACW, filter by mediaType: voice in your historical query to get an apples-to-apples comparison.
To build on the discussion above, if your workforce planning model requires sub-second accuracy on wrap-up duration, the most reliable approach is to bypass the aggregate metrics entirely and calculate ACW from the raw conversation detail segments.
Query the conversation details API and extract the segment data:
GET /api/v2/analytics/conversations/{id}/details
In the response, find the agent participant and look for segments where segmentType: wrapup. The segment has segmentStart and segmentEnd timestamps. Calculate the duration yourself by subtracting the two timestamps.
This gives you the exact kernel-level ACW duration without any aggregation artifacts, UI refresh timing, or reconciliation events. We use this method in our Architect flows to calculate rolling average ACW per queue and dynamically adjust the auto-wrap timer based on actual performance rather than the configured static value.