Vector Call Queue Priority 4

[mariner31]

Hello All,

Im trying to attempt to explain an unfortunate 50minute wait in our call centre. The phone tech is away but I have some experience on the definity switch.

10. I queue calls to a Skill.
20. Then I collect digits after an announcement advising customers to press 1 to stay in the queue or else they will
go to a cover path (voicemail box).
30. If the caller does press 1 to stay queued to the skill I use a goto step pointing back to line 10 above.

My question is. Will that call then be placed at the back of the queue? Or will it still retain its length of wait and still be prioritised at the front of the queue accordinly?

Regards,

Pete

 

[mariner31]

Here is the actual vectoring.


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

01 wait-time 2 secs hearing ringback
02 queue-to skill 1 pri m
03 wait-time 420 secs hearing music
04 collect 1 digits after announcement 6448
05 goto step 2 if digits = 1
06 messaging skill 10 for extension 9321
07 stop
08

 

[tiramisu]

Dear Pete:

Returning to step 2 (queue-command) will take your call out of the queue-slot and put it back at the end of the queue. You have to return to step 3 instead. Then your call will stay in the same original queue-slot

Another suggestion: If you are writing these type of vectors where calls can keep coming in and waiting in queue, it is better:
- to check the queue-slots you have assigned on the hunt-group form
- to also include a condition in your vector if ever the queue-slots are too few: e.g:
on hunt-group:
queue: 20
in vector:
01 goto step X if calls-queued in skill 1 > 19
...
X busy (or disconnect after announcement: too many calls call back later) or too many calls leave message on machine and goto messaging skill, etc...)

If calls are to come in and they don't have a queue-slot, they will just step over the queue-command and "forever" dwell in your vector. On your reports you will find on VDN-level abandoned calls, which you cannot see on skill level.

Hope this helps ?

Tiramisu

 

[mariner31]

Thankyou Tiramisu.
Much appreciated.

Regards,

Pete.

 

[avayaman]

Thank you tiramisu. I have been burned by that in the past. It's easy to forget about. It's not a problem if the queue length exceeds the incoming channels, but that's not really a good idea either. If you have EAS and/or Best Service Routing, you can accomplish the same thing by using goto step if expected wait time for call > 9999 seconds. Only thing with that is that if all agents in a skill or split are in aux work the caller gets a busy, but maybe that is not a bad thing, better than having the call Q forever if everyone has gone on a break at the same time.

Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[avayaman]

I might also add to the above that using the expected wait time for call > 9999 also eliminates the need to check for staffed agents. If anyone of the following 3 conditions are true, then the expected wait time is infinite.

1) No Staffed Agents.
2) All agents in Skill are in Aux Work.
3) Q threshold has been exceeded.

Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[RTMCKEE]

I've seen some interesting things happen on RONA calls also.

Say you only have two agents staffed and both are logged in and do not answer the phone. After the phone rings both agents and they do not answer the system will put both agents in aux, but that call is in limbo waiting for an agent.

As I recall if you do not have a number in the RONA field the call will just "hang" there waiting for an agent to become avaliable. The call will no longer follow the vector steps since it was queued to an agent.

RTMCKEE

 

[green6]

I'm curious about the replys to your question. I respectfully disagree.

I believe that the callers place in queue remains the same regardless of the fact that you are looping back to the "queue to" command. I've created a simple test vector and watched the queue time on CentreVu for my test skill. If the call lost it's place in queue each time it looped back I should see the queue time on CentreVu reset and start over for that call.
What I am seeing is the queue time continues to accrue even though I have the recurring loop.
I think that the only way to take the call out of queue is to use a "route to number" command or have it answered by an agent.

Can anybody confirm what I am seeing?

I'm running Definity Version 8 with EAS. Maybe my system doesn't react the same as a non-EAS system?

 

[RTMCKEE]

We also have eas. I always thought the call remained in the same order reguardless if you sent it back to the queue to step (what green6 said), infact the definity documentation says you "should" send it back to the queue to step just incase for some odd reason it does not queue the first time.

Im pretty sure our priority is always top, so maybe that has an affect on queue order, maybe if its queed at low priority the next time around it gets bumped?

I will set up a test vector tomorrow, and see if my assumptions about the rona are correct also.

RTMCKEE

 

[avayaman]

