" /> StatServer & WDE - count handled interactions that didn't result in a transfer - Genesys CTI User Forum

Author Topic: StatServer & WDE - count handled interactions that didn't result in a transfer  (Read 1763 times)

Offline gen_rtfm

  • Full Member
  • ***
  • Posts: 114
  • Karma: 4
Advertisement
I've been struggling with creating a statistic to show the average interactions per hour for an agent, but exclude any interactions that resulted in a transfer; I only want to count the interactions that agent could successfully finish themselves.

I want this displayed in WDE; which means I don't have the option to use several statistics and perform a calculation, as I can do in ccpulse.

I've been trying to get the count by setting:
Subject: DNAction
MainMask: 'CallInboundCompleted,CallInternalCompleted'

So I'm looking at retrospective actions because if I look at subject AgentStatus and MainMask CallInbound (for example) the interaction will be valid for that statistic before I know the outcome.

My problem is setting a filter for this statistic to exclude any interactions where the agent's final action was to transfer it. CallInboundCompleted will fire anyway.

I thought I could filter on attributeCallState, like I can on MediaType (so create a filter with value 'CallState=0' to only count calls that have actually ended); but it doesn't seem to work.

I'm hoping that a talented individual here has any hints about how to proceed.

I created a statistic to count any DNAction, just to get an idea about how many events were fired in a scenario where an agent is available, has an interaction offered, accepted and then transferred (single step). my statistic registered '12'. I don't know which ones though, so if any of you has an overview of which events occur when an agent accepts, completes or transfers an interaction that'd be a nice help.

Oh, and the kicker here is that if an agent receives a transfer and completes it (eg. doesn't transfer, but ends the interaction) it should be counted. I assume this eliminates the option to filter based on attached data, because data attached to the call at the first agent will persist and still be valid when agent two completes the interaction.