Stumbled on a weird bug today with the execution time metrics in our primary inbound queue flow within the EU-West environment. The specific issue involves a significant divergence between the ‘Average Execution Time’ reported in the Architect flow analytics dashboard and the actual call handling duration visible in the Queue Performance view.
We have a standard IVR flow configured with a series of menu options and database lookups. The flow is relatively straightforward, involving a maximum of three decision points before routing to an agent or queue. However, when reviewing the daily performance reports for the past two weeks, we are noticing that the Architect dashboard reports an average execution time of approximately 45 seconds. Conversely, the Queue Performance dashboard indicates an average call handling time of only 12 seconds for the same period and traffic volume.
This discrepancy is causing confusion among the operations team, as they are trying to optimize agent wrap-up times based on the Queue Performance data, while the Architect data suggests that the IVR itself is consuming a substantial portion of the caller’s journey. We have verified that the data filters in both dashboards are identical, focusing on the same date range and queue.
The error is not a hard failure, but rather a data inconsistency that undermines the reliability of our performance metrics. We are specifically looking for guidance on how to reconcile these two data sources. Is there a known latency in the Architect analytics processing pipeline that could cause such a delay in metric updates? Or is there a specific configuration setting within the flow that might be skewing the execution time calculation?
“Metrics mismatch detected: Flow execution time (45s) exceeds queue handling time (12s) by >200%”
Any insights into the underlying data collection methodology for these dashboards would be appreciated. We need to ensure that our business stakeholders are viewing accurate data when reviewing operational efficiency reports.