Your bot asks eight questions before it escalates to a human. The customer answers them. The transcript lands in the agent's queue.
The agent opens the ticket. Reads the conversation. Reads it again to understand the context they've just been handed. Figures out where things stand. Then types their first reply.
That reading time — two to five minutes, depending on the length of the bot conversation — does not appear anywhere in Zendesk's reporting. The SLA clock starts when the ticket is created or assigned. The handle time metric starts when the agent opens the ticket. Neither one captures the read time before first reply that every agent spends, every time, on every bot-escalated ticket.
For teams with significant bot volume, this creates a systematic undercount in two of the metrics ops managers care most about: handle time and SLA first-reply performance. The numbers look better than the work actually was. And nobody flagged it, because the platform doesn't have a way to flag it.
Why this is a Zendesk measurement gap, not an agent behaviour problem
It helps to understand exactly what Zendesk measures and what it doesn't.
First reply time is calculated from ticket creation to the timestamp of the first public agent comment. This seems reasonable — until you account for the fact that on a bot-escalated ticket, the "first reply" clock started running before the agent ever knew the ticket existed. The bot handled the intake. The time the bot spent asking questions is included in the first-reply window. The time the agent spent reading the transcript before replying is included in the same window. Zendesk has no mechanism to distinguish pre-escalation bot time from agent read time.
Handle time — where it's tracked — typically measures time-in-ticket across agent sessions. This can capture some reading time if the agent opens the ticket and stays in it, but it doesn't specifically timestamp the period between ticket assignment and first keypress. There's no "agent read time" field in Zendesk's native data model.
The gap in practice: An agent on a bot-escalated ticket spends 3 minutes reading, then 4 minutes writing a reply, then closes the ticket. Zendesk records approximately 7 minutes of handle time. But the SLA first-reply metric may show something different depending on when the ticket was assigned versus when the agent opened it versus when the bot conversation concluded. The actual agent contribution — reading time plus reply time — isn't cleanly isolated.
What ops managers have built to measure this
This gap is well understood by experienced support ops teams. The r/Zendesk thread where this problem surfaced included several ops managers describing their workarounds.
The most common approach: custom timestamp-delta visualisers. These are typically built in Zendesk Explore or pulled via the API into a BI tool. The setup involves capturing two timestamps — when the ticket was assigned to a human agent, and when the first agent comment was posted — and calculating the delta. That delta approximates agent read time plus reply time, stripped of the bot intake period.
Building this requires Zendesk Explore access (an additional cost on most plans), data engineering time, and ongoing maintenance when Zendesk's data model or API schema changes. Teams that have built it consider it essential. Teams that haven't are operating on handle time data that systematically understates agent workload.
A smaller number of teams have built proxy metrics: tracking average bot conversation length in turns, estimating a per-turn read time based on spot-checking, and applying that as a correction factor to reported handle times. This is manual, inexact, and depends on an ops manager who understands the gap well enough to have invented the workaround.
Why this matters for workload distribution
The practical consequence of untracked read time isn't just inaccurate reporting. It's that agent workload calculations are systematically off for agents who handle high bot-escalation volume.
An agent handling 30 bot-escalated tickets per day at an average 3 minutes of read time per ticket is doing 90 minutes of work that doesn't appear in their handle time metrics. Compared to an agent handling 30 direct-submission tickets with no bot preamble, the first agent looks equally productive — or, if the bot conversations tend to be longer, even faster — when in fact they're doing significantly more reading per ticket.
Workload distribution decisions made from handle time data alone will systematically underallocate the agents handling the most bot-escalated volume. They'll look fine on paper until they're overloaded.
The honest measurement problem
There's no easy fix here that lives inside Zendesk's native tooling. The read time gap is structural — the platform's data model doesn't have a field for it, and the SLA framework wasn't designed around bot-augmented workflows.
What ops managers can do is understand where the gap is largest. Bot-heavy queues. Agents with high escalation volume. Products where the bot conversation tends to be long — multiple clarifying questions, complex intake flows, high-context technical issues.
For those queues and those agents, assume handle time is understated, probably by 15–30% depending on bot conversation length. Workload scoring based on ticket count or raw handle time will misrepresent the actual burden.
Scoring by risk weight — combining ticket urgency, assignment age, SLA proximity, and inactivity — gives a more complete picture of which agents are actually under the most load, independent of handle time measurement gaps. That's a different frame than "who has the most open tickets" or "who's handling the most volume." It captures the agents sitting on the hardest tickets regardless of how Zendesk counts the time.