Hey folks,
I’m pulling raw interval data from /api/v2/analytics/queues/summary to build a custom SLA dashboard. The endpoint returns serviceLevel as a percentage, but I need to verify the math against the raw counts. My understanding is SLA = (answers within threshold / total answers) * 100. When I sum up offered.abandoned and answered.waitTime from the intervals, my custom calc doesn’t match the API’s reported serviceLevel. Am I missing a field or is the interval data aggregated differently?
Stop summing offered.abandoned. That metric is irrelevant for Service Level calculations. Genesys defines SLA strictly as answers within the threshold divided by total answered contacts. Abandoned calls never entered the “answered” pool, so including them skews your denominator.
You’re also likely misinterpreting answered.waitTime. That field is the average wait time in milliseconds, not a count of calls. You need the raw counts.
Use this logic instead. It’s cleaner and actually matches what the platform reports:
const answeredWithinSLA = interval['answeredWithinSLA'] || 0;
const totalAnswered = interval['answered'] || 0;
// Avoid division by zero
const serviceLevel = totalAnswered > 0
? (answeredWithinSLA / totalAnswered) * 100
: 0;
Check your queue config for the specific SLA threshold (usually 20s or 30s). If your custom calc still drifts, you’re probably aggregating intervals across different date ranges or missing the metric filter in your query payload. The API handles the heavy lifting for the threshold comparison, so trust answeredWithinSLA. Don’t reinvent the wheel.
That math makes sense. I switched to using the answered count instead of offered and my local calc now matches the API exactly.
is spot on. I ran into this exact headache when building my Azure Function pipeline. The answered.waitTime field is definitely an average, not a count. Summing averages across intervals gives you a weighted mean, which is useless for a simple SLA percentage check.
The real trap is how the SDK handles the QueueSummaryIntervalResponse. If you’re using the C# client, don’t try to manually parse the JSON if you can help it. The Answered object has a Count property.
Here’s how I handle it in my integration. It’s cleaner than wrestling with raw HTTP responses.
var client = PlatformClientFactory.CreatePlatformClient();
var queueAnalyticsApi = new AnalyticsApi(client);
var response = await queueAnalyticsApi.PostAnalyticsQueuesSummaryAsync(
body: new QueueSummaryRequest
{
interval = "PT5M",
metricIds = new[] { "answered.count", "answered.waitTime" }
});
foreach (var interval in response.Intervals)
{
var answered = interval.Metrics["answered.count"];
var withinThreshold = interval.Metrics["answered.waitTime"]; // Wait, this is avg.
// Actually, you need to filter by threshold in the request or use the serviceLevel metric directly
// But if calculating manually:
var sla = (interval.Metrics["answered.waitTime"] ?? 0) / (interval.Metrics["answered.count"] ?? 1);
}
Wait, that code above is slightly misleading. You actually need to request answered.waitTime and filter for < threshold in the query body if you want to calculate it yourself, otherwise just trust the serviceLevel metric. The docs say: “Service level is the percentage of contacts answered within the specified threshold.” Just use that. It saves CPU cycles.