We’re trying to calculate agent utilization metrics using the /api/v2/analytics/conversations/queries/intervals endpoint. The requirement is to get tHandle, tAcw, and tHold broken down by 30-minute intervals for the last 24 hours.
Here’s the payload we’re sending:
{
"groupBy": ["interval"],
"interval": "30m",
"dateFrom": "2023-10-27T00:00:00.000Z",
"dateTo": "2023-10-27T23:59:59.999Z",
"select": ["tHandle", "tAcw", "tHold"],
"where": [
{
"path": "conversationType",
"operation": "in",
"value": ["voice"]
}
]
}
The API returns 200 OK, but the data in the intervals array looks aggregated in a weird way. The tHandle values seem to include time that should be counted as tAcw based on our internal logs. We’re summing the tHandle across all intervals for a specific agent, and it’s exceeding the total available minutes in the day.
We’ve tried adding "groupBy": ["interval", "wrapUpCode"] to see if that splits the ACW time out, but the tAcw bucket remains empty or near zero in the response. The docs mention that tAcw is only available for specific conversation types, but we’re filtering for voice.
Is there a specific query parameter or where clause needed to isolate the actual post-call work time? We’re using the Java SDK to make the request, but the raw JSON response is what we’re inspecting. The tHold values look correct, so the filtering isn’t totally broken.
We’re in America/Chicago timezone, and we’ve verified the dateFrom and dateTo are in UTC. The response object has summarizedByInterval set to true, but the granularity isn’t matching our expectations.
Any ideas on how to structure the select array or the groupBy to get distinct buckets for handle time and after-call work? The current output makes it impossible to calculate a true utilization rate.