I run a helpdesk with a few teams, one tasked with frontline support and the others are available as backup should that team be busy or unavailable.
I have queues set up where incoming calls go to the first team, which rings for a certain time period, then the call is moved to the second queue
e.g.
100 Frontline (ring for 60 sec)
101 Overflow
If the Frontline queue is empty/unavailable, it moves to the Overflow immediately. All of this is working as expected; my problem is with the reporting.
Because we get our share of spam-ish type calls, and/or wrong numbers, a certain percentage of calls drop quickly, during the beginning of the recorded message on 100 Frontline - so when reporting on the Queue Stats, I have the "Exclude calls dropped before" enabled for 5 seconds, as I do not consider these to be "missed" by my team.
However this can lead to some stupid math: when the 100 Frontline queue is unattended (late in the day) calls bounce through that queue and into the overflow queue in under the 5 secs boundary. This means in the Queue Stats at the end of the day it's possible for the missed call count for queue 100 Frontline to be less than the number of calls handed to the the 101 Overflow queue - it is as if calls have appeared out of no where. It also means that the total of Answered calls across both groups can be higher than the number of calls that 100 Frontline team received.
eg. 100 calls come in a day, routing through the frontline queue. 5 are robocalls that drop within 5 secs. 10 end up failing over to the second queue, 3 of which happen when the first queue is unattended so are "abandoned" in less than 5 secs. This means the report (set to exclude the 5sec drop calls) shows Frontline receiving 92 calls with 7 abandoned, and the Overflow team answering 10 calls - no matter how I do the math here I can't see the truth: that 95 calls (100 - 5 spam calls) were received and answered.
A second case of bad math is if the call reaches the timeout on 100 Frontline (60 secs) and fails over to the the 101 Overflow, but then the call hangs up within 5 secs of that shift. This does not show up as a missed call for the Overflow team - it is as if the call didn't make the transfer between teams.
I'm only interested in excluding calls that actually drop with 5 secs of calling us - from the callers perspective, not from the perspective of the queues. Am I approaching this reporting wrong, or do I just have to live with the reports including the 5 sec dropped/spam calls if I want the other numbers to be true?
I have queues set up where incoming calls go to the first team, which rings for a certain time period, then the call is moved to the second queue
e.g.
100 Frontline (ring for 60 sec)
101 Overflow
If the Frontline queue is empty/unavailable, it moves to the Overflow immediately. All of this is working as expected; my problem is with the reporting.
Because we get our share of spam-ish type calls, and/or wrong numbers, a certain percentage of calls drop quickly, during the beginning of the recorded message on 100 Frontline - so when reporting on the Queue Stats, I have the "Exclude calls dropped before" enabled for 5 seconds, as I do not consider these to be "missed" by my team.
However this can lead to some stupid math: when the 100 Frontline queue is unattended (late in the day) calls bounce through that queue and into the overflow queue in under the 5 secs boundary. This means in the Queue Stats at the end of the day it's possible for the missed call count for queue 100 Frontline to be less than the number of calls handed to the the 101 Overflow queue - it is as if calls have appeared out of no where. It also means that the total of Answered calls across both groups can be higher than the number of calls that 100 Frontline team received.
eg. 100 calls come in a day, routing through the frontline queue. 5 are robocalls that drop within 5 secs. 10 end up failing over to the second queue, 3 of which happen when the first queue is unattended so are "abandoned" in less than 5 secs. This means the report (set to exclude the 5sec drop calls) shows Frontline receiving 92 calls with 7 abandoned, and the Overflow team answering 10 calls - no matter how I do the math here I can't see the truth: that 95 calls (100 - 5 spam calls) were received and answered.
A second case of bad math is if the call reaches the timeout on 100 Frontline (60 secs) and fails over to the the 101 Overflow, but then the call hangs up within 5 secs of that shift. This does not show up as a missed call for the Overflow team - it is as if the call didn't make the transfer between teams.
I'm only interested in excluding calls that actually drop with 5 secs of calling us - from the callers perspective, not from the perspective of the queues. Am I approaching this reporting wrong, or do I just have to live with the reports including the 5 sec dropped/spam calls if I want the other numbers to be true?
