Voicemail Queuing

[amartin2006]

Hi all, a customer has come to me with a problem where their queuing message doesn't function on the group there main number hit's. The site is a lower and upper school, with two ip office's installed, one at each site. The two IP offices share a central voicemail. The main site's voicemail is set up 'PC', the secondary site setup up 'Line'. On the main site the queuing message works as it should, but nothing on the secondary site. Ideally the custom would like the same queing message at both site's. Going to the file where the queing messages are saved I tried to copy, paste and rename the queuing message in line with the appropriate group, nothing happened. The default queuing doesn't even function. I've checked in call status and the call does appear to queue, be grateful for any help on this matter. Thanks

 

[disturbedone]

It's a "feature"!!

That's the way it's supposed to work. Centralized Voicemail Pro only supports certain features and queuing for a remote system is not one of them. It specifically lists this in the Engineer's Toolkit.

Can you imaging the amount of VoIP traffic there would be if you hada big call centre with dozens of queues with hundreds of callers all getting messages every 20 seconds? This is the reason it doesn't work. However, I have a vague memory of hearing that they might do something about it in the future.

 

[amartin2006]

Thanks disturbedone. Would there be a way of maybe forwarding the calls to the upper school which could play the queuing group and then when a line becomes available forwarding it back? I can understand it fully but when a customer see's something working on 1 site and not on another it can be hard explaining thats just the way it is!!

 

[disturbedone]

Well you could get messy and overflow the group to a group which had a virtual member which was call forwarded to a short code which played a voicemail greeting at the main site but it's left the group and is no longer queueing. The VMPro node could play a greeting and then xfer back to the original group at the remote site but it starts from scratch and will be at the end of the queue.

The queueing isn't true queuing. At the main site it will queue even if the agents aren't busy, they just don't answer. So in the scenario I described it would stop ringing the phones and disappear until after hearing the greeting and being xferred back. If they agents are truely busy then they won't notice. But they could get annoyed if they just didn't get to answer the phone in time and it disappears.

Draw the customer a picture, show the 2 physically different sites. Put the VMPro clearly one one site. Draw a call coming in and going across the link then explain the it can't go back and forth across the link every 20sec to get the queue greeting. This will explain it. They may not like it but it will explain it.

 

[Shine52]

I ran into this before myself. Disturbedone is definately right. I eventually moved the VM PC to the site that was most important for the queue message to be played. Big time bummer. License codes and all sorts of BS had to be moved. I also think that any work around would NOT PUT THE CALLER BACK INTO THEIR PROPER QUEUE POSITION.

Figure it out damn-it!

 

[amartin2006]

Thanks a lot for the replies pass this information on to the customer and hope they take it well!

 

[sizbut]

Grind your teeth, bite your tongue and wait for 4.0. Announcements to waiting calls have been totally separated from queuing (so the caller can now hear announcements while the call is ringing around the possible hunt group members) and are available to all in the SCN.

 

[big70]

The thing is if you don,t tell it before you sell it then tell it now

Greets Peter