" /> Statistic is wrong because of RONA - Genesys CTI User Forum

Author Topic: Statistic is wrong because of RONA  (Read 2985 times)

Offline vma

  • Sr. Member
  • ****
  • Posts: 255
  • Karma: 0
Statistic is wrong because of RONA
« on: April 08, 2014, 09:10:00 PM »
Advertisement
Hello,
I need to know the number of calls answered in first 20 seconds but this number is wrong because of Rona. For example, call is waiting in the queue for 60 seconds then it is distributed to agent. He is not picking up the call so Rona kicks in and call is back in queue. Second agent is picking up in 3 seconds and in CCPulse is counted as answered under 20.

agent-no-answer-overflow is set to a RP where rona strategy is loaded.
the clear targets is not ticked and divert-on-ringing is set to "false" so the EventDiverted is not raised and call ends up in the rona strategy without being removed from the queue. Until now all is good.

But when rona strategy routes the call back to main strategy, after EventRouteUsed I get the EventDiverted and call is removed from queue. This is why the timer is reset and when second agent picks up it is seen as under 20 sec.

Is there a way to prevent this? Is there a way to keep call in queue and still execute all the operations from the rona strategy?

the architecture is pure SIP Server 8.1.100.81
URS is 8.1.300.16

Thank you,
Mihai

Offline terry

  • Sr. Member
  • ****
  • Posts: 328
  • Karma: 35
Re: Statistic is wrong because of RONA
« Reply #1 on: April 09, 2014, 12:33:47 AM »
It might depends from exact flow of events as seen by URS but possible ways to try:
-playing with option confirm_departure. Set it to some time and URS will delay reaction on routeused.
  If during this time URS get EventEouteRequest again on original RP then you have possibility to start startegy from the beginning
  without exiting from queues.
  It is assumed that URS doesn't monitors agents DNs and use_ivr_info is set to true.
  In this way however delaying will be always, will rona be activated or not.   

  - use custom routing. In routing selection object add reference on subroutine in Custom Routing Combo Box.
    Subroutine can make its own routing as well as decide what is criteria of success of routing.
    If it decides that routing fails (for example rona detected) then it returns error and strategy just continue through red port
    of target selection object keeping call in all queues.
    Way to distinguish when routing is Ok and when not (rona) still required.



 

Offline Steve

  • Sr. Member
  • ****
  • Posts: 298
  • Karma: 11
Re: Statistic is wrong because of RONA
« Reply #2 on: April 15, 2014, 07:55:44 PM »
I know it doesn't really answer the question but I can't see why people still use RONA. The agents are paid to answer calls so make them do it, stop letting the calls ring and use auto-answer.
The agent gets a beep in the headset and the call pops on the screen at the same time. The customer journey is much better than ringing, queueing, ringing, more calls are answered and less queue ports are required so costs came down.

Everyone's a winner! (except perhaps the agents, but it is not wrong to make them do their jobs)

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Statistic is wrong because of RONA
« Reply #3 on: April 15, 2014, 09:27:26 PM »
Yeah that is ideal scenario but there are customers and business models. Some agents are not exactly only agents but expert agents who earn a ton for each call and you can't force them to answer like that :/ financial agents who are stock or market sellers will tell you a huge "fuck off" if you tell them to auto answer lol