Multilevel IVRs and impatient callers

Status
Not open for further replies.

TigerTech

Forum User
Joined
May 1, 2018
Messages
55
Reaction score
9
This past summer we retired our old phone system, which had a single-level IVR configured so that it took only one press for a caller to reach a live person. Upon installing 3CX this past summer we decided to go to a two level system for better call routing, but in one way it's made things worse. A caller may press 5, for example, but when the system doesn't respond quickly enough (there's about a 4 second delay) they will press 5 again. That takes them to the person at 5-5, who keeps getting calls that should have gone to 5-1, 5-2, or whatever, had the caller just waited to hear the second level menu. We can't fix impatient callers. Is there anything we can adjust in 3CX to make this problem less likely to occur?
 
It is not typical for it to take 4-5 seconds to transfer a call. It should be nearly instant. I suggest you look at the resources of your 3CX server to ensure you have sufficient hardware.
 
It is not typical for it to take 4-5 seconds to transfer a call. It should be nearly instant. I suggest you look at the resources of your 3CX server to ensure you have sufficient hardware.

Thank you for your reply. I watched the 3CX dashboard for a short time, including while I called in and pressed option 5. Disk usage is at 7% (104 GB free), memory at about 32% (2.6 GB free), and CPU topped out at 8% while I was watching. I believe these numbers are fairly typical for our system, If so it doesn't seem to be a problem of resources, does it? This is the Debian appliance installation running on VMware.
 

Thanks, I have already searched and found that thread. I took away two things from that...

First, I could shave one second off the time by changing the IVR_INTERDIGIT_TIMEOUT from its default of 2 seconds to 1 second. However that would be done "at our own risk". Does this ominous warning simply refer to making it too difficult for a caller to dial an extension?

Second, one person fixed the problem by moving from a Linux installation to Windows. However he reported delays as long as 48 seconds. I'm not sure why moving to Windows would help or whether it could even be worthwhile when we're only talking about a second or two.

On another note, I've looked at a couple of our IVR recordings, and I see about a 1-second silence at the beginnings. I'll remove those and see whether it cuts down on the problem.

In the end I doubt that there is any surefire fix for this. It seems that we have to strike a balance between giving callers enough time to dial an extension and not taking too long that they get impatient waiting for an IVR menu. Am I right?
 
First, I could shave one second off the time by changing the IVR_INTERDIGIT_TIMEOUT from its default of 2 seconds to 1 second. However that would be done "at our own risk". Does this ominous warning simply refer to making it too difficult for a caller to dial an extension?

Yes, it is a risk if you also allow people to dial an entire extension number.

In the end I doubt that there is any surefire fix for this. It seems that we have to strike a balance between giving callers enough time to dial an extension and not taking too long that they get impatient waiting for an IVR menu. Am I right?

Exactly. An option , number of digits to accept, per IVR, might be worth suggesting in the Ideas forum. Depending on extension digit length, and what you want people to do in the IVR (single digits only), it might be an option that would be usefull.
 
  • Like
Reactions: TigerTech
Thanks for confirming that. Do we have the option to turn off extension dialing and use IVRs only? If so how would I do that, and would IVR call transfers happen essentially instantly upon the button press?
 
I think I have enough info now to present options to the boss. Thanks!
 
Status
Not open for further replies.

Forum statistics

Threads
111,901
Messages
589,635
Members
164,768
Latest member
Eagle Man