Quick answerSet the target as time from flag to first human touch, not time to resolution, and separate it by urgency tier: under two minutes for a customer actively waiting in the conversation, under fifteen minutes for a flagged issue the agent parked for async follow-up. Track the metric continuously, not as a monthly average, since a target that holds on average while missing badly during peak hours is invisible until a customer complains. Treat a missed target as its own alert, distinct from the staffing model that is supposed to prevent it from happening in the first place. ---
A queue-time target is not the same as a staffing model
Our post on how to staff AI agent on-call without 24/7 engineering coverage covers who is on the hook to respond and when shifts cover the gap. That post answers who; this one answers how fast, once someone is on the hook. A well-staffed rotation can still miss a fast queue-time target if nobody actually measures how long a flagged conversation sits waiting, so the SLA needs its own number and its own dashboard, not an assumption that good staffing automatically produces good speed.
Why the number has to split by urgency, not average
A single blended average across every escalation type hides the failure mode that actually matters to customers: the live, waiting-in-chat case where every extra minute is felt directly. Split the target into at least two tiers, live-synchronous and async-follow-up, and report them separately. A team that hits a comfortable blended average while badly missing the live-tier target has a real problem the dashboard is actively hiding.
What the human receives has to match the speed you promise
A fast queue-time target is worthless if the human who picks up the conversation then spends five minutes reconstructing context before responding, since the customer experiences that reconstruction time as part of the same wait. The context package covered in what context a human should see the instant an AI agent escalates has to be ready the moment the SLA clock would otherwise be satisfied, not built after the human opens the ticket.
Treat a miss as a distinct alert, not a monthly footnote
Downtime and SLA methodology for the agent's own uptime, covered in how to define what counts as downtime for your AI agent's SLA, uses a similar discipline: define the metric precisely, alert on it in real time, and do not let a monthly rollup average away the moments customers actually noticed. Apply the same real-time alerting to the time-to-human number specifically, since a queue-time miss during a spike is exactly the kind of thing a monthly average is built to hide.
FAQ
Should the SLA clock start when the agent decides to escalate or when the human actually opens the conversation?
Start it the moment the agent's escalation decision is logged, not when a human happens to open it, since the gap between those two events is exactly what the SLA is meant to measure and shrink.
Does an async ticket need the same tight target as a live chat?
No, and forcing the same tight number onto both tiers usually just trains teams to game the async queue rather than actually improving the live-tier response time that customers feel most.