Vector Question 1

[wpetilli]

What should be the behavior of the below steps in this vector? The 'route-to' #'s are VDN's that associate to a different vector. Within those vectors there are 'route-to' steps that send the call to another CM. Part of what I'm looking to find out is if the call would ever reach step 19-23.

14 goto step 18 if staffed-agents in skill 1st = 0
15 queue-to skill 1st pri m
16 announcement 3794
17 wait-time 10 secs hearing silence
18 route-to number 3459 with cov n if unconditionally
19 announcement 3794
20 wait-time 5 secs hearing silence
21 route-to number 3466 with cov n if unconditionally
22 announcement 3794
23 route-to number 3732 with cov y if unconditionally
24 stop

 

[joe2938]

no at step 18 it would route to that vdn 3459 but of course I am not able to see steps 1-13

 

[cgogan13]

Unless there are commands in steps 1-13 that goto steps 19-23, calls will not reach beyond step 18 (based on what we can see here).

 

[wpetilli]

I thought using 'cov n if unconditionally' is supposed to hold on to that call unlike 'cov y', which is like a blind transfer.

 

[joe2938]

still going to route to step 18

 

[cgogan13]

No, "cov n unconditionally" that means send the call unconditionally, just like "cov y unconditionally". The only difference is con y will send the call to an end users voice mail if that's where 3459 goes, and cov n will not terminate to voice mail

What are you trying to do?

 

[wpetilli]

I want the call to still flow through the table even after that 'route-to' step. I'm using LAR to another CM, so while that agent search is in process I still would want the call to still look down the original vector.

 

[cgogan13]

once you use the Route to, the call is gone. I'm not familiar with LAR, can you use a check command to queue the call to another skill while still handling it in this vector with LAR?

 

[wpetilli]

Not sure.. I'd have to look more into it.

 

[Ronster]

18 route-to number 3459 with cov n if unconditionally

The route-to step 18 will send to VDN 3459.
As coverage is no it will move on to step 19 if 3459 is unavailable.

Since 3459 is a VDN it should always be available BUT if the vector that 3459 points to plays busytone (maybe because there are no agents available in a particular skill) then it will return to the sending vector and move on to step 19.

e.g
VDN 3459
Vector

01 goto step    4             if staffed-agents   in skill 1st          >  0
02 busy
03 stop
04 queue-to     skill 1st  pri m

_______________________________________________________________
I stay away from the telephone if at all possible.
Lee Trevino

 

[Ronster]

There is more to LAR than just using a route-to step.
You need to setup the Location and polling VDN's to test the wait time at the location before sending the calls.
Use commands CONSIDER and REPLY-BEST


_______________________________________________________________
I stay away from the telephone if at all possible.
Lee Trevino

 

[wpetilli]

After reading up on a bunch of documentation I don't believe we fit LAR as we want the called center to be the first choice to answer those calls and only traverse the other center if the primary isn't able.

@Ronster -- you reference using a BUSY step. Does the caller hear that busy tone and then suddenly as the call continues through the original vector eventually then hear announcements (if in the flow) or then the ring when an agent becomes avail? Busy is kind of taboo here..

In the example distributed call flow examples I've found the 'route to' step that goes to the other CM CC is an e.164#, which would traverse the PSTN. In my case I'm sending my 'route to' step to a 4 digit VDN# that's traversing an h.323 trunk over our internal WAN, via AAR. Is that an issue?

Also, I'm not setup w/BSR. I can get to the administration pages of it, but wasn't sure if there are any licensing requirements to use that.

 

[Ronster]

OK, what you have is :

14 goto step 18 if staffed-agents in skill 1st = 0
15 queue-to skill 1st pri m
16 announcement 3794
17 wait-time 10 secs hearing silence
18 route-to number 3459 with cov n if unconditionally

At step 14 you are checking to see if no-one is logged in and if so, send to 3459.
If you only want to send to 3459 when no one is available in the skill then do:

14 goto step    18            if available-agents in skill 1st          =  0
15 queue-to     skill 1st  pri m
16 announcement 10023
17 wait-time    30  secs hearing ringback
18 goto step    14            if unconditionally
19 stop
20 route-to     number 3459             with cov n if unconditionally

So the call will only route off PBX if no-one is available in the skill.

I don't think the busytone method will work for you going off-net.

Yes, you will need a licence to use BSR.


_______________________________________________________________
Everyone seems to have a very short attention... etc.

 

[wpetilli]

in your example what does step 18 do? 'goto step 14 if unconditionally'

 

[joe2938]

it forces it back into the queue

 

[Ronster]

Step 14 thru 18 is the queueing loop.
The call will stay there until it is answered or dropped.

You can put an out-of-hours check in there to route calls away if they hold on until closing time or a check for an emergency skill etc so calls are not stuck in the loop if you evacuate the call centre.

_______________________________________________________________
Everyone seems to have a very short attention... etc.

 

[montyzummer]

If CM recieves busy from the far end it will hang onto the call if cov is set to N , so you are looking for a cause code 17 or 486 with sip , then it will continue to process the call

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[john8lee]

what if you used a collect step here at 16
16 announcement 3794
17 wait-time 10 secs hearing silence
18 route-to number 3459 with cov n if unconditionally
change the unconditional to digit and tell that caller to press the respective digit to goto 3459 otherwise continue to hold.
also, not a fan of 10 seconds of silence, but thats just me

 

[wpetilli]

I did test the disconnect step at the remote CM and the call did continue down the flow in the originating vector. Thanks

Agree, the 10 second wait step is way too long.

When doing a check on 'available agents in skill x = 0'. if the agents are all logged in but on active calls will that call queue or does it treat them as if they are not available? We did set the HG's to allow the agents to take 2 calls... not sure if that matter. The agents are set to be able to answer 2 calls, if that makes a difference.

 

[wpetilli]

In scenarios such as mine where the call is using 'route-to' steps to another CM CC, when the call hits the other CM and looks for available agents and there is one and it hits a RONA condition, what's the logical way to handle that? Should I have a different HG/skill setup that I make those agents part of for those cross CM calls where RONA can go directly to VM or back to the original CM?