Has anyone been faced with this problem and come up with an elegant solution? We're looking to see if it's possible for agents to stay in a ready state and continue to receive queue to agent calls, but not receive queue to skill group calls. We've thought about having supervisors remove their skills, but this is not scalable when you have a large number of agents. Another solution could be to give agent reskilling access to all agents, but this also would be an adminitrative nightmare. Anyone?
can you please explain this in more detail? I do not mean no offense and all, but this sounds like a design flaw.
First of all, AFAIK if an agent does not have any (non-default) skill group assigned, the login is denied. So You can't just take all the skill groups away from the agent.
Second, can you just implement a service (either by calling a CVP microapp / Application Gateway / IP IVR) that would return a flag - if it is set, the ICM script would continue to the Select->Skill roup nodes (or Q to Skill Group nodes), if it is unset, then it would go to a different set of nodes, namely Queue to Agent.
[Start] -> [important routing decisions and other useful nodes] -> [Go to External Script getFlag.aef] -> [If ECC.flag="1"]
If positive, go to [Queue To Skill Group "Skill1"]
If negative, go to [Queue to Agent "JohnDoe"]
I'm not sure what you mean by design flaw. If you're going into the very specifics of how QtoA works, yes every agent needs at least one skill which is part of QtoA enterprise skill group. So, you would not be able to remove all SGs for someone if you want them to be able to take QtoA calls.
Agent login without skills: I think it's controlled by a registry setting, but you could have zero skills assigned and still be able to login.
I like your idea and you might be on to something, however the problem becomes where you want only some agents to get QtoA calls and other to continue taking both (QtoSG and QtoA). To go further in the scenario an agent needs to work on their backlog of cases, but wants to be available in case a customer calls who owns one of those cases. If they stay in a ready state there's a possibility that a new call might come in and the agent will have to take it or let the call RONA.
now it's getting more interesting er... challenging Could you give me an example? I am trying to imagine a situation when this would be necessary and it would not be possible to decide within the routing script.
Actually, I've got a similar setup with one of my customers: an ICM routing script asks an application gateway for a list of agents, ordered by a special condition (at least five different factors). The routing script tries to route the call to all of the agents on the list. If that's not possible for some reason (ie none of the agents is Available) then comes the good old Queue to Skill Group node.
I would recommend you a similar setup: first, try some agents, and then try the skill groups.
Let's think of this example:
I work in tech support for an ISP. In the mornings I answer customer calls and open a case for any new calls and in the after noon I do call backs to follow up on cases I have in my CRM queue. In the afternoons I don't take any new calls which result in new cases, just work on cases I own. A customer calls in and enters their case number, this is a case that was opened in the past and is assigned to me. In this scenario the agent didn't have to call the customer to follow up, the customer called the agent instead. The problem is that if you're in a ready state and assigned to a skill group, you will get new calls not just calls that are in your queue.
We're trying to prevent new calls from going to that agent. No matter how I slice this, we need some trigger which tells the system that the agent should no longer take SG calls. Then undoing this trigger is the next tricky part. I would love to solve this within ICM/CVP, but it's looking like custom desktop and maybe ConAPI might be the only solution.
But that example looks like it has a time of day solution.
What's wrong with the Supervisor doing the Dynamic Reskilling?
Unfortunately there is no time of day here as it's 24/7/365. Also, there are over a thousand agents and a lot less supervisors.
OK, so that was just a example but not YOUR example.
Are you saying that you would like this solution for all 1000 agents?
Yes, just an example the full details would take a dissertation to go through. Was trying to summarize it and break it down to as basic as possible. Yes, the solution would have to apply to the majority of agents.
Thanks for taking a crack at this by the way.
actually, it should not be that complicated.
What I would do: route the calls to agents only using the Agent to Agent node. A separate script - using queries against the ICM HDS and realtime tables plus an additional database - would pick the most apropriate call targets. It would also check how many calls the agent worked on, etc.
The ICM script of course would use Application Gateway nodes to talk to the separate application, which would inject the list of agent ID's into the script using an ECC array. So actually it would NOT be ICM picking the agent.
Er... Can you give us just some more bits?
Sent from Cisco Technical Support iPad App
Man this is getting so much more complex and really taking away from ICM's routing engine. Not sure I would like to go down this path as supportability (not by me) could become a problem. Any other ideas?
Thank you by the way, appreciate the mental exercise.
Nice avatar, by the way. I am glad to see the Evil Monkey got a good IT job.
Sent from Cisco Technical Support iPad App