We are relying heavily on this SLA target for queue management and there is a crack in the logic that a number of tickets are falling through, which is causing upset customers when their tickets are not responded to in a timely manner. The scenario is this (directly from the help text):
The Pausable update metric uses the agent's public comment on a new or existing ticket as a starting point, only if that ticket is not in the Pending status. If an agent adds a public comment and marks the ticket as Pending in the same event, the metric will not be applied to the ticket until the ticket is first submitted in a New, Open, or On-hold status with a public comment. The metric will apply once the ticket is set to Pending. Once a comment is present, the metric pauses in the Pending status and resumes in a non-pending status with either no comment or a private comment from an agent.
That action described in bold is an incredibly common action. Here is the scenario:
A customer puts in a ticket with very little information. When the agent starts looking at the ticket, they identify immediately they need more information to help the customer. They add a public comment asking for more information and set the ticket to Pending status.
My Request - Either of the following would cover this gap:
- When the ticket is placed in Pending with a Public comment by the agent, the Pausible SLA target is applied and then immediately paused.
- When the requestor updates the ticket (moving it back to Open status), this action applies the Pausible update target.
I LOVE the Pausible Update SLA feature, but this gap has caused us to rethink using it. If we abandon it, the next best solution is using the Next Reply Time SLA and requiring agents to ask for updates on tickets that have not received responses, which can be time consuming.