Calls going straight to VM Box when it shouldn't

[assistu]

I have an IPO 406 (3.0.44) with VMPro. Calls come in on 12 loop-start CO lines and go directly to a hunt group that has one member, no voicemail and no queuing. This one member (extension 200) has 13 call-appr buttons. Call Waiting is ON in the hunt group AND the station. The "no answer" timeout in the hunt group is 999 seconds (16.5 minutes). The idea is that this person answers all calls until the place closes at which time she presses the "night-service" button. This one phone is the only phone that has a "night-service" button for the hunt group. Night service for the hunt-group is another hunt-group with no members, no queuing, and goes straight to VM at which time the caller gets an auto-attendant. Inside the auto-attendant the caller can press zero or wait and will go to a general mailbox (it's a "leave mail" for station 200). The "voicemail on" check-box is NOT checked on the station or in the hunt-group.

Now, everything works fine (call flow, night service), but I’m getting one anomaly. Somehow outside calls are going straight to the general mailbox (ext. 200) during the day and NOT ringing on the phone first. Not all calls, just a few. Most calls are ringing on her desk like they should, but a few are somehow getting into her mailbox. I’ve verified that she is not activating DND and she is not turning on “Night-Service”. We have spoken to many of the people who left messages and they say they are not speaking with a live person or even getting the Auto-Attendant, but instead are just going straight to the general mailbox (extension 200, NOT the auto-attendant) where they leave a message. This has been consistent with all the people we’ve asked so far. They are all just getting the mailbox for 200. I have been unable to duplicate the situation, but have verified that the messages are being left during the day and that the receptionist has not been turning the night service on.

Does anyone have an insight? Should I upgrade to the new 3.1.59 and see if this corrects the problem? Is there some issue with multiple incoming calls at the same time that could be causing this? Should the “no answer” timeout on the station form be set for 999 secs too?

Any help is very much appreciated.

 

[brainey73]

I have found that in large call volumes, it takes 2 seconds for vmpro to see your user as available and send the next call to you. If you are on the phone, you will recieve a call waiting but if you hang up at the same time it tries to send a call, the 2 sec. rule applies. I was able to get tech support to validate this but with no fix. The only way around this is to turn on queue for the group. It was as if the wrap up timer (default 2 seconds) comes into play but changing it did not apply. The same thing happens if you use the vmpro client to record a wav file by selecting telephony handset and entering the extension #. If the phone has not been idle for 2 seconds, a message will pop and tell you that user was unavailable.

 

[CarGoSki]

Perhaps you can build the operators extension with line appearances and VM built as AA.

 

[sizbut]

God, I'm glad I don't work for you guys. First I'm expected to juggle up to 13 simultaneous calls and now you don't even want me to draw breath between calls.

 

[assistu]

=

I'd like to add that no more than 2 or 3 calls have ever been ringing at once. 3 is super busy. I just put 14 c/a's there just incase that was the problem. 99.9% of the time it's one call at a time.

 

[sizbut]

phew!!!! at least I can get to sip my coffee then - you're not such a bad boss afterall.