Recalculate SLA metric when ticket priority is changed
Feature Request Summary:
If a ticket's priority is changed, any SLA metrics associated with that ticket should recalculate, even if the SLA metric has been completed.
Description/Use Cases:
Often times an incorrect Priority will be set on a ticket and later changed to more accurately reflect actual ticket priority. A ticket may automatically be set to an Urgent or High priority ticket, but after further review it is later determined to be Normal or Low priority (or vice versa) and it will not recalculate first response time, requester wait time (resolution time), etc if the metric has already been met. We have triggers in place that set the Priority of a ticket based on various scenarios and we often err on the side of caution and set ticket priorities to Urgent or High to ensure they're reviewed right away. If the ticket priority isn't changed prior to that metric failing (often times Agents are hesitant to change a ticket priority, especially downgrading, so typically it isn't until a ticket is in the solved status before it's changed) then there is no way to go back and recalculate that metric.
Business impact of limitation or missing feature:
It's reflecting an inaccurate view of Support SLA Achievement rate, which is especially detrimental if we have to provide service credits to customers for breached SLAs. We work in a fast paced Support environment and relying on a human to catch that the Priority field should be changed before it's too late. There's absolutely no wiggle room in recalculating a SLA metric once it's been completed.
-
Hi Jamie,
We appreciate your input! Our Product Managers actively monitor our feedback threads, and conversations with high user engagement ultimately get flagged by the team for roadmap planning. Thanks!
-
+1 on this - recalculating the SLA when priority changes, would be super helpful.
Vous devez vous connecter pour laisser un commentaire.
2 Commentaires