Reporting on 'waitsec' accurate for first answer?

[AIC2000]

Hi,

I'm trying to figure out the best way to report on the inbound answer time, after the caller has selected an option on the IVR. Is 'waitsec' the total time that a caller spends on hold in the queue? Or it is the time they could spend listening to the IVR too? Does 'waitsec' add up during call transfers etc too?

Thanks in advance for any pointers

 

[AIC2000]

Hmm digging into this deeper, I've found the following columns within Postgres:

cc_queue_joined_epoch
cc_queue
cc_agent
cc_queue_answered_epoch


The difference between cc_queue_joined_epoch and cc_queue_answered_epoch isn't that different to the waitsec on most of the calls I've looked at.

Does anyone know if waitsec is just the time spent waiting in a call centre queue? Or can that be added to if the caller is put on hold / transferred to a different queue later?

Thank you

 

[Adrian Fretwell]

I think waitsec is another term for Post Dial Delay (PDD), i.e. the difference between the created time and the start of ringing.

 

[AIC2000]

Hi @Adrian Fretwell thanks for the reply.

I doubt it, as that comes in at minutes (many minutes) sometimes - and tends to match up with the difference between cc_queue_joined_epoch and cc_queue_answered_epoch.

The difference in those numbers are small (a second or two) so that definitely points to being added in as PDD.

I may be wrong though. Is there any hidden documentation or knowledge about this? I need to know how waitsec is calculated, and whether it's added to on other variables other than just the queue times.

The information I'm after is basically how to calculate how fast a call is picked up on average, after joining the queue.

 

[Adrian Fretwell]

I don't know the answer to this but I will do some digging later today. It could be that waitsec is treated differently in the call center environment.
waitsec is mentioned in the FreeSWITCH documentation for CDR accounting variables but the information is incomplete:
https://freeswitch.org/confluence/display/FREESWITCH/CDR+and+accounting+variables

 

[AIC2000]

Great, thank you for your help with this @Adrian Fretwell
I am struggling to figure out the best way for call logs to be analysed to figure out how long they spent queuing before being picked up. I'm thinking it has to be the cc_queue_joined_epoch and cc_queue_answered_epoch fields - however not sure if this relates perfectly to 'waitsec'

 

[Adrian Fretwell]

OK, this is not an authoritive answer it is just based on what I can work out, others may be able to clarify further...

On a normal non call center call the waitsec is the same as the Time to Answer (TTA) (answersec), i.e. the time between the initial ringing and the call being answered.

On a call center call, waitsec behaves differently, if the caller hangs up or the call ends up at the timeout destination waitsec will be zero. If at the time of the inbound call an agent is available then his phone should start (ring_all strategy) ringing, when answered waitsec is equivalent to the ringing time of the agents phone. If an agent is not available then the queue will wait for an agent to become available and then (after a small delay) start ringing the agents phone, if answered by the agent, then waitsec represents the time spent in the queue plus the time the agents phone was ringing.

 

[AIC2000]

Hi Adrian,

Thanks for the informative breakdown.

I've pulled some stats from the DB, and can confirm that waitsec in a call centre scenario is a combination of different wait times - which does correlate with what you're saying.

It's also so inconsistently used across the different ring strategies or call flows that it can't really be relied upon for operational efficiency / strategy / performance reasons.

From what I've found, the v_xml_cdr table within the fusionpbx database has the following columns:

cc_queue_answered_epoch
cc_queue_joined_epoch

Therefore doing a:

(v_xml_cdr.cc_queue_answered_epoch - v_xml_cdr.cc_queue_joined_epoch)

gives us the "Seconds in queue" result I'm looking for I believe.

Hope that helps (and is right !)

Thoughts welcome.

Thanks again