Call Concentrator

General Discussion
1

We’re looking at adding Call Concentrator to our environment. The

business side of company is slowly starting to realize that call

level detail can be very useful in our environment, but they’re still having “sticker shock” over the price tag. I’m trying to convince them of the benefits of calllevel reporting and that implementing the turnkey solution will be less expensive in the long run with a faster ROI than trying to create something inhouse. If they were able to hear about someone else’s experiences, it might help them with the decision.

Would anyone be willing to provide their experiences with Call

Concentrator, especially:

  1. If you did not initially have CCon in your environment, then added it:

(a) did it meet your expectations?

(b) what pitfalls, if any, did you encounter as part of the

implementation?

(c) has this proved to be useful in researching/tracking/resolving

environment issues and/or caller complaints, compared to before?

  1. If you have an environment where reporting on a related group of

callers (such as a company and its employees) is necessary:

(a) How often do you use this level of reporting? Regularly? On

demand? Never?

(b) Is this level of reporting used internally, or are these reports provided to the external client?

(c) Have you found this level of reporting to be useful in customer

relations? Problem resolution? System troubleshooting?

  1. If you have an environment where reporting on a specific caller

(either call history or a specific call) is necessary:

(a) How often do you use this level of reporting? Regularly? On

demand? Never?

(b) Is this level of reporting used internally, and/or are these

reports provided to the external client?

(c) Have you found this level of reporting to be useful in customer

relations? Problem resolution? System troubleshooting?

  1. What other information would you like to provide about your experiences?

Thank you in advance for your time.

2

Additional question:

If you have an IVR in your environment, do you use CCon for tracking feature usage, such as number of times a menu was selected, how the caller terminated the call, etc? If so, how have you found it to work? If not, why not ? (Procedure existed before CCon, haven’t gotten there yet, etc)?

3

Hi Kevin,

When we put in our 6.5 ERS solution 18 months ago we had purchased CallCon as part of the overall package. This was mainly driven by the technical operational folk who ‘claimed’ it would make problem isolation and tracking, agent tracking and customer call time logging a simple and easy process. Good theory I suppose.

As it turned out we were running short on Database space during the project and because CallCon added no direct Business Value persec, it was decided to just install the applications and leave them disabled in CME. This has not changed since that date, other than the tech team requesting it be turned on every 3 months or so (but when we ask them to sponsor the database space 10’s of Gigs, they go all quiet)

We do use a table that is created by CallCon to collect and report on agent login/logouts, but thats it.

IBM’s CallPath Reporter had similiar features to CallCon from adetail point of view. We turned that off as well, after it used up all the system Database space and CPU.

Can you not use the CDR records from the local PABX? Sometimes they can be helpful, if not too much information is required.

Call Wrap information from an agents desktop is handled by the main business application upon a call disconnect event. All the information is sent directly to a totally different database system to Genesys. Like wise the IVR detailed records are parsed on each IVR to consolidate them and then send to the same database the desktop App uses.

Some of the issue we have with enabling CallCon are:

  1. Can use vast amounts of database space, so very careful planning is needed to size things up. (we normally triple the space needed to accomodate SQL backups and Logs etc)

  2. Has yet to be demonstrated to us that there is any business value in turning it on. ie the business case is weak.

  3. Needs very specilist skills to actually extract meaningful information. We have DBA’s but they are in another division. I would be concerned about letting anyone else loose on the system as it would only take one Select * statement to bring Production systems to their knees.

  4. Because there are no real tools for CallCon, the ongoing maintence requirements are large.

If we need to troubleshoot or search for things we use the various applcation log files (URS, TSerevr etc) as we have added enough general hard disk space to collect them, albeit only 24 hours worth, but even then that runs into Gigs of data.

Hope this helps

Superglide

4

I must side with SuperGluide on this issue. CCon is a tech junkie’s toy of the year… and you end up paying for it.

The major problem with CCon that I have, other that it misses some events (just check release notes and you will see what I mean) is that there is no way to make a use of the information it has in it. It is like having a big log file stored on you computer. Sure, it has all the little events and everything, but you only look at them when SOMETHING GOES WRONG.

I think that the first “c” in ccon actually stands for CLAIM usually you would look at the data there after you get some idiot of a caller who wants to complain that he was on hold for a long time, or that his call was dropped. In most cases, it is CHEAPER and more effective to just take the client’s side and give him some kind of freebie than retrieving the information from CCON, analyzing it, writing up a report and then have your agent call the client and explain.

It is a really nifty toy that we all want to have because it tells you what happens to every call, but… do you really care about it when you have 100,000 calls a day? Even if you did, a sheer volume of interaction will make it close to impossible to retrieve the data and since CCOn table layout is based on DB concept that was used 10 years ago, you cannot use any of the recent database advances to speed it up.

Oh… did I mention that in every call center that I have seen CCon deployed, people used … EXCEL to import data from it? :slight_smile:

So, in conclusion, if you are a data junkie and you like to collect gigabytes of data JUST IN CASE, get it…otherwise, think twice, because from my experience I found that you still have to compare CCON data to PBX I do not know of any client who said:“heck, we do not need CDR we got CCON!”