Using consider in your vectors 1

[dynamos2000]

We are going to be cross training agents in other departments to help out Dept A when expected wait time exceeds a certain threshold.

However we don't want the cross trained agent in Dept B to get the call if his or her primary skill is already slammed.

I'm looking for suggestions / best practices that you may be using in your own call centers.

Thanks as always

 

[koglass]

Are you using skill based routing and do you have Avaya Business Advocate software activated in you switch?

 

[dynamos2000]

Hi,
Skill based routing. To be honest I don't know about the advocate software. I do see where I have everything enabled to use the consider as an option for my vectors.

It looks like no matter how you use it, if using my example above, if Dept B has someone available, the call will go to them if no one in Dept A is available no matter what your options are. Ideally (for management anyway), a call would stay in queue in Dept A even if Dept B had an agent available as long as the EWT wasn't too bad.

 

[koglass]

I was just thinking that you could just easily assign reserve skills to those that have been crossed trained. So when there are no agents left in the primary skill they will go to the reserve agents to be answered.

 

[koglass]

Also the consider step is generally used for multiple sites and best Service Routing.

 

[dynamos2000]

Gotcha, but I'm still stuck with the "But if Dept B is busy, we don't want our cross trained agents getting slammed and hurting the agent's main department" deal.

Its never simple haha

 

[dynamos2000]

Best service routing is what I believe I have to use

 

[marcell55]

I would use a "check" command instead.

queue-to skill 1 pri m
check skill 2 pri m if expected-wait < 120

It will only queue to skill 2 as well if the "expected-wait" in skill 2 is less then 120 seconds. You can also check skill 2 for "available-agents", "calls queued", "oldest call waiting", etc.

 

[dynamos2000]

Ahhh gotcha.

So if we wanted skill 2 to be a backup of skill 1, but not at the expense of 10 degrading service to its primary focus, I would change:
01 queue-to skill 1 pri m
02 wait-time 30 secs hearing music
03 goto step 8 if staffed-agents in skill 99 > 0
04 goto step 8 if staffed-agents in skill 97 > 0
05 goto step 8 if staffed-agents in skill 5 < 1
06 goto step 2 if unconditionally
07 stop
08 disconnect after announcement 8133


to:
01 queue-to skill 1 pri m
02 check skill 2 pri m if expected-wait < 120
*if I am understanding this correctly, don't queue to skill 2 unless the expected wait time for skill 2 is less than 2 minutes...so if ewt is 3 minutes for skill 2, its gonna queue to skill 1 and the caller will remain in that queue until answered
03 wait-time 30 secs hearing music
04 goto step 9 if staffed-agents in skill 99 > 0
05 goto step 9 if staffed-agents in skill 97 > 0
06 goto step 9 if staffed-agents in skill 5 < 1
07 goto step 3 if unconditionally
08 stop
09 disconnect after announcement 8133

 

[dynamos2000]

Sorry, I don't think I can go back and edit that post.
I should have said:

So if we wanted skill 2 to be a backup of skill 1, but not at the expense of degrading skill 2's service to its primary focus, I would change...

 

[marcell55]

Yes, pretty much. Something to keep in mind in that scenario: If skill 2's ewt is less than 120, you would be queued to skill 1 and skill 2 at the same time.

If you only wanted to queue to one skill at a time, you would have to do goto statements before queueing instead.

 

[dynamos2000]

Awesome Marcell55! I don't see how being queued to both is a bad thing at least in our setup. Seems like that is the best of both worlds as the call has the opportunity to be answered by either sk1 or 2 at that point.