Ran into a weird issue today with the Predictive Routing score persistence logic within our EU-FR environment. The business stakeholders are questioning the accuracy of the ‘First Contact Resolution’ metric when correlated against the Predictive Routing confidence scores in the Performance Dashboard.
The issue manifests when an interaction is routed based on a high-confidence skill match (score > 0.85) but the agent subsequently transfers the case. In the Architect flow, the transfer action is logged correctly, and the interaction history reflects the transfer. However, in the Performance Dashboard’s Agent Performance view, the original high-confidence score remains attached to the initial leg of the interaction, while the second leg shows no routing score data. This creates a significant discrepancy when calculating the effectiveness of the routing model for quarterly reviews. The dashboard appears to be caching the initial prediction rather than updating it based on the final disposition or transfer event.
We have verified that the Architect flow is configured to reset context variables upon transfer, yet the dashboard metrics do not reflect this reset. The data lag seems inconsistent; sometimes the corrected metrics appear after 24 hours, other times they do not update at all. This is causing confusion in the reporting layer, as the ‘Routing Accuracy’ KPI is inflated by these stale high-confidence scores that did not result in a resolution.
- Verified the Architect flow configuration to ensure context variables are cleared on transfer actions, and confirmed that the interaction history API returns the correct sequence of events with updated dispositions.
- Checked the Performance Dashboard settings for any custom filters or date range anomalies, and compared the raw data export against the dashboard visualization to confirm the data discrepancy exists in the underlying aggregation logic.
Is there a known limitation regarding how Predictive Routing scores are aggregated in the Performance Dashboard when multiple interaction legs are involved? We need to understand if this is a reporting bug or a misconfiguration in how we are defining the ‘resolution’ event within the flow.