Genesys Cloud metric definitions explained: formulas, intervals and traps

Every metric in Genesys Cloud analytics follows a naming scheme published in the Developer Center. A name starting with t is a timer, a length of time such as talk time, and timers are stored in milliseconds. A name starting with n is a count, such as the number of interactions answered over the service level threshold. A name starting with o is an observation, the current state of the platform, such as how many interactions are waiting in a queue right now.

Timers come with statistics. For each interval, a timer such as tHandle returns a count of the interactions that had that timer, the minimum, the maximum and the sum. Averages in the performance views are built from those statistics: average handle time is the sum of tHandle divided by its count. Counts starting with n only have a count. Knowing this explains most of the confusion new teams meet, because a view column labelled average is always a sum divided by a count, and the question to ask is which count.

The names in the performance views are friendlier than the API names, and the mapping is not always obvious. The table below lists the metrics most teams use in their first weeks, with the name they will see in a view and what the platform actually measures.

Genesys Cloud gives each metric a single timestamp, and reports it in the interval in which that timestamp falls. The timestamp is set when the metric's calculation is complete. Speed of answer is recorded in the interval in which the agent answered. Handle time is recorded when the agent submits after-call work and the interaction is complete. Genesys's own example is a 45-minute call that starts in one half-hour and ends in the next: its handle time appears only in the second interval.

This explains a common complaint after go-live: the half-hour view shows more interactions handled than answered in one interval and fewer in the next, or a spike in handle time at the end of a busy period. Nothing is wrong. Answered and handled are counted at different moments, and long contacts carry their whole handle time into the interval in which they finish. Daily and weekly totals reconcile far better than half-hour intervals, so judge handle time on longer periods and use intervals for staffing and arrival patterns.

The same rule matters for after-call work. If an agent leaves an interaction in wrap-up, its handle time is not counted until wrap-up is submitted, and if wrap-up is left open over a break, that time is in the interaction's handle time. Coaching agents to submit wrap-up promptly, and setting sensible after-call work rules on each queue, improves both the agent experience and the accuracy of every handle time report.

Offered is the number of interactions routed into a queue for an agent to answer, and every offered interaction ends one of three ways: answered by an agent, abandoned by the customer, or flowed out. Answered increments for the agent who is first to connect, and an answer counts for the queue in which it happened. Abandoned means the customer disconnected while waiting, or the system disconnected the interaction, before an agent connected.

Flow-outs are the outcome teams most often misread. Genesys defines them as interactions that enter and leave a queue without being answered and without being disconnected: a transfer to voicemail, a callback, an in-queue flow that sends the customer to another queue or an external number after a set time, or a caller who chooses to leave the queue and return to the IVR. A rise in flow-outs is not a failure in itself if they are callbacks working as designed, but it is a sign of pressure on the queue, and the destination of the flow-out decides where the customer is counted next.

Short abandons are abandons under a threshold you set. Genesys Cloud uses the first column of the Abandon Insights intervals, set in Analytics settings, as the short abandon threshold, with a default of under six seconds. A customer who hangs up within a second or two of hearing a queue message has rarely waited at all, which is why many organisations leave short abandons out of service level and abandon reporting. Agree the threshold early and keep it stable, or month-on-month comparisons stop meaning anything.

Service level is the percentage of conversations answered within a target time. The target is set on each queue, separately for each channel: Genesys Cloud asks for a service level percentage and a target in seconds for voice, messaging, chat, email and callbacks. A conversation meets service level if the time it waited in queue before an agent answered is less than or equal to the target. The numerator is always conversations answered within target; what changes is the denominator.

Which conversations count in the denominator is set once for the organisation in Analytics settings: whether to include flow-outs, abandons and short abandons, and, for callbacks, whether to measure callback virtual wait and whether to include callback abandons and callbacks that could not reach the customer. When flow-outs or abandons are included they count as missing the target. These settings are the most common reason one organisation's service level cannot be compared with another's, and the most common reason a figure changes after someone edits a setting without telling anyone.

Genesys publishes a formula for each option. Note that the published formula for the short abandon option, (tAnswered − nOverSla) / (tAnswered + tAbandon − tShortAbandon), removes short abandons from the denominator, while the setting's wording speaks of including them. Before you rely on a figure for contracts or board reporting, confirm the behaviour in your own organisation by recalculating a sample day from the raw counts.

Average handle time in Genesys Cloud is the cumulative talk, hold and after-call work, plus dialling and contacting time on outbound calls, divided by the number of interactions handled. tHandle in the API is described the same way: the complete time an agent spent on an interaction. Contacts handled counts ACD and non-ACD interactions an agent was involved in, and increments when the interaction ends after after-call work.

The most common question we are asked after go-live is why average talk, average hold and average after-call work do not add up to average handle time. Each of them is averaged over a different count. Average hold is total hold time divided by the number of interactions that had a hold, not by all interactions; average after-call work is total after-call work divided by interactions that had after-call work; average talk is divided by interactions with talk time. Handle time is divided by all handled interactions. If one call in ten is held, the average hold is the average of that one call's holds, and adding it to the other averages overstates the total.

To break handle time into parts that do add up, divide each total by the same count, the number handled. That gives you the contribution of talk, hold and after-call work to every interaction, which is the view a team leader actually needs. Also watch tHeld against tHeldComplete and tTalk against tTalkComplete in the API: the complete variants describe the overall time for an interaction rather than an individual segment, and mixing the two in one report double counts or under counts.

