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.
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.
Por favor, entrar para comentar.