Is this possible?? Queue callers before VMpro 1

[TeltronMan]

Hey I have an intriguing question for my IP Office designers. Simply… Can you put callers into a Hunt Group Queue if all VM pro ports used? I have a customer running a winter weatherization radio ad; in the event of high traffic volume can I place overflow callers into queue while the system waits for a VM port to open. Obviously Atech is going to recommend additional ports; but I would like to solidify my IP Office design in the event of “the perfect storm”!

 

[intrigrant]

The question is not so intriguing as me... putting calls in queue has nothing to do with the availability of VM channels. The calls in the queue can be presented queue messages by VM but if at the time the caller should be presented a queue message but there are no channels available then the caller stays in the queue and will not get a queue message.
A new customer will not notice the lack of queue messageg and a known customer may think "at last, that annoying voice has finally broke down..." but the calls are processed by IP Office as if there is no problem with vm channels

 

[Greybeard191]

a bigger issue will be that potentially the announcements will be sucking up all the ports leaving nothing else for VM, AA prompts, call recording etc.

Unless you reserve VM ports for certain things, it's open season on ports. Intrigrant is correct, the incoming caller will likely not notice the lack of queuing announcements... callers and users are far more likely to notice a lack of AA announcements, or a lack of VM access etc.

GB

 

[Westi]

if you synchronize the queued messages all callers will use the same vm port and share the announcement (per queue and still queued greeting per huntgroup)
That means that you have enough ports as they only have the initial greeting and after that they are all on the same timing.

Caveat is that there are no breakouts from these messages so you can't offer them to leave a message by pressing a button or go to reception etc. and the timing is slightly off for the greetings.

Joe W.

FHandw, ACSS (SME), ACIS (SME)

http://convergednetworks.ca

“Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.”

 

[TexasBear]

When the OP mentions weather, I immediately think of time/weather announcements. If a caller has called with the express intention of reaching a menu of messages to select one to listen to, can the system queue the caller with nice hold music/message until a port is available to allow this? (Don't mean to hijack the thread, I just wonder if this is what the OP is asking, or maybe I'm being a bonehead.)

 

[TeltronMan]

TexasBear
Thank you.

 

[VoIPP]

If the incoming call route is set to go to AutoAttendant and all VM ports are used (or VM Server is down) then if a fallback huntgroup is configured in the ICR then the calls will flow to the fallback destination.

Depending how you setup the fallback group it can ring until someone picks up or you can have the call rerouted backup to the AutoAttendant after it times out if VM ports are available.

If the fallback group times out and tries to forward the call to the AutoAttendant and there are no VM ports available then I'm not sure what happens; will the call die or will it remain in the group? Maybe someone else knows the answer that question.

 

[VoIPP]

After further contemplation...

The fallback huntgroup could be setup with a "Still Queued" VM PRO action to redirect to AA module. If no VM ports are available then call will remain in the queue and will retry at the "Replay 2nd announcement interval" or every 15 seconds by default.