I have a bit of a inbound routing issue… here’s the scenario:
We have many agents geographically distributed to contact centres across the country.
Calls are routed the agents using SKILLS
Any agent in any contact centre can answer a call if they have the right skill.
We have hundreds of SKILLS and thousands of agents.
Pretty basic right?
So, the issue:
A contact centre in City_A has a fire alarm and evacuates without logging out their agents (and their phones are set to auto answer).
We want to restrict URS from targeting agents in City_A, even though those agents are logged in/ready and have the appropriate skill to receive the call.
To add CITY skill and modify routing strategy to route only if some agents/virtual group doesn’t has this CITY skill or level is not enough. This level can be managed through Config Manager and taken by strategy during each routing.
One of our clients has that exact requirement and setup. I’ll take a look after the weekend as I haven’t viewed that part of their routing yet, but have a feeling that it may be an external app that logs those agents out when a fire alarm/evac has been triggered on that particular site.
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.
If contact centers can be identified by switch(es) then probably marking entire switch object as “not targetable” can be used
(no DN located on such switch will be selected by URS for routing call).
For such marking few ways exist, one of them - setting in CME in Switch annex in section “ROUTER” option “using” with value “none”.
How about a digit code sequence to a specific Route Point/DN loaded with a Strategy, which when dialled invokes a Strategy change across the affected Site, based on the code entered?
Sounds much less reliable - but much more dramatic than each of the previous suggestions…
We have two switches (so we don’t have a switch at each site)
The mechanism for deactivating a site is not an issue (as we simply change a key value in a transaction list)
This would be quite simple if we were to use Virtual Agent Group as our targets as we could just build the group to specifically prevent a skill from being targeted (eg, the skill would be the site). However, we would have to build hundreds of VAGs, or use SDK the edit them on the fly (which might still be an option, but a bit of an extreme solution to what should be a fairly simple task)
currently we simply have a target group for each site, then target each site in a single target block…this works, but it’s not scalable and we’re looking to add many more sites.
Really what we need is to target SKILL and exclude SKILL… without using a VAG
Thanks for your ideas on this though, really nice to throw some ideas around.
I’m not sure I understand the question now - since you have just proposed a working solution. Specifically targeting Skills - or NOT targeting SKILLS - is the obvious answer. Are you saying that you know how to Target a VAG with SKILLS, but you don’t know how to Target a SKILL, without using a VAG? If so, a simple remedy could be to include an IF Block, include an “All_Agents” VAG and apply a SKILL name, per Site.
If you are talking about scalability, in that you would have either hundreds of VAG’s or SKILL’s because each one represents a SITE, then perhaps you are looking at this from the wrong end. To exclude a VAG or SKILL because of a fire alarm means changing a single parameter - not updating hundreds.
Create variable in startegy varClosedSkill. At the beginning check does some skill is closed and if yes then set this variobale to name of this skill, otherwise set this variable to 0. On top of existing targets (Agent group (virtual or real), skill expression) apply FIXED extra condition: varClosedSkill=0.
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.
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’ = ‘Y’ then within the targeting block you want to use the skill expression - Cat['City_A >= 5 & ',‘EmergencyA != 10’]
This means that the call will only target the City_A agents over 5 that DO NOT have the emer skill @ level 10
if ‘EmergencyA’ = ‘N’ then within the targeting block you want to use the skill expression - City_A >= 5
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.
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.
