" /> Brief description about Total_Talk_Time inbound - Genesys CTI User Forum

Author Topic: Brief description about Total_Talk_Time inbound  (Read 4184 times)

Offline Mat

  • Newbie
  • *
  • Posts: 36
  • Karma: 0
Brief description about Total_Talk_Time inbound
« on: April 30, 2009, 12:10:21 PM »
Advertisement
¿How the stadistic is calculated by Genesys?

Offline ecki

  • Sr. Member
  • ****
  • Posts: 329
  • Karma: 8
Re: Brief description about Total_Talk_Time inbound
« Reply #1 on: April 30, 2009, 12:27:52 PM »
Hi,

Depends on how it is configured. By default it should be the total amount of time that agents were in CallInbound status; that is, the total time agents completed handling inbound calls. This stat type excludes those inbound calls that were in progress at the end of the reporting interval because its configuration is:

Category =  TotalAdjustedTime
Subject = AgentStatus
MainMask = CallInbound
Objects = Agent, GroupAgents, GroupPlaces, Place

How is yours defined?

Offline Gui75

  • Jr. Member
  • **
  • Posts: 99
  • Karma: 0
Re: Brief description about Total_Talk_Time inbound
« Reply #2 on: May 05, 2009, 05:52:06 PM »
[quote]This stat type excludes those inbound calls that were in progress at the end of the reporting interval because its configuration is:[/quote]

So do not try to calculate % from such statistic (by dividing by login time for example) on 15 minutes reports. If you have one conversation lasting more than 15 minutes, you can get a pourcentage > 100%

[quote]This stat type excludes those inbound calls that were in progress at the end of the reporting interval because its configuration is:[/quote]

Well that is not exactly true : if your agent puts the call on hold before the end the first reporting interval and releases the call in second interval, you will have the conversation time before hold in the first interval and the rest of conversation in second interval.

That is just one the many reasons why Genesys StatServers statistics have always been an issue in projects.
That is just why we need some solution like ICON or informart (some doubts remaining on performance issues for intraday)

Offline ecki

  • Sr. Member
  • ****
  • Posts: 329
  • Karma: 8
Re: Brief description about Total_Talk_Time inbound
« Reply #3 on: May 06, 2009, 04:25:57 AM »
:o Quite odd statement.    ??? 

You can configure your stat as you please, it is up to you what you want and how deep is you knowledge about this problematic. I would say that this is the common reason why statistics could be a problem in project delivery. The unknown and lack to understand is always factor causing problems all the time in history.

To the statistics definition, if you take it from perspective how the stat is defined "STATUS" then inbound call from status perspective has ended as soon as new status replaced it. That means the status on inbound calls in your case you described was replaced with on hold status and then again replaced by inbound call status which ended in second collection interval.  Although it is the same call we have two inbound call statuses reported for agent. Therefore the first status time is correctly written within first collection interval and the second again correctly written in the second collection interval, because the stat type definition is "TOTALADJUSTEDTIME".

I really recommend you to thoroughly study the "Reporting Technical Reference Guide for the Genesys 7.2 release" before jumping on another project and causing new issues with stat definitions.  ;)

Good luck,

Cheers,

Ecki.

« Last Edit: May 06, 2009, 05:41:42 AM by ecki »

Offline Gui75

  • Jr. Member
  • **
  • Posts: 99
  • Karma: 0
Re: Brief description about Total_Talk_Time inbound
« Reply #4 on: May 07, 2009, 01:12:29 PM »
Hi Ecki,

1. Put statistics issues on Developer skills/Integrator weakness is the Genesys politically correct explanation.
If there are always issues on statistics, it means (there I agree with you) that you do not have the proper skills to do them. But let's go a bit further. If integrator never finds the proper skills, it is because the system is so complex that they are hard or too costly to get them. So I put the guilt more on the product than the developer.

2. Even Genesys developers have difficulties with it, 1 example :
- Total_Calls_Outbound is a statistic from Reporting Templates. It is supposed to give the number of outbound call. But such statistic is based is a TotalNumber using CallOutbound and AgentStatus. Great! If you put you call on hold, it increments twice...

3. Documentation is not good enough, 2 examples extracted from statserver guide, which is a far more useful guide than reporting technical Reference guide to understand statistics
- Let's go to CallInbound definition (most basic one). Doc says it increments on EventEstablished. Great! What about transfers received by agents?
- What about CallConsult status? According to documentation, it has less priority than CallInbound, However, when the agent makes a consultation call, you will see callconsult status increment...

So you will understand that I maintain my position,

Offline ecki

  • Sr. Member
  • ****
  • Posts: 329
  • Karma: 8
Re: Brief description about Total_Talk_Time inbound
« Reply #5 on: May 09, 2009, 10:55:38 AM »
Hey Gui

Well now I understand you. You are complaining about canned report templates. Yes you are right, they have some illogical statistics, but why are you using them? Because they are very easy to deploy without spending to much energy and money to explain customer what this system is capable of and get from customer exactly what he wants and design proper historical reporting collection?  Still all that is not a reason to say Stat Server and CCAnalyzer is crap, or is it? I am very sorry and please apologize my reaction, but I will never understand whining/position like this. My position is, that product is quite good. Very easy to setup when you know what you want (if project does not cheat this part), though quite complex for maintenance (mostly for very complex reports). So, customer needs to have quite good trained administrator. This are the major weaknesses of this product and reason why Infomart is going to replace it. Not the statistic configuration. But I can tell you now, Infomart is not going to be less complex than CCA. But this is another story.

« Last Edit: May 09, 2009, 10:57:57 AM by ecki »