Vector Scripting Question

[mikej97204]

I have some VEC scripts that have been used in our Definity G3si since before I got here. I've been going through some of them as part of a clean up to streamline some of our call routing. One of our more used VECs looks to me like it has a dead end that might be causing some dropped calls rather than the calls staying in the queue until it is answered.


CALL VECTOR

Number: 4 Name: Tis High Pri
Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? n G3V4 Adv Route? y CINFO? y BSR? y Holidays? y

01 wait-time 0 secs hearing ringback
02 goto step 3 if available-agents in skill 12 > 0
03 queue-to skill 12 pri h
04 goto step 5 if available-agents in skill 21 > 0
05 queue-to skill 21 pri h
06 queue-to skill 12 pri h
07 announcement 7715 (this is a welcome ann)
08 announcement 7700 (this is a Please Hold ann)
09 wait-time 20 secs hearing music
10 goto step 11 if available-agents in skill 21 > 0
11 queue-to skill 21 pri h
12 announcement 7701 (this is a continue to hold ann)
13 wait-time 10 secs hearing music
14 goto step 10 if expected-wait for skill 12 pri h > 20
15 goto step 12 if available-agents in skill 12 < 1
16 stop

What it looks like to me is that if it gets past steps 14 and 15, the call will be dropped. We don't want that to happen of course. Should there be another goto back to step 12 (the please continue to hold ann) rather than a stop at the end? Or does the logic prevent it from ever getting to the stop at step 16?

Here is another example as well:

01 wait-time 0 secs hearing ringback
02 queue-to skill 12 pri h
03 announcement 7700 (Please Hold ann)
04 wait-time 30 secs hearing music
05 announcement 7701 (Please Continue to Hold ann)
06 wait-time 30 secs hearing music
07 goto step 5 if available-agents in skill 12 < 1
08 stop

On this one, it appears that if it can't queue to skill 12 in step 2 that it will loop through the continue to hold announcements until the number of agents in skill 12 are greater than 0 then it goes to the stop. Or is the scripting smart enough to send it to the queue rather than to step 8?

I understand scripting, but some of the Avaya VEC scripting is a bit confusing on what it's doing behind the scenes. We've been getting some dropped calls (the customer says they have not been dropping) and I was wondering if maybe some of our vectors were the cause.

Thanks

Mike

 

[TykeUK]

Personally the whole vector looks confusing to me. The goto steps won't be doing anything as they go to the next step anyway, also you shouldn't need to keep re-queing to skills. Once the call is queued to a skill it will continue to do so even if the call is queued to a 2nd skill until answered... my suggestion for the 1st vec would be...

01 wait-time 1 secs hearing ringback
02 queue-to skill 12 pri h
03 queue-to skill 21 pri h
04 announcement 7715 (this is a welcome ann)
05 announcement 7700 (Please Hold ann)
06 wait-time 20 secs hearing music
07 announcement 7701 (this is a continue to hold ann)
08 wait-time 10 secs hearing music
09 goto step 6 if unconditionally
10 stop


the 2nd vector for me should be...

01 wait-time 1 secs hearing ringback
02 queue-to skill 12 pri h
03 announcement 7700 (Please Hold ann)
04 wait-time 30 secs hearing music
05 announcement 7701 (Please Continue to Hold ann)
06 wait-time 30 secs hearing music
07 goto step 5 unconditionally
08 stop

 

[Zen216]

The way it looks, to me anyways, is the it queues to skill 12, if available agents is 0 then it goes back to queue step..
if available agents is > 0, then it would be sent to that agent, since it is in queue waiting for the next agent anywayws...

me personally, I probably would just change the step 15 on the first one to say, goto step 12 if unconditionally..

also, the queue-to skill 21 in step 11 seems redundant, since it was already queued to skill 21 in step 5, and following that logic, if (in step 10) there are available agents, the call was already n queue, so it should have been sent to the agent...

on a side note, I usually create two vectors that are identical, except the queue to step on the first one is to pri m, the secind vector queues to pri h, then I use the RONA field in the hunt group form to send the call to the second vector if it RONA's, so that way the call will get to the front of the queue...

 

[marcell55]

If a call is queued, it will not drop when it gets to the "stop" step. HOwever, if the call isn't queued, it will. The only reason a call would not queue based on the vector that you posted above is if the "Queue limit" on the Skill / Hunt Group is too low. If there are no more queue slots available, then the call will continue through vector processing, but never actually queue.

 

[mikej97204]

Thanks for the information and suggestions. These were created before I got here when we were set up a bit different. We use to have different agents in multiple skill sets so if the main skill set, 12, overflowed it went to the backup agents in skill set 21. If that one was full, it went back to 12 in hopes that someone was available by then.

That was when we had fewer agents, less call volume and more people wore multiple hats. Now that we have grown quit a bit there really is no overflow to 21. All the agents are 12 and 21 so if they are busy in 12 t hey are going to be busy in 21. So I see no reason to have more than one skill set identified, which is why I've started digging into our vectors to see what I can do to clean them up a bit.

Marcell, the Queue size is 100 for these skill sets. Since we rarely go over 10 calls waiting in queue under normal conditions, the call should stay in the queue that it goes into until it is answered or the caller hangs up. At least that is what I understand you are saying.

Thanks again. Now I just need to build a few test vectors and do some testing.

Mike