I also believe that is incorrect. I noticed it & thought, well maybe he knows something I don't. I was going to check it as well. It would be interesting to re-queue it at exactly the same priority & see what happens. As far as the RONA problem is concerned, it would nice if you had the option for it to log out the agent rather than put them into Aux Work. I've sometimes sent it into a VDN that routes the call to the supervisor, so they know someone has walked away without going into aux work. Another quirk I have noticed is that it seems to be possible for the last agent in a split/skill to log out while there are still calls queued. It would seem logical to me for the system to prevent the last agent from logging out if the Q was not clear.

Also has anyone ever come up with a simple method of placing a Q into nights? I can't understand why a simple night key function has not been built into the system. The ability to use a hunt-ns key dissapears as soon as you specify vectoring in the split. I've done it with a dummy skill that the supervisor logs into, but that seems awkward. In small applications I've also sent the call through a dummy hunt before the main entry VDN and used a hunt-ns key. Since that means you have to route incoming calls in the day through a coverage path to the entry VDN, I'm reluctant to try that on a Q with high call volume. I have visions of calls being lost. What would be really nice is a night destination option in VDN's and a VDN-ns key.

Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[green6]

I'm with you beddows,

There are some really simple features that could be added to vectoring for much more flexibility.

I've been asking for the ability to program toggle buttons into vectors for years. For example, a go to step/vector, or, route to number if toggle 1 is on/off, etc. You program the button onto a phone or multiple phones and users could change routing with the push of a button similar to night service. A similar VDN button would be another great tool.

Some ideas for re-routing in your above scenario are;
1) vector steps with routing based on time (the obvious one but not much flexibility),
2) if you have ISDN you can take your incoming digits and change them at the trunk group based on the status of the console night service button, or
3) you can create a phantom queue with a phantom agent, the supervisor logs in with the phantom agent ID and you use the "goto if staffed agent in queue...etc to reroute the call.

I've not seen a way to completely log out an agent based on RONA and I wasn't aware of the potential for the last agent to logout while there are still calls in queue. I guess that would be a good reason to check the staffing status of your queues on a recurring basis and route out if staffing drops to zero.
One trick I've used with RONA is to redirect the calls to a cover answer group of multiple phones. When a call goes to RONA on my system 8 other phones start ringing. It definitely gets some attention.

 

[avayaman]

I've resurrected this thread to clarify something I mentioned above about using expected wait time to check for Queue slots being full. Its important to note that the callhas to be Queued first

Eg;
1 consider skill 1 pri l adjust by 0

2 consider skill 2 pri l adjust by 0

3 goto step 5 if expected wait for call > 9999

4 queue to best

5 busy


It should be noted that this only works by checking the expected wait time for "call" " check expected wait time for best, or check expected wait time for skill will NOT work.

Because the call is momentatily queued, I'm not sure if this may impact stats or CMS. I do not think it will appear as an abanoded call, since there is a timer for that in system parameters features that defaults to 2 seconds. I'm going to check it out.


Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[avayaman]

I'm sorry, its too early in the morning , steps 4 & 3 above have to be reversed.

Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[tiramisu]

Hi Paul and Pete and however's on this thread by now,

I've just been reading through it, and I was surprised to hear that you can requeue ! I guess, you're never too old to learn new things.

On the queueing thing:
- If you requeue, does that mean that the call takes a new slot in the queue (one less for a newcoming call)
- does that also mean that when the first queueslot of the call is being answered, the second one will give an outflow on the cms reporting ?
- what about simultaneous queuing in 3 different queues, does that still work ?

On the Rona bit:
If you're afraid that a call will stay hanging in mid-air because rona has put all your agents in aux, why not try to put rona on a VDN and check first in the vector whether EWT is > 999 and if so choose alternative routing

To track rona, just customize an agent (group) or skill report, inserting a NOANSREDIR column. It will give all rona-counts for each of the agents. A good alternative for the exceptions log.

On the extra gadget bits that AVAYA should do:
- I didn't really understand the need for an ns-button
- My frustration is that you cannot check agents in a certain aux-code: e.g. goto vector if agents in aux1 > 10
(meaning then that some European call centers have team-meetings with a whole section agents during office hours and another group has to fill in for them). Now, supervisor need to manually redistribute skills for a couple of hours.

regards,

 

[avayaman]

On the re-queueing thing, that is an interesting point, I will check it out in our lab and post a reply.

The Rona suggestion is a good one, but it seems that only checking EWT for the active call will check for infinite EWT in the target skill based on available queue slots. It does consider a queue will all agents in aux work as having infinite wait time. I had a little trouble finding this in the documentation but it is there, sort of.

