Can’t quite understand why the Performance Dashboard reports significantly lower Average Handle Time (AHT) for our French digital messaging queue compared to the actual session logs visible in the Conversation Detail view. The business stakeholders are questioning the efficiency metrics, as the dashboard suggests agents are resolving issues in under 3 minutes, while manual spot-checks indicate sessions often exceed 10 minutes due to concurrent customer inputs and internal knowledge base lookups.
The environment is running the latest standard release for the Paris region. The flow in question is a standard Omni-Channel routing flow, utilizing the ‘Route to Queue’ node with a priority-based selection strategy. The queue configuration is set to ‘Longest Idle Agent’ with a maximum wait time of 5 minutes.
The specific issue appears when analyzing the ‘Agent Performance’ view filtered by the ‘Digital’ channel. The ‘Wrap-up Time’ metric is consistently near zero, and the ‘Talk Time’ (which maps to active typing/listening time in digital) seems to truncate prematurely. However, the ‘After Call Work’ (ACW) time is inflated, which does not align with standard digital workflows where ACW is typically minimal.
Below is the relevant segment of the Architect flow JSON configuration for the routing block:
routing:
queue:
id: "fr-digital-support-01"
strategy: "longest_idle"
timeout: 300
actions:
- type: "route_to_queue"
parameters:
queue_id: "fr-digital-support-01"
priority: 5
metadata:
channel_type: "messaging"
language: "fr"
Is there a known limitation in how Genesys Cloud calculates handle time for messaging interactions that involve multiple sub-interactions or long periods of inactivity? The data action used to pull this report returns a 200 OK status, so the query syntax is valid. We need to reconcile these figures for the upcoming quarterly review. Any insight into the calculation logic for digital AHT would be appreciated.