CMS call record data collection limit 1

[Coineandude]

Hello folks.

We run an R3v9 CMS. I rely on call record data for some data validation blah blah blah.

My issue is that during our peak traffic times, call record data collection fails with a threshold exceeded error. CMS documentation states that call record data is not collected for periods where call rate exceeds 400 calls per 20 minutes. As we run a predictive dialer, this happens quite regularly.

Does anybody know of a way to bypass this limitation?

thanks for your thoughts,

--shane

 

[marcell55]

The only way to get past that is to purchase a system such as NICE Analyzer that can read ECH data. ECH (External Call History) is a call record feed to another system. ECH is also a pay feature, meaning you have to pay for the license to turn it on in the CMS. Then you would pull your call record reports from the other system. NICE Analyzer uses Explorer to retrieve and display the information.

 

[abacks]

I believe if you purchase the ECH RTU in the CMS it greatly increases the storage capacity for call records. SO maybe you can just purchase the ECH without needing to purchase NICE ANalyzer. The CMS helpline will answer that question for you



Andy Backs
MVD Communications
andy.backs@mvdcommunications.com

 

[doiknowyou]

Good ole predictive dialer, huh? We have an inhouse written dialer as well... works so well, it can kill the switch by dialing so fast if not properly governed.

ECH = NICE/Explorer/Explorer2... or you can do it yourself with ODBC and the db of your choice. Yes, you will need to have ECH turned on. I believe the db will hold 500 records by default which will quickly overwrite if you are in a busy call center environment or have multiple ACD's.
ECH will house all of the successful dialing attempts, but will not record the misses. I prefer the application guys to keep track of their record attempts... that way all of the details are in one bucket, and it's not mine

 

[Coineandude]

We are going with dropping the ECH data to a MSSql server since we already use crystal reports to ODBC other data, it didn't seem cost effective to reinvent the wheel with NICE.

i just wanted to be sure i was spending money that i really needed to spend.

thanks all for the feedback.

--shane