Inconsistency in 'Average Handle Time' Aggregation for Blended Voice/Chat Queues in EU-West

Struggling to figure out why the Average Handle Time (AHT) metric in the Performance Dashboard diverges significantly from the raw conversation logs for our blended voice and chat queues. The environment is Genesys Cloud EU-West (Paris), operating on the latest standard release. We are managing a high-volume Architect flow that routes inbound requests based on customer tier, utilizing omnichannel routing to balance agent workloads across voice and digital channels.

The specific issue manifests in the Queue Performance view. For a particular queue handling approximately 2,000 daily interactions, the dashboard reports an AHT of 320 seconds. However, when extracting the conversation detail data via the reporting export tool and calculating the weighted average manually, the figure is closer to 295 seconds. This 8% variance is substantial for our service level agreement (SLA) reporting and impacts our workforce management forecasting accuracy. The discrepancy appears most pronounced during peak hours (09:00-11:00 CET), where the volume of concurrent chat sessions is highest.

We have verified that the Architect flow logic correctly tags the conversation type and that the wrap-up time configuration is consistent across all agent groups. The ‘Talk Time’ and ‘Wrap-up Time’ components seem to align, suggesting the error lies in how the system aggregates or weights the multi-channel interactions within the dashboard’s backend calculation engine. It is unclear if the dashboard is applying a different weighting formula for chat interactions compared to voice, or if there is a latency issue in updating the aggregated metrics for high-throughput digital channels.

Could someone clarify the exact calculation methodology for AHT in blended queues? Specifically, does the system apply a distinct penalty or weighting factor for chat interactions that are not documented in the standard Performance Dashboard help articles? We require a definitive explanation to reconcile our internal reports with the platform’s native metrics.