RP stats in CCP - keep incrementing!

[JTL]

I'm just finishing the build of a new environment, and virtually everything is working to plan. Reporting is all fine, except for one annoyance.

I have a RP view, monitoring the inbound routing CDNs. We have VTO configured to play treatments if a call is not available.

The "problem" I have - the Calls Entered statistic for the RP view increments wildly when test calls are placed, and as far as I ca deduce, it adds an extra call everytime the call leaves VTO and is put back on again.

I have put DCID into the formula, but this hasn't made a difference.

Any suggestions?

[tony]

Hi JTL,

It could be one of the following;

Your calls may be "tromboning" on the Switch, through Treatments on your VTO.  That is; interactions are being accepted via the first RP/CDN, after being allocated a ConnID then sent to VTO and then moved outside of the Switch and represented at the same RP/CDN with a new ConnID.  In this way, the monitored RP/CDN would see each and every interaction as a new interaction.  You may want to check what Treatments are being performed on the VTO, to see whether there are any interim steps/moves to any other CDN's, ACD Numbers or any other type of Switch-orientated Extension (inside and outside the local Switch) and then ensure that these Extensions are also registered/monitored via your TServer.

Your calls may be being treated through your ACD or Switch, through an unregistered CDN.  Check that your CDN's are not being Treated in any way by any other routing methods, outside of Genesys URS and/or VTO.  This can cause calls to be removed and then represented to the CDN, which gives the effect of presenting a new call, each time.  Check with your Switch/ACD guys if the CDN's have any routing or rules/vectors applied to them, that you may not be aware of.

Hope this helps!

Tony

[JTL]

Tony,

Many thanks for your response.

The calls are not tromboning, but (as I understand it, I didn't set VTO up!) are routed to the VTO extension where the treatment is played (controlled by Genesys) and then back to the CDN again.

The CDN is presumably seeing these calls as transfers, so is treating them as a new interaction. As I have already configured DCID, I expect they must be presenting with a new ConnID, unless that part of Genesys doesn't report how I would expect.

The treatments on the VTO are simply to play announcements, and by definition, these ports / extensions are configured and monitored within Genesys.

I just want 3 statistics for these CDNs / RPs...

a) Number of calls Entered
b) Number of calls Answered
c) Number of calls Abandoned

Now, I'm already having issues with both Entered and Abandoned, since Abandoned won't increment at all, as the call is deemed to have answered... but I can at least work around this if I get a true value for Entered!

[tony]

OK....

It could be that each time a Treatment section of your VTO is completed, the call is sent back and thereby re-enters the CDN.  If that is the case, it would depend on how many Treatments are applied through the VTO and how many times the call is forced to re-enter the CDN...

I'm rusty on VTO - perhaps there is a way to ensure that calls which pass in/out through various Treatments are not recounted...  But for that I would also need to check the Treatments themselves... I don't think that there is a way to export VTO Treatments (?) so, if you have a relatively simple set of Treatments, perhaps you could screenshot them, for us to take a look..?

Tony

[bcyk]

The problem is highly caused by the second call leg (new connid) in call transfer!

See http://www.sggu.com/smf/index.php/topic,2034.msg11246.html#msg11246 for relevant discussion; portion of thread is extractd below. IT IS ASSUMED that Genesys URS is used.

Each time VTO call is being returned to RP/CDN, the (new) transfer connid arrvies BEFORE the original connid; thus, CCPulse considers it as new enter calls.

Suggested actions:
    1. implement the small patch below in the very beginning URS strategy
    2. for Virtual Queue statistics, nothing to be changed
    3. for RP statistics, the second call leg (from VTO extension to RP/CDN) with new connid still exists
        -> workaround case 1: caller  ---> PABX --> RP/CDN --> VTO ---> RP/CDN -->.....
                                                                                  +---> ready agent
              - there is no other call entry to the RP/CDN
              - exclude the event with Call type = Consult
        -> workaround case 2: there are mulitple entries to RP/CDN, e.g, overflow, ....
              - real call and VTO->CDN call cannot be distinguished by call type
              - filter statistics by customer KV pair


regards






-----------------------------------------------------------------------------
An important "step" MUST be catered in URS strategy for consult call type.

Assuming that inbound call is answered by IVR and then transfer to CDN/RP, route_consult_call option must be set to true. There must be some reasons for Genesys to have this option default value as 'false'.......

It is suggested to have below or similar code segment in URS strategy to handle consult call type; otherwise, unexpected results may occur
          - false/stuck waiting calls in CCPulse (as experienced in 5.1; not observed in higher version!)
          - missing KV-pairs
          - dropped call

{ delayTimer = 200 }
{ loopMax = 5 }
{ loopCnt = 0}
{ if CallType[] = Consult } --> delay(200) --> {loopCnt = loopCnt +1} --
        |          --> { if loopCnt < loopMax} ==( go to the if CallType[] = Consult block}
        |                        |
        | <---------------+
        |
{ ... next block ...}

Values of delayTimer and LoopMax here are example only; they depends on call transfer method and switch method (i.e., how fast to complete transfer).
Transfer method refers to single-step, mute-transfer, two-step transfer by machine or two-step transfer by agent (e.g., attended transfer).

Above values should work in most environment; maximum wait time is set to cater attended transfer call by agents.

------------------------------------------------------------------

[JTL]

Thanks for that...

I tried all manner of working around the idea of filters, including trying masks etc., but without success.

One of the first attached data pieces we use is "CDN", so I setup a test strategy and put a filter on (using the "~") to check to see whether "CDN" was attached.

Using this filter within CC Pulse now generates the correct number of "Calls Entered", which is great.

It leaves me with 2 other problems though (doesn't that always happen?) because all calls are shown as "Answered", there is no way to get a "true" (Agent) Answered call (per route point) on the RP view, as the answer event is sent back from IVR or VTO, regardless of agent interaction. Likewise, it is virtually impossible to "abandon" a call on the RP, so both the "Answer" and "Abandoned" figures which the customer wanted will be impossible to achieve.

But thanks a lot for your suggestions, your input was very useful!