Support quality can look steady in aggregate while repeat work is already building in one corner of the queue.
That usually shows up in reopen rate. One owner can keep seeing tickets come back after “Solved” while the team-wide quality picture still looks acceptable. Other queues stay clean enough to keep the blended metric stable, so the local issue remains hidden until customers and managers start feeling the drag directly.
This is one of the easiest ways to miss a real quality regression. The dashboard says “fine.” The repeat work says otherwise.
Why the blended quality metric can hide it
Blended reopen rate tells you whether the whole system is producing repeat work. It does not tell you where that repeat work starts.
If one assignee owns fewer tickets overall, they can have a much worse reopen pattern without moving the top-line number very much. That is especially true when:
- the owner handles more complex or ambiguous tickets
- one specialist queue closes work too early
- one owner inherits more escalations or exception handling
- the rest of the team keeps resolution quality stable
From a distance, quality looks fine. Up close, one queue keeps recreating the same work.
Why this usually happens
When one assignee hides most reopen risk, the cause is often structural before it is personal.
Tickets are being solved too early
The owner may be optimizing for speed and closing before the customer is fully done.
One issue type is naturally messy
Some owners inherit billing, integrations, or policy issues that are much more likely to come back.
Handoff quality breaks down
The ticket leaves one queue with weak context, incomplete next steps, or poor expectation-setting.
Customer follow-up loops are weak
If one owner does not confirm resolution clearly, the customer is more likely to come back and reopen the case.
What to review first
If quality looks stable overall but one owner keeps recreating work, review:
- Zendesk Reopen Rate by Assignee Report
- Ticket Reopen Rate
- Zendesk Resolution Time Report
- support metrics dashboard
Those views help you answer:
- is the issue really isolated to one owner?
- is one ticket type causing most of the repeat work?
- is the owner solving too early to protect speed metrics?
- is this a stable pattern or a short-lived spike?
The trap in treating it like a performance score
One owner with higher reopen risk does not automatically mean one underperforming employee.
If the same person gets the hardest tickets, the noisiest customers, or the weakest workflows, the metric will reflect that. Support ops gets better results when it asks:
“Why does this owner queue create more repeat work than the rest of the system?”
That question produces fixes. The shallow question “who is bad at support?” usually does not.
What good looks like
A healthy team does not require every owner to have identical reopen rates.
What matters is that:
- differences are understandable
- high-reopen queues are visible
- poor patterns do not last for weeks without explanation
- repeat work is investigated with ticket mix and workflow context
Some variation is normal. Hidden concentration is not.
What to do when the pattern is real
If one assignee consistently carries more reopen risk:
- Review ticket tags, channels, and priority mix.
- Check whether the queue is closing too early to protect speed.
- Compare with Zendesk CSAT Report and Zendesk Resolution Time Report.
- Tighten expectation-setting, follow-up habits, and solve criteria.
- Coach the workflow after you understand the structural cause.
Quality improves fastest when support ops treats reopens as a signal about system design, not just individual behavior.
The main takeaway
When one assignee can hide most reopen risk even when support quality looks stable, the blended quality metric is too broad to be an early warning system.
Keep the top-line view for leadership, but inspect owner-level reopen reporting to see where repeat work is actually being created. If customers keep coming back in one queue, trust that local signal before the system-wide quality metric finally reacts.