A stable resolution time trend can make support look healthier than it really is.
That is especially true when the slowdown is concentrated around one owner. A specialist assignee, escalation lead, or senior generalist can start taking much longer to close tickets while the team-wide time-to-close metric stays mostly unchanged. Everyone else keeps the blended result calm enough that the local delay looks smaller than it is.
Customers in that queue do not experience the team average. They experience the owner who has their ticket.
Why the top-line metric can stay flat
Blended resolution time tells you what the system is doing overall. It does not tell you where the drag lives.
If one assignee owns a smaller share of total tickets, they can slow down noticeably without moving the top-line number very much. That is even more likely when:
- other owners still close routine work quickly
- the slower owner handles more complex or escalated tickets
- long-running tickets sit in one specialist queue
- the slow queue has weak backup coverage
From a leadership view, the system looks fine. From a support ops view, one owner queue is quietly becoming the place where work stays open.
Why this usually happens
When one assignee slows down first, the cause is often structural before it is personal.
Specialist ownership expands
The trusted expert gradually becomes the destination for anything risky, vague, or politically sensitive. Resolution time rises because ticket complexity rises, not because the person suddenly forgot how to work.
Handoffs create friction
One owner may depend on another team, an approval step, or product context before the ticket can truly close.
Queue habits drift
Sometimes the issue is local workflow. One person may follow up less often, hold more “waiting” tickets, or keep tickets open longer than the rest of the team.
The blended metric hides all of it
If the rest of the queue is healthy, the global number stays calm long enough for the local delay to become a real customer experience problem.
What to review before calling it a capacity problem
If one owner looks slow while the team trend stays flat, review:
- Zendesk Resolution Time by Assignee Report
- Zendesk Tickets per Agent Report
- Zendesk Time in Status Report
- support metrics dashboard
Those views help you answer:
- is the owner slow because the work is harder?
- is the owner waiting too long in one status?
- is the queue overloaded or just badly designed?
- is the pattern real or just a low-volume edge case?
The trap in trusting the blended trend
When team-wide time to close stays flat, it is easy to assume the queue is under control.
But customers do not experience the blended trend. They experience the ticket owner. If one queue is slowing down, the customer experience in that lane is already worse even if the company-wide metric still looks acceptable.
That is why local queue views matter. They show where the experience is changing before the executive KPI does.
What good looks like
A healthy support team does not require every owner to resolve tickets at exactly the same speed.
What matters is that:
- differences are explainable
- slower owners are slow for a reason, not by accident
- trend changes are visible
- the same owner is not repeatedly becoming the queue bottleneck
If one assignee is always slower and nobody can explain why, that is the real problem.
What to do when one owner keeps slowing down
If the same assignee repeatedly carries the worst resolution trend:
- Review ticket mix before assuming underperformance.
- Check for rising time in one status or repeated handoffs.
- Look for one channel, issue type, or priority band causing most of the delay.
- Decide whether the fix is routing, process cleanup, documentation, or staffing.
- Recheck the trend weekly until the owner queue stabilizes.
Support ops improves faster when it treats resolution drag as a workflow question instead of a vague productivity complaint.
The main takeaway
When one assignee can slow resolution even when team-wide time to close stays flat, the global metric is too broad to be an early warning system.
Keep the top-line number for leadership, but use owner-level reporting to find where the real friction lives. If one queue feels slower than the dashboard suggests, trust the local signal and inspect the owner lane before the rest of the system starts showing the same delay.