Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: KiwiCosmo on May 22, 2015, 03:40:16 AM
-
Hello there,
I have a bit of a inbound routing issue... here's the scenario:
1. We have many agents geographically distributed to contact centres across the country.
2. Calls are routed the agents using SKILLS
3. Any agent in any contact centre can answer a call if they have the right skill.
4. We have hundreds of SKILLS and thousands of agents.
Pretty basic right?
So, the issue:
A contact centre in [b]City_A[/b] 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 [b]City_A[/b], even though those agents are logged in/ready and have the appropriate skill to receive the call.
ideas?
.... and go.
-
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.
-
Logging out is bad idea. Better control by emergency flag on strategy
-
[quote author=cavagnaro link=topic=8864.msg39521#msg39521 date=1432297894]
Logging out is bad idea.
[/quote]
Why?
-
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".
-
O.o nice...from where you got that trick?
-
I use a parameter group in GAX (so an ops manager could trigger it) and set an "Emergency Declared" boolean for each center.
-
Well that would work on BEP environment but not a standard for all Genesys implementations
-
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... :)
-
Strategy change based on Dtmf? Jummmm how? Is basically the same as attached data...strategy has to do something
-
oh just to clarify...
1. We have two switches (so we don't have a switch at each site)
2. The mechanism for deactivating a site is not an issue (as we simply change a key value in a transaction list)
3. 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, [i]without [/i]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.
-
[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.
-
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.
-
[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
-
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.
-
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.
-
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?