CCA reporting does not match

[Vic]

Hi, everybody,

I am having a somewhat of a rookie problem and I cannot figure out what it is.

I am using 6.5.2 Historical and Realtime Reporting to keep track of all the calls, and numbers do not match. The numbers shown in CCP and the numbers shown in CCA are different by about 10 to 20 percent by the end of the day.

At first I thought it had something to do with time profile, but... we are using the same statistics in both CCA and CCP templates with identical time profiles, so that should not be the case.

Next, I thought it might be ... "# of cleared calls " but then it still does not make sense. Because, if you have CCP open from morning till night then by the end of the day you should have the same number of calls entered, followed by calls answered+calls abandoned+calls distributed to somewhere else...
But it is not... Total Answered+Total Abandoned+total cleared does not match Total Entered. What makes matters wose, Total_Answered is different for CCP and CCA...

Anyone has any idea what is going on?
PBX is Avaya

[Superglide]

Just a thought. We had a similiar problem, but only in CCP, which was caused by consult calls effectivly being counted twice. It relates to intersite call transfers/conferences.

[Tony]

Hi Vic,

Yes we have seen this happen as well, if calls are in an 'unknown' status then this will throw off the total calls entered statistc and will not equal Call answ + call abd + call dist. We have been able to get the data in CCP and CCA to matchup pretty well, but every now and then we'll see things not add up and it is difficult to pinpoint one or two calls out of the 000's we receive daily.

Let me know if you have any luck.

[Vic]

Hi, Tony,

with us, we have about a ten percent discrepancy between the number of calls reported by CCP and CCA.

How do call ype of unknown calls originate?

I also think there might be a bug with Genesys when you have a multiskill agent logged into a queue. Could it be that sometimes Genesys forgets to add CallsAnswered to the right VQ?

Here is what I think:

we are using VirtualAgentGroups based on skill.
Our agents have multiple skills, so obviously they can belong to different VAGS.

In order for Genesys to correctly report queue elated statistics, we have virtual queues from where calls are distributed to that agents registered inside virtual agent groups.
So, for VAG_Skill_English_1 we would have VQ_English registered as Origination DN.

Could it be... that Genesys does not apply DCID correctly to VQs?

I have VAG VAG_Skill_English_1, based on skill English > 0 and < 5,
VAG_Skill_English_2 where English >4 and < 6 and VAG_Skill_English_3 where English >5 .

We have VQ_English in our strategy, from where the calls are distributed to VAG_Skill_English_1, 2 or 3.

When calls enters VQ_English, it is first looking for VAG_Skill_English_1 for 5 seconds. If it does not find anyone, it then goes on to look for VAG_Skill_English_2 for ten seconds and then if it does not find anyone there, it goes to VAG_Skill_English_3.

In all three cases, VQ_English is assigned to the target.

Clear Target is NOT checked on VQ_English_1 and 2 but is checked on English_3.

Could it be that... When call leave VQ_English_1 and goes to VQ_English_2 , the number of CallsEntered goes up even though it has DCID assigned to it?

[Fariborz]

Vic,
Are you using one single StatServer for both CCP and CCA ?
If not, are you sure that the main config parameters are the same for both?
Is the same VQ is assigned to all VGAs as the Origination DN?

Why do not use the gpureh skill based routing (and not the VAG routing), the result would be the same regarding Routing and Reporting. Thatfs what we are using all the time with even more complex segmentation, and we donft have any problem with our reporting.

Else, generally DCID works well.

[Superglide]

Vic, I emailed you a diagram of how we resolved this problem. Hope it helps.

[CTIgem]

I'm having the same issue.
Is it possible to get that diagram to resolve the problem?

[tony]

Wow!  This is an ooooold post!

Perhaps you can tell us what does not match and we'll have a fresh look?  Is it CCP versus CCA?  Which stats don't match?

Tony

[CTIgem]

We are using  CCA (ver 7.1).
Route Point Y splits into 9 VQs.
Adding all VQs calls entered should be equal to answered + abaondoned + short aban?


          Entered Distributed Answered Abaondoned Short Aban
Route Point Y 6033   3095               2902                                 9

X1_VQ             132       0                 0                   8                     1
X2_VQ               7       1                 1                   0                     0
X3_VQ               3       0                 0                   0                     0
X4_VQ               266     262               259                   4                     0
X5_VQ               1928     1706             1700                   223                     3
X6_VQ               48       42               42                     6                     0
X7_VQ               664     625               625                   42                     0
X8_VQ               56       53               53                     3                     0
X9_VQ               7       4                 4                     0                     0
Total             3111     2693               2684                   286                     4

[kowari]

Call flow required!!
How are the VQs defined?  At any time can there be one call in more than one VQ?

However, Sometimes statserver can do crazy things.  I would recommend over night that you restart all statservers involved in this call flow (Routing, CCPulse and CCA) and recheck the stats.

I would also get a thorough understanding of exactly what your stats are measuring on each statserver and whether or not they are measuring the same thing.  The statserver manual is a wealth of information and I really recommend that you become very familiar with its contents (it hurts your brain, but it is worth it)

The other thing I would check for are filters.  Ensure that the same filters are being applied across the board.  And check your objects.  The reason I am recommending the restart is that sometimes statservers drop their connection with config server/proxy and refuse to listen to changes in the environment.  This can stuff around with data collection.

So my steps would be: Clean slate on statservers, check then double check all config, ensure that I understand the call flow and where things would be counted, ensure I understand all stats used and they are counting what I think they are.

GL mate!

[CTIgem]

Call flow is pretty simple.
Once call enters rp, based on flag, calls are branched out.
There will be only one call at each VQ, since it branches out from rp.
These numbers are from canned report not modified in any way.
Therefore stats are pretty much what's in the stat doc.

No filter is used.

will restart stat tonight.

[cavagnaro]

what pbx are you using? At any point you use external music for example? Mean, on target treatment does the call leaves Genesys enviroment or use some script on VTO/GVP for example?
Entered = abandon + cleared + distributed

[tony]

...make sure your ACD/PBX/Switch doesn't have any low-level routing rules set on the DN/Ext that your Route Point is associated with.  I have found that, 80% of the time, it is either the Switch or the Network which "deals" with some of the calls on a Route Point (because it has had a "time out" or a rule has been set to forward/remove calls after a certain period of time) - this type of routing is frequently not captured by the associated Genesys TServer/StatServer, which is a good reason why your stats wouldn't add up...

Tony

[CTIgem]

Hmmm,  I'm not counting calls cleared.
Should I include that?

We are using VTO for music no pbx(notel cs1000) MOH.

I don't think we have low-level routing rules since calls are following strategy as expected.

[cavagnaro]

Yes you should, cleared calls are those who jump from one target to another and can only be seen on VQ, not on RP, so on RP you may have a mismatch because of this, happened to me once.