Predictive routing queue depth mismatch after zendesk migration

Why does this setting in the predictive routing queue configuration not align with our legacy Zendesk ticket volume metrics? we migrated our digital channels from Zendesk to Genesys Cloud last week. in Zendesk we used simple ticket counts for SLA tracking. now in GC we are seeing the predictive routing queue depth reported as zero even when there are active interactions.

the API call to /api/v2/routing/queues/{queueId} returns the correct member count but the wait count is always null. we are using the Genesys Cloud REST API v2. the environment is EU2. we have configured the queue with predictive routing enabled. the agents are online and available.

in Zendesk the workflow was straightforward: ticket created → assigned to agent. here the flow is much more complex with skills and wrap-up codes. we are mapping the Zendesk tags to GC skills. maybe the skill mapping is wrong? or is it a data lag issue? the error code is 200 so the request succeeds but the data seems stale.

we tried clearing the cache and restarting the architect flow but nothing changed. any tips on how to debug this? coming from Zendesk this level of opacity is frustrating. we need accurate wait times for our SLA reports.

{
“wait_count”: null,
“member_count”: 5
}

You need to enable `includeWaitCounts` in the query parameters for that endpoint. Predictive routing often requires explicit flags to expose real-time queue metrics. The default response omits wait data to reduce payload size. Check the routing docs for optional parameters.

GET /api/v2/routing/queues/{queueId}?includeWaitCounts=true

The suggestion above is correct. The default payload suppresses wait metrics to optimize throughput. When managing high-volume trunks, explicit inclusion prevents unnecessary data transfer. Verify the response body now contains the integer value for wait_count. This aligns with standard BYOC monitoring practices.