Plan requirement
| Subscription | Suite Growth or higher, Support Professional or higher |
| Access | Admin |
A ticket breaching while you wait on somebody else has three causes, and the first one is almost always it.
Why did my ticket breach while we were waiting?
- A ticket breaches while parked waiting on a supplier or another team.
- The clock keeps running on a ticket where the customer owes you an answer.
- Breach figures that do not match what the team experienced.
Resolution steps
1. The target does not pause at all
The commonest cause by a long way, and the one that surprises people: first reply time, next reply time and periodic update do not pause on any ticket status. Not on pending, not on on-hold. Total resolution time only stops when the ticket is solved.
There is no setting to change that. What decides which waiting counts is the target you picked. Agent work time counts only New and Open, so it stops for both pending and on-hold, and it is the honest measure of time the ball was in your court. Requester wait time and pausable update stop for pending only.
2. The policy uses calendar hours
Then evenings and weekends count. A ticket sitting overnight has used eight hours of its budget with nobody working.
3. It is a resolution target, not a reply target
Resolution time generally keeps counting through everything. If you set one, waiting is included by design, which is why resolution targets are hard to meet honestly.
The two fixes
- Turn on on-hold and use it. Then teach the team the distinction: pending is the customer, on-hold is anyone else. Without it, nothing downstream can tell the two kinds of waiting apart.
- Add a target that excludes the waiting, which means agent work time next to your reply targets rather than instead of them.
Doing only one of those does not work. On-hold nothing measures changes nothing, and agent work time on a desk where every ticket sits in Open is the same number as before.
What you cannot do is make a first reply target ignore a wait. If the promise to the customer is a fast first answer, then a supplier delay genuinely does eat into it, and the fix is the promise, not the clock.
Comments
0 comments
Article is closed for comments.