Quote:

EWT for Call


EWT for a call is the remaining time that a caller can expect to wait before his or her call is
serviced from the queue. If the call is queued to multiple splits, the remaining queue time
for each of the splits is calculated, and the shortest of these is taken as the call’s EWT.

For a call to have an expected wait time it must be queued to at least one split. IF IT IS NOT QUEUED, or if it is queued to splits that are not staffed, the EWT value is infinite.

The "if it is not Queued" I have capitilized seems to be the reference that applies to queue slots, if there are none, obviously the call is not Queued, but an attempt to queue the call must be made before attempting to route on this basis.


Now under the reference to EWT in a split, it also seems like the same holds true, but when I tested it in the lab (using skills, maybe that is the difference), EWT was not considered infinite when all the Queue slots were full. It does consider EWT infinite if all agents are in aux work. here is what it says under EWT for a split:

EWT for split:

EWT is infinite if:


There are no logged-in agents.

All logged-in agents are in AUX work mode.

The split queue is full.

There is no split queue and all agents are busy.

The split queue is locked (This occurs when the last working agent in a non-vectorcontrolled
split attempts to go into AUX work mode.).

I would assume the reference to "split queue is full" as queue slots, but when I tested it, this was not the case. I'm going to do some more experimenting & try & pin it down.


Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[green6]

the thread that never dies... : )

Tiramisu

Queueing multiple times in the same queue for the same call should not affect that calls queue slot positin unless the call is requeued at a different priority. I suspect that the call gets tagged and the system keeps track of the tags place in queue regardless of how many "queue to" statements it sees. I've not tested the possibility of queuing at different priorities though but I am implementing a program that bumps a calls priority as time goes by. I'll post up my results once I've put it into place.

Good question on what CMS reports will show if a call is taken out of queue at one priority and put back in at another priority.
Again, once I have my new programs in place I'll see what happens and post my results.

Not sure what the question is on queueing to multiple queues. Yes you can queue to a max of three skills which is a system limit.

The night service button idea is just an easy way to manually control routing. Currently there is no way for me to manually reroute vector calls without doing some fancy work-around programming. Hunt groups have had this functionality for years; push a night service button - redirect the call.

As an example, we have departmental meetings requiring all hands. I can program the vector to reroute based on no agents staffed. It only works if all agents log out, which they sometimes forget to do. If I had a toggle button that I could program on the supervisors extension, the supervisor could reroute calls by pushing the toggle button which I would have previously referenced in my vector, bypassing the need to check staffing levels.

Eg: "route to xxxx if toggle 1 = ON"

To do the same thing now I have to create a phantom skill and give the supervisor a phantom agent login ID. The supervisor logins in to the phantom skill and I reference that skill in my vector.

Eg: "route to xxxx if staffed agents in skill x > 0"

Great idea on the custom reports showing NOANSREDIR. Tracking down agents who fail to properly AUX out has been an issue since there is no standard report that accomplishes that. Usually I use the agent trace function of CentreVu but it's not very elegant.

Good luck.

 

[tiramisu]

Green6,

Is this "putting a call back in queue with higher priority" a necessity for your business, or just for testing purpose. Because, if necessary for business, you really should try CV Advocate: calls get automatically higher priority while waiting in queue, as the system checks its Predicted Wait Time against its service objective. A very elegant solution.

On the ns-button, yes, this is clear now: this is how I tackle the team meetings in call centers as well, by having a supervisor login with a fake ID. What can I say: great minds...

Paul,

From what I read re: EWT infinite: you can also check the skill before placing the call in queue (do I understand that correctly ?). Then I'd really prefer doing that, because first placing a call in queue, then checking and going somewhere, will give me an outflow on my reports, which will be devastating for my service level by the end of the day.

Thanks for your feedback !

 

[avayaman]

Tiramisu - I'm not sure a split second queueing will show up in reports, I suspect there is a timer somewhere, as split second queueing would happen under normal circumstances as well. If anyone wants to check that out, I'd appreciate knowing one way or another.


Ok, I've been down in our lab experimenting. It seems that requeing a call does not use up another Q slot. I guess this makes sense if if releases a queue slot when it re-queues.

Now for EWT.

Scenario 1:

If you queue a call first to a skill,split or best, then do a "goto if expected wait for call > 9999", it works.

EG

