Why does this setting in the Architect flow impact the accuracy of the ‘Service Level’ metric within the Performance Dashboard? Our organization operates within the EU-West BYOC environment, and we have observed a consistent variance between the reported service levels and the actual conversation outcomes. The dashboard indicates a 90% service level achievement, yet the Conversation Detail view reveals that 15% of calls exceeded the defined target time. This divergence affects our monthly reporting to stakeholders, who rely on these metrics for operational adjustments. The issue persists across multiple queues, suggesting a systemic configuration error rather than an isolated incident.
The flow configuration includes a standard IVR structure with a primary queue node and a fallback node for overflow. The timeout settings are aligned with the service level targets, yet the dashboard metrics do not reflect the actual wait times recorded in the system logs. We have verified that the time zone settings are correctly configured to Europe/Paris, and the data retention policies are set to retain detailed logs for 30 days. Despite these checks, the discrepancy remains, leading to confusion in interpreting the performance data. The metrics appear to be calculated based on an incorrect timestamp or a misaligned definition of service level achievement within the dashboard logic.
We require clarification on the correct configuration to ensure that the Performance Dashboard accurately reflects the queue activity and agent performance. Specifically, we need to understand how the dashboard calculates service levels and whether any adjustments are necessary in the Architect flow or the dashboard settings. Any insights into resolving this metric divergence would be greatly appreciated, as it is critical for maintaining accurate performance reporting and operational efficiency within our organization. Please advise on the best practices for aligning dashboard metrics with actual conversation data in the EU-West BYOC environment.