Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: SisB on August 26, 2009, 11:09:28 PM

Title: Staff Check Logic in Routing Strategy
Post by: SisB on August 26, 2009, 11:09:28 PM

Hello All,

I guess many of us are using a staff check logic in Routing - to see if there are agents logged in to the system with a particular skill expression. If no agent logged in - the line could be considered closed and appropriate treatment could be given.

Today in the strategy we are using GetSkillInGroup/ExpandGroup - to first get a list of agents matching a specific skill criteria and then entering a loop for doing SData on them one by one. As soon as an agent is found logged in, break the loop and proceed with queuing the call (since agents are logged in). But we are seeing CPU utilization problem because of this fast looping.

We tried to use CountSkillInGroup as an alternative (without agent group parameter, as we cannot use it due to other reasons), but that is querying stat server for all agents in the system.

Is there any other approach you might be using. or any better idea?


Thanks

Title: Re: Staff Check Logic in Routing Strategy
Post by: René on August 27, 2009, 09:30:54 AM

Hi,

The way you using isn't really optimal from performance point of view. I would suggest you to define virtual agent groups based on required skills and then use SData function together with some relevant statistic like StatAgentsTotal. Such approach makes your strategy easier and it won't be CPU intensive.

R.

Title: Re: Staff Check Logic in Routing Strategy
Post by: SisB on August 28, 2009, 05:57:43 PM

René,

Thank you for your response.
I agree that having VAG will make things better from load perspective, but creating and maintaining VAG for thousands of expression (and they go through frequent changes) itself becomes a complicated task.

Thanks again.

Title: Re: Staff Check Logic in Routing Strategy
Post by: catanirex on August 30, 2009, 07:53:17 PM

Another way is to configure URS (skip_targets option) to immediately exit on the red port if no agent with required skill is logged in. In this way you can escalate the call to next target and so on.

Title: Re: Staff Check Logic in Routing Strategy
Post by: René on August 30, 2009, 07:54:23 PM

Hello,

It's me again ;). I've been looking around your "issue" and found something. Maybe it won't bring any performance benefit and there is a chance you've already tried that way. But it's worth a try IMHO.

It is possible to check whether there are any agents logged in with particular skills using IRD functions MultiSkill, ExpandGroup and SelectTargetsByThreshold. Function "MultiSkill" is used to define dynamic agent group based on skill (generally - on logical expression). Returned string is passed to function "ExpandGroup" that returns list of agents belonging to that group. Finaly, function "SelectTargetsByThreshold" returns list of agents that fulfil defined condition. In your case, non-empty string means there are some agents available so call could be routed to such dynamic group.

[code]vTargetGroup = MultiSkill['<...Statserver name...>','<...skill expression...>']
vExpandGroup = ExpandGroup[vTargetGroup]
vAgents = SelectTargetsByThreshold[vExpandGroup,'StatAgentsTotal',0,ReadyIfGreater][/code]

It would be nice to have possibility of using the function "SelectTargetsByThreshold" without expanding the group as the function "ExpandGroup" has negative performance impact and usage isn't recommended. But it doesn't work without it.

What do you think about that?

R.

Title: Re: Staff Check Logic in Routing Strategy
Post by: SisB on September 02, 2009, 04:15:16 AM

catanirex,
We'll have some challenges implementing this in our environment because of the way we target the calls and peg the virtual queues.

René,
Excellent idea!! I tried it in our lab and it [SelectTargetsByThreshold] is definitely better than looping through the agent list and doing SData one by one -  relieves CPU considerably. Better in other ways too.

Thank you.