Excluding agents from being targeted

[Fra]

[quote author=cavagnaro link=topic=8864.msg39524#msg39524 date=1432303798]
Because agents may be on a ongoing call or some state where logout is not possible. Therefore you run a risk that you waste time waiting for those agents to do a proper logout will allow yet calls to come in.
If you handle that on routing will avoid such situations.
[/quote]
True, but you don't have the luxury of waiting to finish a call if you get a fire alarm: notready + hang up and run.

[mduran22]

We have done something similar to what Terry mentioned but we build skill target variables during the strategy based off of Transaction lists and Route Point information. We also have site skills for everyone as well. So if a call comes in that is for a new insurance claim and requests Spanish the variable becomes NewClaim >0 & Spanish > 0. If we put in a flag in the transaction list (or could also be route point or other places) to close a site the variable is modified and a "& LosAngeles < 1" so the variable (and skill expression) becomes NewClaim >0 & Spanish > 0 & LosAngeles < 1. We still of course have calls that make in before the flag set that get stuck on a phone with no person for a little while. The other thing to consider in this is reporting, especially real time. In our case we may show availability in a Virtual Agent group because those agents with that City skill are available but the skill expression modification now excludes them. You could build specific VAG for sites and we even looked into a config SDK to modify the script for the VAG during this time, but based on the frequency this happened we decided to manage it as an emergency and not worry about the stats during that time.

[cavagnaro]

[quote author=Fra link=topic=8864.msg39544#msg39544 date=1432630248]
[quote author=cavagnaro link=topic=8864.msg39524#msg39524 date=1432303798]
Because agents may be on a ongoing call or some state where logout is not possible. Therefore you run a risk that you waste time waiting for those agents to do a proper logout will allow yet calls to come in.
If you handle that on routing will avoid such situations.
[/quote]
True, but you don't have the luxury of waiting to finish a call if you get a fire alarm: notready + hang up and run.
[/quote]


Hehe if there is a fire I doubt they care to logout or make a flag

A flag has shorter time to deploy

Flag will prevent new calls no matter what

[Nathzn]

Hi,

Create a new skill(example : EmergencyA) - Specifically for emergency use. Attach this to all agents at a level 10(can be any number but all have to be the same on each agent)

Create a new transactiion/list object(example: EmergencyFlags); within this list object create a new key/value called EmergencyA, set at 'N'.

Before the targeting block in IRD fetch the data from the list object(EmergencyFlags) and if 'EmergencyA' = [b]'Y' [/b] then within the targeting block you want to use the skill expression - [b]Cat['City_A >= 5 & ','EmergencyA != 10'][/b]

This means that the call will only target the City_A agents over 5 that [b]DO NOT [/b] have the emer skill @ level 10

if 'EmergencyA' = [b]'N'[/b] then within the targeting block you want to use the skill expression - [b]City_A >= 5[/b]

This means that the call will only target City_A agents over 5

the one that we use is a little more completx than this having over 30 different site skills.

_____________________

If active the call will continue to queue. You can also create a new startegy that will control the list object, allowing you to active the flag in an emergency in your own building/office.

[KiwiCosmo]

Thanks for all your efforts chaps!

I'm going to roll with the site skill option.  It means a change to our agent reservation algorithm, but that's probably a good thing.

Interestingly, if you include a threshold option lcfgdata at the target block and set a transaction list object for the site to either 1 or zero, you can disable the site while the call is still within the target block (useful if you have long queue times in a single target).  Kinda cool that.

[Adam G]

Have you given any thought to how will the update be invoked?  I mean, practically, the staff are vacating because of a fire - do you have someone nominated to "hit the switch" to make that change?  You've mentioned that staff may be mid-call and so I expect you want the change to be immediate - but I can't imagine anyone still sitting there, saying[i] "I'll be out in a second guys - just got to log in and update this Strategy/Block...."[/i]

Maybe a password-protected "Kill Switch" in IW/GSD?