Looking for some advice on troubleshooting this persistent data inconsistency between the Agent Performance dashboard and the underlying Predictive Routing scorecard metrics. We are operating in the Europe/Paris timezone and have recently migrated several high-volume queues to Predictive Routing. The issue manifests when viewing the ‘Agent Performance’ tab within the Performance application. Specifically, the ‘Offered’ and ‘Accepted’ call counts for agents assigned to predictive queues do not align with the historical data available in the Conversation Detail View or the standard Queue Activity reports. For instance, an agent shows 150 offered interactions in the Performance view for the last 24-hour period, yet the detailed export for the same timeframe and queue indicates only 90 offers were actually routed to that specific agent profile. This discrepancy creates significant friction during business reviews, as the executive summary relies on the Performance dashboard for high-level KPIs. We have verified that the time zone settings are consistent across the tenant configuration and the individual agent profiles. Furthermore, the data refresh interval appears to be functioning correctly, as standard WFM metrics update without delay. Is there a known latency or aggregation logic difference when Predictive Routing is enabled that causes the Performance dashboard to cache or calculate ‘Offered’ interactions differently than the raw event logs? We need to ensure the metrics reported to stakeholders accurately reflect the actual routing events to maintain trust in the analytics platform. Any insights into how the Performance application aggregates predictive offers versus standard queue offers would be appreciated.
If you check the docs, they mention that predictive routing metrics are calculated at the flow level, not the queue level, which creates a common disconnect for those coming from ticket-based systems like Zendesk.
Cause:
In Zendesk, a “ticket” is a single, atomic entity. When you migrate to Genesys Cloud with Predictive Routing, the “Offered” and “Accepted” counts in the Agent Performance view often lag or mismatch because the system tracks the offer event and the acceptance event separately within the flow execution. The performance dashboard aggregates these based on when the interaction is logged, whereas the scorecard calculates them based on the predictive model’s decision timestamp. This creates a temporal gap, especially during high-volume bursts in the Europe/Paris timezone where daylight saving transitions or server sync delays can exacerbate the lag.
Solution:
To align the metrics, you need to ensure your flow is explicitly logging the offer status. Check your Architect flow for the “Set interaction attribute” action immediately after the “Predictive Routing” node. You should map the routing.predicative.score and routing.predicative.offer_status to custom attributes. Then, adjust your performance view to filter by these custom attributes rather than the default system fields.
Additionally, verify the “Data retention” settings in Admin. If you are purging interaction logs too aggressively (e.g., 30 days), the scorecard recalculations will fail to find historical offer data, leading to discrepancies. Set the retention to at least 90 days for predictive queues.
Here is a snippet of the JSON config for the set attribute action to ensure proper tracking:
{
"name": "Set Offer Status",
"type": "set-attribute",
"data": {
"target": "interaction.attributes.custom.offerTimestamp",
"value": "{{ system.interaction.timestamp }}"
}
}
This mirrors how we used custom ticket fields in Zendesk to track SLA breaches, but here it ensures the performance engine has the correct timestamps to reconcile the counts.
If I remember correctly… the metric lag is often just a caching delay in the performance app rather than a data error.
- Wait 15 minutes for the analytics cache to refresh.
- Cross-reference the raw
GET /analytics/details/v2/interactionsAPI response to verify the actual counts.