YundaDeskThe number most likely to start an argument at a monthly review is resolution time. The support lead says 4 hours average. The owner pulls raw export data and gets 11 hours. Neither one is wrong — they’re just using different definitions. One counted the 6 hours the customer was asleep; the other didn’t. Ticket handling time looks like a simple metric until you try to use it for SLAs, bonuses, or real decisions, and then the lack of a shared definition turns it into noise.
Where does the clock actually start
Most teams default to “the moment the customer sends the first message” as the starting point, but that hides a real disagreement: if a message lands in a website widget and the AI hasn’t looked at it yet, has the clock started? The stricter and more honest approach is that the clock starts the moment the message enters the system, regardless of when anyone (or the AI) actually looks at it — because that reflects what the customer actually experienced, not when the team noticed the problem.
A second, easily missed starting-point issue is multi-touch contact. A customer messages once on Instagram DM, gets no reply, then repeats the same question by email. Is that one issue or two separate requests? If each channel is timed on its own, resolution time gets artificially deflated — each channel looks “fast” in isolation, but the customer was waiting on an answer to the same question the whole time. This is exactly why routing every channel into one shared customer profile matters; see what an omnichannel inbox actually solves.
Resolution Time Done Right: the industry baseline behind the metric
Does wait time count — this is where numbers get gamed the easiest
A common move is subtracting the time a customer takes to reply from resolution time. An agent asks “could you share your order number?” and the customer replies two hours later — does that gap count against the team?
Both definitions are defensible, but you have to pick one and write it down:
| Definition | What it measures | Best used for |
|---|---|---|
| Wall clock | From first question to resolution, no deductions | How long the customer actually felt they waited |
| Net handling time | Wait time on the customer’s end is subtracted | Team efficiency, isolated from customer delay |
Both are worth tracking, but you can’t report only one without labeling it — especially not by quietly using net handling time when reporting up (it looks faster) while never mentioning it when explaining delays to a customer. The honest approach is to keep both numbers and label each clearly as “what the team controls” versus “what the customer actually felt.”
Reopened tickets: same issue, or a new clock
A customer asked about a shipping delay three days ago. The agent said “we’re on it,” and the ticket got marked resolved. Three days later the customer messages again asking if it’s actually been fixed. Is that a reopen of the original ticket, or does the clock start fresh?
Resolution time and First Contact Resolution are a closely related pair — a high reopen rate usually means resolution time is being chopped up on the report to look better than it is. For a deeper breakdown of how these two metrics relate, see what resolution time actually measures.
AI-only resolutions and human handoffs shouldn’t share one average
This is the most overlooked definition question, and it has the biggest effect on the report: conversations the AI closes on its own should not be averaged together with conversations that only got resolved after a human handoff.
- AI-only resolution: a customer asks about shipping timelines or return policy, the AI pulls the answer from the knowledge base, answers directly, and the customer doesn’t follow up. These conversations typically resolve in minutes or even seconds. Averaging them together with human-handled conversations badly dilutes the real time complex issues take, making the overall number look great while complex issues still take exactly as long as they always did.
- Human-handoff resolution: conversations where the AI couldn’t answer confidently, or the customer asked for a person, and an agent took over from there. These should be tracked separately, since they reflect the actual work the team has to put in.
Reporting these two separately is the only way to see where AI support is genuinely helping — not by dragging the blended average down, but by making the handoff bucket itself shrink over time as handoffs get cleaner and agents stop having to ask customers to repeat themselves. For how AI and human agents split responsibility, see where the line sits between AI-first and human-backed support.
Approval-gated conversations shouldn’t count as “overdue”
Refunds, compensation, and price changes always require human approval in YundaDesk — the AI never executes them automatically. That means these conversations will naturally run longer than a pure knowledge-base answer, not because anyone is slow, but because approval is supposed to take time: verifying the amount, checking the order, weighing the risk.
If these conversations get held to the same SLA target as routine questions, one of two bad things happens: the team looks like it’s constantly missing deadlines, or someone starts cutting corners on approval to keep the numbers clean. Neither outcome is what you want. The better approach is to set a separate resolution-time baseline for approval-gated conversations and label the report clearly: “includes a human-approval step, excluded from standard overdue tracking.”
Before you argue about the target, agree on the definition
Before debating what the “right” resolution time number should be, get the team aligned on these first:
- Clock start: when the message enters the system, or when it’s first seen
- Wait time: track both wall clock and net handling time, and label each
- Reopened tickets: same issue means the clock keeps running from the first ask, no reset
- AI-only resolutions vs. human handoffs: reported separately, never blended into one average
- Approval-gated conversations: a separate baseline, not the standard SLA
Once these definitions are settled, the owner and the support lead are finally looking at the same number — and the review meeting can actually talk about what to improve, instead of spending the first half hour arguing over whether they’re even measuring the same thing.
Resolution time itself isn’t the problem — teams quietly defining it however’s convenient for them is. Pin down the clock start, the wait time rule, reopen handling, and the AI/human split, and the number becomes something worth deciding on. Calculate it precisely without doing that, and all you’ve built is very scientific-looking noise.