In the performance views, Transfer counts interactions an agent answered in one queue and then transferred, blind or after a consult, and it counts for the queue in which the agent answered. Transfer % is transfers divided by interactions answered. Consult counts interactions where the agent answered and then consulted another participant, whether or not they completed the transfer, again for the queue where the interaction was answered.

The API counter nTransferred is wider: it counts transfer actions initiated by agents, blind and consult, even when the transfer does not complete. nBlindTransferred and nConsultTransferred separate the two kinds. If a data warehouse report and a performance view disagree on transfers, this is usually why, and a transferred interaction is also offered again to the receiving queue, where it can be answered, abandoned or flowed out like any other. Decide early whether your reports count transfer actions or transferred customers, and label them accordingly.

Genesys Cloud tracks two separate things about an agent. Presence is what the agent chooses, such as Available, Busy, Meal, Meeting, Training or Away, and organisations can add their own secondary presences. Routing status is set by the system when the agent is on queue and reflects what they are doing: Idle, ready for an interaction; Interacting, handling one; Communicating, on a non-ACD call that utilisation settings treat like an ACD call; Not Responding; and Off Queue. Agents cannot set routing status themselves.

Not Responding is applied when an agent is alerted for an interaction and does not answer within the queue's alerting timeout. While in that status the agent receives no new interactions. The Alert – No Answer metric is not a count of Not Responding events: it increments whenever an alert is not followed by an answer, on any conversation type. In the API, tAgentRoutingStatus, tSystemPresence and tOrganizationPresence give the time in each routing status, system presence and custom presence, which feed occupancy and adherence reporting.

Agent utilisation decides how many interactions an agent can be given at once. By default Genesys Cloud allows one call, one callback, one email, up to four chats, up to four messages and up to four workitems, and administrators decide which types can interrupt others; by default email can be interrupted. These settings change what the metrics mean. When an agent handles three messaging conversations at once, each conversation's handle time runs in parallel, so the sum of handle time can exceed the time the agent was logged in, and handle time per messaging conversation is not comparable with handle time per call.

Messaging has its own timers that describe the experience better than handle time does. tFirstEngagement is the time between the customer's first message and the first agent response; tFirstResponse is the time between the agent's session connecting and the agent's first message; tAgentResponseTime and tAverageAgentResponseTime describe how long customers wait for each reply, and tUserResponseTime and tAverageCustomerResponseTime describe how long agents wait for the customer. For asynchronous messaging, response times matter more to customers than total handle time, and they are the measures we recommend for messaging service levels and coaching.

Workforce management uses the same service level definition and the same Analytics settings as the performance views, so a forecast and an actual can be compared like for like. Occupancy is interacting time divided by on-queue time: predicted interacting time over scheduled on-queue time in the plan, and actual interacting time over actual on-queue time on the day. Because the denominator is on-queue time, occupancy says nothing about time spent off queue in meetings, training or after-call work outside the queue.

Real-time adherence compares each agent's current presence and routing status with their scheduled activity, using a mapping of presences to activity categories. An agent scheduled for on-queue work is adherent when on queue and Idle, Interacting or Communicating. Historical adherence and conformance report the same comparison after the event. Historical shrinkage compares planned and actual non-interacting time, by activity category, and is the most useful single view for finding out why measured occupancy comes in below plan.

Observation metrics describe now, not an interval. oWaiting is the number of interactions waiting in a queue, oInteracting the number being handled, oLongestWaiting the longest current wait, and oOnQueueUsers, oOffQueueUsers and oUserRoutingStatuses describe the agents. oServiceLevel for a queue carries a target, a ratio, a numerator and a denominator. Wallboards and real-time dashboards are built on these, and they answer a different question from the half-hour aggregates.

A wallboard showing a current service level and a daily report showing a different one are usually both right: one is a rolling or point-in-time calculation and the other is a completed interval. Explain the difference to team leaders before go-live, show them which tile is live and which is historical, and you will avoid most of the early disputes about whose number is correct.

A conversation aggregate query for a day of voice queue metrics in half-hour intervals

POST /api/v2/analytics/conversations/aggregates/query
Content-Type: application/json

{
  "interval": "2026-11-02T00:00:00.000Z/2026-11-03T00:00:00.000Z",
  "granularity": "PT30M",
  "groupBy": ["queueId"],
  "metrics": ["nOffered", "tAnswered", "tAbandon", "tShortAbandon",
              "tFlowOut", "nOverSla", "tHandle", "tTalk", "tHeld", "tAcw"],
  "filter": {
    "type": "and",
    "predicates": [{"dimension": "mediaType", "value": "voice"}]
  }
}

Almost every reporting dispute after a Genesys Cloud go-live comes down to one of a handful of causes. Work through the list below before assuming the data is wrong, and write the answers into your reporting standards so the next person does not have to rediscover them. At QVCCS we recommend agreeing these reporting standards before go-live, so the first month's reports are trusted rather than argued over.

1. Interval rule: is one figure counted when answered and the other when handled?
2. Period and time zone: do both reports cover exactly the same start and end, in the same time zone?
3. Filters: same queues, media types, directions, wrap-up codes and users?
4. Service level settings: were flow-outs, abandons or short abandons included differently, or changed in Analytics settings?
5. Short abandon threshold: has the first Abandon Insights interval been edited?
6. Averages: is each average divided by the same count?
7. Concurrency: are messaging or email handle times being added together?
8. Transfers: is the report counting transfer actions or transferred customers?
9. Live against historical: is one figure an observation and the other a completed interval?