Discrepancy in Service Level calculation from raw Analytics API intervals

Just noticed that my GraphQL gateway returns skewed Service Level percentages when aggregating raw interval data from /api/v2/analytics/queues/events/summary. The accepted and answered counts align with the platform UI, but the calculated SL% is off by ~5%.

I am summing accepted and answered from each 15-second interval. Is the Service Level threshold applied per-interval or across the full window? Here is my aggregation logic:

const sl = (data.answered / data.accepted) * 100;

Any insight into the correct denominator?

Check your aggregation logic against the Genesys Cloud Service Level definition. The discrepancy arises because Service Level is not a simple ratio of total answered to total offered across the entire window. It is calculated per-interval based on whether the offer was answered within the specified threshold (e.g., 20 seconds) during that specific interval. Summing accepted and answered from raw 15-second intervals ignores the temporal constraint. The API returns serviceLevel as a pre-calculated metric precisely because the calculation requires comparing timeInQueue against serviceLevelGoal for each individual interaction, not just counting states. To replicate the UI accurately, you must use the /api/v2/analytics/queues/events/summary endpoint with the metrics parameter explicitly including serviceLevel. Do not attempt to derive SL% from accepted + answered. Instead, query the serviceLevel metric directly. Here is a curl example demonstrating the correct parameterization:

curl -X GET "https://{{hostname}}/api/v2/analytics/queues/events/summary?dateFrom=2023-10-01T00:00:00Z&dateTo=2023-10-02T00:00:00Z&interval=PT1H&metrics=serviceLevel,accepted,answered&groupBy=queueId" \
 -H "Authorization: Bearer {{access_token}}" \
 -H "Content-Type: application/json"

In your CI pipeline validation steps, ensure your Terraform genesyscloud_queue resource definition matches the serviceLevelGoal configured in the platform. If you are using terraform_cxascode to generate configurations, verify that the service_level block is explicitly defined. The serviceLevel metric in the response is already a percentage (0.0 to 1.0 or 0 to 100 depending on the API version context, usually 0-1 for raw analytics). If you sum accepted and answered, you are counting interactions that may have been answered after the SL threshold was breached, thus inflating your denominator without the corresponding numerator benefit in the SL calculation. The platform calculates SL as: (Interactions answered within threshold) / (Total interactions offered). The serviceLevel metric in the API response is the aggregate of this ratio across the requested time window, weighted by the number of offers. Using the pre-calculated metric is the only reliable method.

It depends, but generally you’re aggregating wrong.

1. Stop summing raw accepted across intervals; use the serviceLevel metric directly from the summary response.
2. If you must calculate manually, sum only answered where waitTime < threshold per interval.
3. Verify with this query:

query {
 queues(ids: ["queue-id"]) {
 analytics {
 events {
 summary(
 interval: "PT15S"
 dateFrom: "2023-10-01T00:00:00Z"
 dateTo: "2023-10-01T01:00:00Z"
 ) {
 serviceLevel {
 value
 }
 answered {
 value
 }
 }
 }
 }
 }
}