Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: cavagnaro on December 02, 2006, 12:11:17 AM
-
Hi,
I'm running an OCS campaign and from time to time some calls goes to agents that do not belong to the campaign, i have checked the logs and they seem to be calls that exceeded queue time. How can i set OCS to indicate to drop this calls. I setted up the overflow_dn option on OCS with the value of a set. Then on the set options, annex tab created a default section a option with value overflow_dn = true but didn't worked.
Do i have to restart OCS? TServer?
Thanks for any help
-
[quote author=cavagnaro link=topic=1937.msg6423#msg6423 date=1165018277]
Hi,
I'm running an OCS campaign and from time to time some calls goes to agents that do not belong to the campaign, i have checked the logs and they seem to be calls that exceeded queue time. How can i set OCS to indicate to drop this calls. I setted up the overflow_dn option on OCS with the value of a set. Then on the set options, annex tab created a default section a option with value overflow_dn = true but didn't worked.
Do i have to restart OCS? TServer?
Thanks for any help
[/quote]
Hello, Cavagnaro,
I am so glad that you have posted your question! I am using OCS in a small callcenter and did not know that there is way for calls to be "overflown" to "overflow" dn where it can be dealt with. Armed with the knowledge that there is a overflow-dn option, I looked through OCS manual again and to my delight I found what I was looking for!!! This is a really useful feature, isn't it?!
A smart test, that followed confirmed that this option does in fact work and I will be putting it to good use on Monday.
The way I got it working was rather simple:
1. define an overflow DN (ACD queue 20000 for us)
2. in CME add a "default" section to Annex of 20000 DN definition
3. in "default" section, add "overflow_dn" and set it to "true"
4. add overflow DN to Agent Group that you defined under campaign as "Origination DN"
5. restart OCS
This will forward all the calls to 20000 if they are not answered within the predefined time.
As you you can see with my setup we do not drop the calls but transfer them to 20000 instead, this is because if you want to drop the call, you need to do so on 20000 either by modifying the pilot (and/or vector) on 20000. The really cool thing about using overflow dn is that in CCP and CCA the call is marked as "dropped" instead of abandoned!!!
Please tell me if you were able to replicate this as well and if there is anything else that can be done with OCS please please please tell me as well!!!!
-
Hi,
Ok i have to use it on production, no time for lab, scenario was desperate.
So still can't say if this worked or not.
Now in your strategy on this overflow RP you just end the call? (In > End)???
About other options for OCS well there are a lot of usefull optional stuff, maybe if you read the whole manual you can find many things you can use on your CC.
Thanks
-
Well it is definitively not working, overflow is reaching inbound agents which are another very different group, have to find a solution for this asap
-
[quote author=cavagnaro link=topic=1937.msg6434#msg6434 date=1165083503]
Well it is definitively not working, overflow is reaching inbound agents which are another very different group, have to find a solution for this asap
[/quote]
Cavagnaro,
how are you?
OCS man post seems to be correct - it should be working. Have you tried what he has suggested and after rebooting OCS you still do not have calls forwarded to overflow dn?
I have a question - is it that the calls not forwarded to overflow_dn or are the calls forwarded to overflow dn and then they are distributed to agents and you want OCS to NOT do it?
Well, if this is latter, then OCS cannot really drop the calls per say - you need PBX to do it for you, so in overflow dn scrip, all you need to do is add STOP (or some other equivalent of it in whatever PBX language) and PBX will drop the call.
If your calls are not forwarded to overflow dn - please provide us with OCS and tserver logs showing what happened to the call that was not answered within the first two seconds (or whatever you have set for your timeout).
Also, I strongly adivse that you issue a titcket to Genesys support just in case, even though chances are solution through this board will be probably much sooner (no pun intended :P )
Vic
-
Cavagnaro,
Victor is right: if you have setup the overflow dn as ACDQueue, you have to program the script on the VDN on the switch to really drop the call (for Avaya really easy, a 'disconnect after announcement' is enough). This is why OCS does NOT drop the call, it just marks the call as "Dropped", the switch has to to it. Only after this, check or send OCS logs where there we should find the calls landed on this overflow dn got disconnected. If there are not, it means the calls get distributed some other ways to agents, in this case we need URS and TServer logs.
-
Ok,
What i did is the following:
On the strategy that routes to agent group, if after 10 seconds, no agent answer the call i send it to another RP which has default option (Annex Tab) and overflow_dn = yes.
This RP has another strategy loaded which simply goes in , cancel the call, end.
Now, i see that using IRD monitor the call on the decision (target object) on going to the overflow dn (the RP) always takes the false node. ???
Still can't check the OCS/URS logs, will arrive at customer site and let you know.
-
Cavagnaro wrote:
[quote]On the strategy that routes to agent group, if after 10 seconds, no agent answer the call i send it to another RP which has default option (Annex Tab) and overflow_dn = yes.
This RP has another strategy loaded which simply goes in , cancel the call, end.
Now, i see that using IRD monitor the call on the decision (target object) on going to the overflow dn (the RP) always takes the false node.[/quote]
??
You should just have the block target of the agent group, then connect its [color=Red]red node[/color] to another target block that has the RP in. No strategy should be loaded on this last one, also cause I wouldn't configure it as RP, rather as an ACDQueue with its pbx equivalent (VDN for Avaya, e.g.) that disconnects the call.
-
Yeah, i just noted my stupity. It seems that sleep only 6 hours on 3 days has it's bad effects. today more fresh reviews all and saw that huge mistake.
Changed and eveything seems ok until now.
Also for a note removed the Overflow from the RSI object of Alcatel PBX so under no circumstances it goes to the CCD Queue of Inbound.
-
Well, seems all is perfect on this issue now.
Thanks everyone for the help ;D