At a glance
- An AI-to-human handoff needs an explicit SLA policy — continue, pause, restart, or a separate human-only target — not whatever the help desk happens to default to.
- Continuing the customer-facing clock keeps the promise honest; we consider restarting it at handoff the option most likely to look deceptive to the customer.
- Reporting the AI stage and the human stage as two numbers, not one blended figure, is what lets leadership see where time actually goes.
- Help desks such as Zendesk and Freshdesk already expose reply and resolution timers and an escalation field; the open question is which policy governs them, not whether they can be tracked.
- This is a policy and reporting framework only — it makes no claim that adding an AI stage improves resolution time.
Why AI handoffs break SLA reporting
An SLA policy designed for human-only support treats a ticket as having one owner and one clock, running from the moment a customer reaches out until someone resolves the request. An AI agent that answers first and escalates only some tickets breaks that assumption: the ticket now has two owners and, implicitly, two timers, and nothing in that kind of policy says how those timers relate to each other.
In this article, first response time means the time from ticket creation to the first reply a customer receives. If the AI's reply counts, the metric looks fast even when the AI never resolves anything and the customer's real wait only starts once a person picks the ticket up. If it doesn't count, the human's first response time is measured against a clock already running before they saw the ticket, and looks artificially slow.
- A headline SLA that looks healthy while the human stage is actually breaching, because a fast AI acknowledgment gets averaged in with the slower escalated cases.
- A human-agent performance number that punishes agents for time the AI agent spent working the ticket before handoff.
- A customer who experiences one continuous wait but sees it reported as two figures that don't add up to what they actually lived through.
None of this is a defect in the platform. Zendesk's API reference defines an SLA policy as a combination of criteria and assigned metric targets attached to a ticket's priority [1]. It says nothing on its own about whether an AI stage and a human stage should share one clock or run on two — that's a policy decision for your support team to make explicitly, not a default to inherit by accident.
The SLA policy decision table
There are four realistic policies for what happens to the clock at an AI-to-human handoff: continue it unchanged, pause it while the ticket sits with the AI agent, restart it when a human picks the ticket up, or run two separate SLA targets, one for the AI stage and one for the human stage. Each trades a fair customer-facing number against a clean way to measure the human team.
| Policy option | What happens to the clock | Customer impact | Reporting consequence |
|---|---|---|---|
| Continue | The original clock keeps running through the AI stage and the human stage without a break. | Matches what the customer actually experienced: the promise is measured from their first contact, not from whichever stage looks best. | Blends AI-stage and human-stage time into one number, so a slow AI turn and a slow human turn look identical in the headline metric. |
| Pause | Time with the AI agent is excluded from the target, and only person-facing time counts toward it. | Fair to the human agent, but a customer who waited a long time in the AI stage still sees an "on-time" badge, which can read as generous to the team and unclear to the customer. | Isolates human performance cleanly, but only if the AI stage has its own separate timer — otherwise nobody is accountable for how long that stage took. |
| Restart | The clock resets to zero the moment a human takes the ticket, as if the conversation began there. | The riskiest option for customer trust: a customer who already waited through a slow AI stage sees the countdown start over as though their wait hadn't happened. | Makes the customer-facing number look like a human-only number, because the time the customer already spent in the AI stage is dropped from it entirely. |
| Separate human SLA | Two independent targets exist from the start: one for the AI agent's first reply, one for the first human reply after an escalation. | Nothing is hidden, and the two targets can be added back together into a single customer-facing promise if you want one. | Gives the clearest view of both stages, provided leadership reads both numbers rather than only the more flattering one. |
For most teams, we recommend continuing the customer-facing clock while reporting the human stage separately underneath it, rather than choosing pause or restart outright. That keeps the customer-facing number honest and still gives leadership a clean view of the human stage.
Metric definitions for both stages
Reporting both stages well starts with naming the metrics precisely, because "SLA" alone isn't a metric, it's a policy applied to metrics. Two response-time measures matter most: how long the ticket took to get its first reply, and how long it took to get its first reply after a human took over. Zendesk's SLA metric list, for example, already names more than one separate timer [1].
- First response time Time from ticket creation to the first reply the customer receives, whichever stage sent it.
- Time to first human reply A second, separately tracked timer that starts at the handoff event and ends at the first reply from a person.
- Time in AI stage Time from ticket creation to the handoff event, for tickets that escalate to a person. This is the separate timer the Pause option above needs before it can isolate human performance cleanly.
- Next reply time and total resolution time Time between a customer's message and the next reply, and time from creation to resolution; both are separate named metrics in Zendesk's SLA metric list [1], not a single combined figure.
- Escalation flag Freshdesk's ticket record, for example, has an is_escalated field, set to true if the ticket has been escalated for any reason, separate from a breach-specific fr_escalated field [2]. It's a general escalation marker, not one documented specifically for an AI-to-human handoff, so use a field like this, or a dedicated tag, to mark the handoff explicitly.
- Escalated share Tickets that reached a person divided by all tickets the AI agent handled. If your help desk doesn't report this directly, calculate it from the escalation flag and total ticket volume.
A genuine, on-policy AI reply should count toward first response time; a bare acknowledgment shouldn't. Track the human stage's own first-reply timer regardless, so a fast AI reply never masks a slow human one.
Configuring it in a help desk
If your help desk already records a handoff event, this is a policy decision plus configuration, not new tooling. The steps below don't depend on a particular platform.
- Define the handoff event
Decide exactly what event marks the handoff, a status change, reassignment, or escalation action, so every downstream timer and flag has one trigger to key off.
- Pick one policy from the decision table
Choose continue, pause, restart, or separate targets, and write it down as a policy your team agreed to, not whatever your default configuration happens to do.
- Turn on an escalation flag
Mark a ticket as escalated independently of whether any target was breached, and use that flag to separate handed-off tickets in every report, not only the ones that missed their target.
- Set business hours once, deliberately
Decide whether targets run on business hours or calendar hours, and apply that choice consistently across both stages so the two numbers stay comparable.
- Report the human stage on its own
Whatever you do to the customer-facing clock, keep a separate view of the human stage's own response and resolution times, so a policy choice at the top never hides its real performance.
Reporting to leadership
Present two numbers side by side, not one blended figure: the customer-facing SLA from whichever policy you chose, and the human-stage metric, reported separately regardless. A blended percentage can look healthy while the human stage is breaching badly, since averaging a fast AI turn with a slow human turn describes neither stage accurately.
Break the escalation flag out as its own reporting line: the share of tickets that reached a human, plus that subset's first-human-reply and resolution times, since that's what leadership needs to staff against.
When this doesn't apply
This framework assumes a ticket genuinely changes hands: some tickets are handled entirely by the AI agent, and others are escalated to a person partway through. A few situations sit outside it:
- Every ticket already goes to a human from the start, with AI only assisting the agent rather than answering first. There's no handoff event to key a policy off, so a standard single-clock SLA is simpler and correct.
- Your help desk doesn't record a reassignment or escalation distinctly from a normal reply. Fix that tracking gap first; none of the four policies above can be applied without a clear handoff event to trigger them.
- Every AI-handled ticket is fully resolved without reaching a person. There's no second stage to report, and the decision table doesn't apply until escalations start happening.
- Contract or policy language already commits you to a specific SLA definition. Treat that as fixed and adapt the reporting around it, and check with compliance or counsel before changing what a contractual SLA measures.
Frequently asked questions
Does the SLA reset when an AI agent escalates to a human?
Not automatically, and it shouldn't be a default you inherit by accident. There's no single default: you choose whether the clock continues through both stages, pauses during the AI stage, restarts at handoff, or splits into a separate human-only target. Pick one on purpose; don't assume restarting is simply what your platform does.
Should the AI stage count toward first response time?
Usually yes, if the AI's reply is a genuine, on-policy answer rather than a bare acknowledgment, since the customer got real information even if a person gets involved afterward. Track the human stage's own first-reply timer separately regardless, so a fast AI reply can never mask a slow human one.
How do you report SLAs for AI and human stages?
Report two numbers side by side rather than one blended figure: the customer-facing SLA built from whichever clock policy you chose, and the human stage's own response and resolution times, reported separately regardless of that choice. Break out the share of tickets that reached a human, too, since that subset is what support leadership needs to staff against.
What SLA should a human have after an AI handoff?
There's no universal figure; it depends on what you already promise customers and how your team is staffed. We recommend a tighter first-reply target for escalated tickets than for tickets a person owns from the start, because an escalated ticket has already failed a simpler resolution path and needs prompt attention.
How do customers experience a restarted SLA?
Often as if their wait didn't count. A customer who spent time with the AI agent and then got escalated sees the response-time countdown start over at handoff, even though their own wait began earlier. We consider that the policy option most likely to look deceptive from the customer's side, whatever the internal reporting reasons for choosing it.
Related reading
- See customer support escalation for how the underlying triage-and-handoff workflow is designed.
- Our article on customer support automation with escalation covers that workflow at more length; this page covers only the SLA clock.
- Human-in-the-loop AI governance covers how to set the limits that decide when an AI agent escalates.
- For how a human review-and-approval step is designed into an AI workflow generally, see document review with human approval.
- The AI agent implementation service describes how a setup like this is scoped, tested, and handed over.
Sources
- Zendesk, "SLA Policies" (Ticketing API reference) (accessed 2026-09-30)
- Freshworks, "Tickets" (Freshdesk API) (accessed 2026-09-30)
More in Customer and revenue operations
Utility Customer Billing Exception Handling Automation
Utility customer billing exception handling automation: a workflow table from meter data to the customer message, plus what an agent flags and a rep decides.
Utilities and Energy CompaniesHow to Automate Insurance Eligibility Verification Without Losing the Exceptions
How to automate insurance eligibility verification: an exception table and a cost-per-check formula for what 271 responses leave for a person.
Why Round-Robin Lead Assignment Goes Uneven (and How to Fix It)
A failure catalogue for round-robin lead assignment going uneven: six causes, their symptoms, fixes, and a monthly fairness audit method to run.