Calculating Avg. Response Time After Escalation

[JayMehta]

Avg. Ticket Response Time per department is a metric that like many others we too monitor continuously and it's fairly straight forward to measure this. However, our helpdesk has three different departments, Technical Support (let's say LI), LII Support and LIII Support for three different teams. New tickets by default are always opened in the LI queue, these tickets can then be moved to the two other queues either through an automated escalation rule or manually by a staff member from the LI team.

Now, we measure the average response time for the last 50 tickets. For the LI queue, this is accurate. However, for our LII and LIII teams, this is metric is not accurate since it takes into account the time a ticket has spent in the previous (LI) queue before it came into LII and hence the response time per department for LII and LIII is not an accurate KPI to be measured here.

I am having a tough time figuring this out, I am relying on SQL queries and some simple maths to do this and it works for the first queue. Can anyone point me in the right direction or share some ideas on how to do this accurately for the LII and LIII queue taking into account the escalation?

Any help is appreciated, thanks.

[Kian]

You should also consider working hours, holydays and weekends 😜 otherwise avg. response time make absolutely no sense. Let's say your office closes al 18:00 and opens at 09:00. A ticket opened at 18:01 will have an avg. response time greater than 14h 59m before you had a chance to read it.

Anyway I think you can get what you need by looking at tblticketlog table that logs all activities. You should focus on tblticketlog.action LIKE "Department changed to {YOUR_LII_DEPARTMENT}%" and tblticketlog.date.

[JayMehta]

Thanks for your reply, yes someone pointed me out to the tblticketlog table.

Since we are operational 24x7, the office closures are not something that we need to account for.