Vectoring

[BIS]

Hi All,
This has been driving me mad for while. How can I route a call out of vectoring (Audix/cov rem etc) after a certain queue time? Suppose a call has queued for X minutes, interupted by an announcement every 30 second or so, and I then want it to flow out. From a vectoring perspective, the only solution I can see is a whole lot of "wait-time 30 seconds hearing annXXXX then music". Using conversant, each step would be doubled ("wait-time 30 secs hearing music", followed by a converse-on step). If I want the call to flow out after a specific time, I will need to calculate the exact duration of the announcements, multiply them all up and add the music time. I would also be using a disproportionate amount of vector steps. Using "go-to if oldest-call-wait" will not solve the problem as this could cause newly queued call to flow out. I am looking for a command along the line "go-to step X if this-call-has-been-in-queue-for 10 mins"
Any ideas, perhaps in newer releases (currently I'm on 8.2) ?

 

[pbxman]

We use 8 wait-time steps in our main vector (adding up to a maximum of 15 min in queue), and then use an announcement saying you need to call back, or leave a message. If they dont do anything, a "go to step xx if unconditionally" points to the end of our vector saying "route-to number xxxx" ...which sends them to voicemail.

here's a copy of one of our main vectors starting at step 12:
12 announcement 4034
13 wait-time 180 secs hearing music
14 announcement 4034
15 wait-time 180 secs hearing music
16 announcement 4034
17 wait-time 180 secs hearing music
18 announcement 4034
19 wait-time 180 secs hearing music
20 announcement 4034
21 wait-time 25 secs hearing music
22 announcement 4033
23 goto step 32 if unconditionally
24 wait-time 0 secs hearing silence
xx
xx
xx
..
32 route-to number 4099 with cov y if unconditionally


..works like a charm. Hope this helps!

 

[BIS]

pbxman, thanks.
I am aware of this setup. However if you need to interrupt the system music every 30 seconds for 10 minutes, you will quickly end up using 2 vectors or more.If you are tight for capacity this can be a waste. What I was looking for was a simple command to avoid that. As far as I can tell, avaya hasn't thought of this scenario...

 

[clausen]

I wonder if you could put in a step
goto step x if expected-wait for skill x pri m is > 300
you could put this several wait steps down to route out

Chris

 

[pbxman]

sorry BIS - i mis-read your initial question, and posted a ton of wait-steps!
Either way - if you have the room, you can put as many wait-steps as you can in the vector, and just increase the timing between music/announcements. Ours used to be every 60 seconds, and now they're 180 seconds (3 min.)
But - youre right, BIS..Avaya really has no command to do exactly what you want. Clausen's idea is closest to what you want to do. I don't see any other way do get that information.
Also, depending on your setup - you may not be able to effectively use the expected-wait feature in the switch.

 

[Jolagues]

BIS- Just FYI I have release 9.0 and there is still no command to do exactly what you are looking to do. José B. Olagues
Telephony Administrator
NACIO Systems

 

[BIS]

Thank you all !
Maybe we will need to inform avaya on what we want. It would be nice if they had a feedback forum or something to that extent.
Expected wait time is not an option (and I really don't trust it either), as this will calculate queue-time, not total wait time. Thanks for all your feedback.

 

[Warper]

The only thing you need is a CTI solution made for such a situation - it's quite easy to calculate the time of call processing using any CTI.
Although there is no normal vector command.

 

[MKU]

The reason why they prolly don't have this feature is that they want to sell Conversants to calculate the waiting time and MUOH with integrated messages (like the "please wait" or "buy our product now!!!" messages). Adding the mentioned feature would create a complete standard vectoring environment so there won't be any reasons for customers to buy the expected wait time feature...


M.