1 Consider skill 1 pri l adjust by 0
2 queue to skill 1 (or best) pri l
3 goto step 5 if EWT for call > 9999
4 announcement XXXX
5 busy

Now in that case the call is momentarily queued then given a busy if:

1: Q slots exceeded
2: No logged in agents
3: All agents in that skill are in aux work

I haven't delved deep enough into CMS stats to see if there is a field for total calls Queued. If so this could be an issue since the call is Queued for a split second, but i would imagine there is a timer there that will ignore split second queueing anyway.

If you try to reverse steps 2 & 3, it don't work. That's unfortunate.


Scenario 2:

This vector also works

1: Consider skill 1 pri l adjust by 0
2: goto step 5 if EWT in skill 1 pri l > 9999
3: Queue to skill 1 (or best) pri l
4: announcement XXXX
5: busy

In this case the same calls route to busy as above, but the call does not have to Q momentarily. Only problem with this scenario is if you are queuing to multiple skills or Q to best, your only looking at EWT for one skill. If you put all 3 in a row, it will route to busy on the first full one it sees, defeating the whole purpose.

This vector does not work:


1: Consider skill 1 pri l adjust by 0
2: goto step 5 if EWT for best > 9999
3: Q to best/ or skill 1
4: announcement XXXX
5: busy

Reversing steps 2 & 3 also doesn't work.


I just used scenario 1 in a large call center I just implemented for Verizon. The reason I used this method rather than the "goto step if calls queued >" method is because they have a large number of skills accessed by a large number of VDN's. I'm using best service routing (queueing to the best of 2 or 3 skills defined in the accessing VDN based on EWT). Some of these skills have very few agents and the customer wanted the calls routed to a mailbox if all of them happened to be in aux work. The " ifcalls queued >" method does not pick up agents in aux work, just logged out. They were worried about all the agents in a skill going into aux work at once (Call Centers in Canada don't tend to be the sweat shops they can be elsewhere & agents are not monitored as closely). Because some of these skills only have 2 agents, I needed to set the Q slots low, so they did not get too many calls stacking to them.

This creates a problem with routing based on calls queued , since there is no such statement like "goto step if calls queued in best > X". That is why I used infinite EWT to do the job.

I am also using generic vectors for most skills to try & keep it simpler. For this reason, BSR is being used even in skills that do not require it, and I tried to make it so that BSR can be used efficiently as the volumne grows (they are expanding across the country) without having to do a complete redesign later. Some of them have a low enough volume to make EWT an inaccurate parameter to base treatment on. I'm just not using it in those cases for giving callers treatments based on EWT other than detecting infinite EWT.


By the way, in the case of Verizon, we are using IP Agents tied to a Meridian switch. There appears to be a bug in IP agent (at least version 3). You cannot enter reason or workcodes if vu-stats are active & are in the process of refreshing. On a hard set, vu-stats suspends automatically, in ip agent it does not. In other woirds, IP agent is not correctly emulating a callmaster. (Also tried it with an 8434 & 6424 emulation) We are going to try version 4 & have an active trouble into Avaya on this problem.


Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html

 

[green6]

Tiramisu

The need to "up" priorities stems from programming I've done to categorize calls by importance of customer. (Marketing idea, not sure if it was the best solution). The problem that it caused, and one that I pointed out in advance, was that the lower priority calls could end up in queue for extended periods as long as higher priority calls continued to ring in.
The fix was to bump up the priority after a preset time in queue. I'm in the process of making the programming changes now. I have no idea what the impact will be on CentreVu reports, yet.
It sounds like CV Advocate accomplishes the same function, yes? I'm not familar with Advocate and since our company is on a spending freeze during these troubling telecom times I'm sure that I won't be purchasing new products anytime soon.
Thanks for the feedback, this site is a great place to learn new tricks.

PS
Alas, the phantom queue trick was not something I came up with myself. I learned it from an old Bell Labs engineer. In fact, most of the programming tricks I use were learned from the "old timers".

Greg

 

[avayaman]

Greg,

I have run into this issue on several occasions, usually when the customer has a 1-800 access & a local access to the same Q. Usually I write 2 identical ca vectors, one queueing at a higher priority than the other. The one that queues at lower priority does a requeue to the same priority level as the 1-800 Q when it reaches the second announcement, at which time all is equal. This enables 1-800 calls to be presented before any local calls until the local calls have been queued for a minute.

Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via

http://www.vancouver.hm/email.html