Set them on the whole piece of work, from request to outcome, including the time an action sits waiting for a person. Drafts produced in seconds and left in a queue for a day meet no useful target. Every speed target needs a quality floor next to it, and a rule for what happens when either is missed.
Why not just measure the agent's response time?
Because customers and internal teams experience the outcome, not the agent. The agent's own speed is rarely the bottleneck. The held queue, the escalation route and the availability of connected systems usually are.
A level set only on agent speed also creates the wrong pressure. If the team is judged on how quickly items leave the agent, the easy fix is to raise its depth or to approve held items faster than anyone can read them. Neither improves service. Both raise risk.
What should a service level for agent work cover?
| Measure | What it tells you | Who owns it |
|---|---|---|
| Time from request to outcome, by route | Whether the customer or colleague got what they needed in time | Process owner |
| Time an item waits in the held queue | Whether reviewers are keeping up | Team lead for reviewers |
| Time from escalation to a person picking it up | Whether hard cases are being stranded | Team lead |
| Quality floor: edit rate or error rate on a sample | Whether speed is being bought with mistakes | Process owner |
| Agent and connected system availability | Whether the agent was able to work | Platform or IT owner |
| Fallback trigger | When work routes to people instead | Operations lead |
Split the first row by route. Items the agent completes within its bounds, items held for approval and items escalated have different natural speeds. One blended number hides a held queue that is quietly ageing.
How do you set the levels?
- Process owner: starts from the customer or business need, not from what the agent can do. If a regulation or a contract sets a deadline, that is the outer limit. Evidence: the stated requirement.
- Analyst: measures current performance with people only, per route. Evidence: a baseline.
- Agent, depth 1 or 2: runs in shadow or draft while the analyst measures hold and escalation rates. Evidence: filed verdicts with timestamps.
- Process owner: sets targets per route and the quality floor alongside them. Evidence: a signed service level, versioned.
- Platform owner: wires breaches into your incident process, for example by connecting the agent to your IT service management platform. Evidence: a ticket for each breach.
What does that look like for a real queue?
Say a card issuer's disputes team must acknowledge every dispute within one working day and resolve simple ones within ten. An agent reads each dispute, gathers the transaction and merchant data, and at depth 3 sends acknowledgements within approved wording. Resolution decisions stay at depth 2.
The team sets three targets: acknowledgements within two hours, held resolution drafts reviewed within one working day, and escalated cases picked up within four hours. Beside them sits a quality floor: in a weekly sample, reviewers must not need to change the outcome of more than a small, fixed number of drafts. If the agent is unavailable for more than an hour, acknowledgements route to people with a template.
After a month, the held queue meets its target but the edit rate on resolutions creeps up. The owner holds depth where it is, rather than letting speed win. That decision is the reason the quality floor exists.
Which controls keep service levels from distorting behaviour?
- No target on approval speed alone. Pair it with sampling of approved items.
- Separate targets per route, reported separately.
- Breaches trigger review, not depth increases. A missed target is never a reason to give the agent more authority.
- A written fallback that sends work to people when the agent or a connected system is down.
For a deeper treatment of the work itself, see setting service levels for work done by an AI agent, and for the contractual side, what a service level agreement is. The rest of the deployment sequence is in deploying an AI agent.
Questions people ask
Should agent work have tighter targets than work done by people?
For items the agent completes alone, usually yes, because it works around the clock. For held and escalated items, targets depend on reviewer capacity, which has not changed.
Do service levels belong in a vendor contract?
Platform availability and support response belong there. Outcome targets for your process belong to you, because you set the depth and staff the review.
What happens if the agent meets every target but complaints rise?
Then the targets measure the wrong thing. Add a complaint or rework measure to the quality floor and review recent filed verdicts for a pattern.