Tens of Thousands of Inbound Calls logged in a Month... to one person.

Hi There!

We have a couple of people experiencing this issue. About 2 to be exact, where their call history shows what the screenshot provided shows. Their inbound calls are logged thousands of times, despite it being just one call at the moment. Their disposition is typically "No Answer from User (user alerted)" and "User Busy" when this occurs.

I verified that their call queue is not setup in such a weird way that calls might get looped or something similar and that a couple of the numbers are legitimate customers, NOT spam numbers. I have not verified all of the numbers involved, but we have seen about 5-6 of the same numbers coming up in this way.

As far as I can tell, the users do not complain about getting inundated with these calls. It seems to me to be something weird in how the calls are logged, but to be honest I have no clue where to even begin since the setup seems to be as it should be. I should note that at least one of the users does not use a soft phone, opting to stick to using their cell phone exclusively. They racked up like 37,000 inbound calls on their own. The other guy about 5000.

I want to avoid re-assigning the extensions if possible, but am willing to do so if that helps. Has anyone come across this? If so, how did you resolve it? I plan to submit a case with GoTo, but I have seen their response times and figure this might be a better first step instead. 😬

Thanks in advanced!

Find more posts tagged with

Accepted answers

alexnuno

Just an update. According to support, apparently users have to use Pause Codes and log out and back into queues. I will be advising my users to try and do so, but this doesn't seem to be a very intuitive or user friendly solution since DnD is such a core expected feature. I was really hoping GoTo would be able to just change how the reports handle the call data and/or how the system handles the call scenario. I will inquire about this.

"Hi Alex,

Thank you for this information. The fact that they do not use pause codes neither log out or back is what is causing problems on the reports. The system identifies as if they're busy when on DND and sends the calls multiple times to their extensions as it always hits voicemail. We do not recommend this practice.

Please get them to use appropriate pause codes and to log out after every shift and let me know if this issue persists after this change. Bellow you will find links for how to use pause codes and how to login and log out:

How do I manage pause reasons? https://support.goto.com/connect/help/how-do-i-manage-pause-reasons
How do I pause or unpause queue calls? https://support.goto.com/connect/help/how-do-i-pause-or-unpause-queue-calls
How do I log in and out of a call queue? https://support.goto.com/connect/help/how-do-i-log-in-and-out-of-a-call-queue

Thank you,
Lili | Support Engineer"

All comments

alexnuno

How do I manage pause reasons? https://support.goto.com/connect/help/how-do-i-manage-pause-reasons
How do I pause or unpause queue calls? https://support.goto.com/connect/help/how-do-i-pause-or-unpause-queue-calls
How do I log in and out of a call queue? https://support.goto.com/connect/help/how-do-i-log-in-and-out-of-a-call-queue

Thank you,
Lili | Support Engineer"

alexnuno

Hi mkeaton!

Thanks or the additional information and apologies for the late response, I hope all has been going well for you! Your input is infinitely appreciated.

The user did confirm that they use the App's built in DND feature when they don't want to receive work calls.... which makes sense, though I did advise that if they can do a different workflow to avoid work calls to please do so.

The call queue has definitely already been set to "Never" ring active agents, so thats another thing ruled out and I just confirmed the logging errors are still occurring. /:

@GlennD Would there happen to be any updates or other suggestions on the GoTo side?

Thank you both for your help!

mkeaton

Here is a few other things to check...

Another weird bug they told us about was... Agents that are logged into a queue shouldn't have on do not disturb, it will also make toooons of missed calls. the mobile app does have that option, and so does the softphone so might check that.

Here is what ours looked like as well while we were troubleshooting these issues:

Another thing to make sure is set up right, is the "ring active agents" option in the queue settings - basically that needs to be set to never or they will get calls incoming to their line when they are already on a call.

Ring active agents — Choose when agents actively on a call can receive additional incoming calls:

Never — The user will never receive an additional call when their line is busy.
On personal calls — The user can only receive an additional call when they are currently on a non-queue call.
On all calls — The user can receive an additional call regardless of the type of call they are currently on.

Hopefully one of these helps! if not I hope GoTo can figure it out!! Have wonderful weekend.

alexnuno

How interesting! Thanks for the information and suggestion @mkeaton! I am going through that side of troubleshooting with the users now and hope it will help too. So far "Call waiting" seems to be a feature that is enabled by default on the carrier side, as there is no option to enable/disable anywhere in their phone settings or carrier app settings. They are both on iPhones. There's an option with Verizon to temporarily disable it by dialing *70 before calling a number, which I hope will help, as it should re-enable and maybe matter? We will see.

mkeaton

Hello!

We have seen this as well. We found that the users having the feature "Call waiting" turned off would get thousands of missed calls, for some reason this causes the call to get stuck on the Agent. The best work around was to turn call waiting back on, then disable the sound notification since its in the users ear and its very distracting. Once you turn this call waiting back on the system will figure out that the agent is already on a call and move on to the next one as it should.

This worked for us, hopefully it will work for you!

GlennD

Hi @alexnuno, welcome to the community.

This is certainly an odd one and something I have not seen reported before. I've shared it with the team and hopefully, we'll have a solution for you early next week.