Cisco CRA Software

[admin_2]

I have a dilemna with the Cisco reporting software. I am new to the position of running reports using the CRA software and have received no training. I did not setup the initial configuration so I do not know what all the installation settings are set at.

My problem is when I run different reports that should come up with the same numbers such as call taken during a day or the abandonment rate for a day I am getting different numbers depending on the report.

I need to understand the process of how the call flows from the time it hits the IPCC server until it is answered or abandoned. If anyone has recommendations on how to proceed or what literature is available and would be helpful to read, please let me know.

Thanks,

Doug

[adignan]

This post could run for days if wanted to really get into it. I have been working with IPCCX/CRS/CRA since the beginning and reporting is and has always been an issue. IPCCE 6.0 is supposed to really be much better with reporting and I am hearing CRS (CRA) will also be better with CRS 4.0. However, a couple things. * Also note that the IVR scripting has an enormous effect on the accuracy of the reports. Make sure you carefully place the "Set Contact" (Handled) in all the correct spots in the script. For example, if a user is in queue and they are given the option to "zero" out. You will obviously use the redirect step to send them to a voicemail box. If you do not mark the call as handled, they will show up as an abandonded call in your CSQ and Application reports.

1. Which reports are you talking about specifically?

2. Which fields in the reports are you talking about specifically.

Lastly, read all of the information in the following link (Especially the FAQ section). It gets very detailed into each of the reports and SQL queries run to generate reports.

http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_1/english/admn_app/hist_rep/index.htm

Regards,

adignan berbee

[rhugo]

If you are talking about general call flow with IPCC, here is an overview:

The call flow process for CRS

1. A call is initiated to the Call Manager system. Whether this call came from an external source or not is irrelevant.

2. The DNIS value is presented to the Call Manager via control logic.

3. Call Manager determines that the DNIS value is a route point and is associated with the CRS’ JTAPI account.

4. Call control is subsequently passed to the CRS application via the JTAPI link.

5. CRS determines that the DNIS value is a trigger with certain attributes:

a. A Maximum number of sessions.

b. A JTAPI Call Control Group (CTI Port Group) defining a group of ports for use.

c. A Primary Dialog Group, defining a maximum number of channels for use of this dialog type.

d. A Secondary Dialog Group, defining a maximum number channels for use of this dialog type.

6. If the maximum number of sessions has been reached or, there are no CTI port resources or, there are no available channels in the primary or secondary dialog groups, then the call is immediately rejected and the caller gets treatment from Call Manager.

7. If resources are available then CRS determines that the trigger is associated with an application with certain attributes:

a. A Maximum number of sessions.

b. A script with possible parameters.

c. A default script.

8. If the maximum number of sessions has been reached or there is some other problem with the script execution, then the default script is executed. Otherwise the primary script executes.

9. Upon script execution and the passage of the accept step in the script, the call is then terminated on the CRS machine and script execution continues and it is handled according to the specific nodes of the script.

I know this is a general explanation, but I hope it is helpful.

Good Luck,

Rob H.

[geoff]

I agree with you that IPCC Express reporting is strange. I think that the historical reporting package is useless.

I made several calls to my applications and let them progress in different ways:

· Queued to the CSQ and then abandoned

· Queued to the CSQ and sent to an agent

· Redirected to voice mail - customer chose not to wait but to be called back

· Dropped while in menu but before being queued

There are three reports in the real-time monitoring CRS Admin applet that I analyzed:

· Contacts Summary

· Overall IP ICD Stats

· CSQ IP ICD Stats

I checked the way these worked and Cisco’s concept of “abandoned” is confused.

Contacts Summary

· “Inbound” is accurate – all calls are incremented by this counter.

· “Connected” only counts calls connected to an agent.

· “Abandoned” counts calls that drop in queue and calls that drop in menus.

Overall IP ICD Stats

· “Total Contacts” – only counts calls that are queued.

· “Contacts Abandoned” – counts calls that drop in queue and those that are redirected to voice mail while in queue at the caller’s request.

CSQ IP ICD Stats

· “Total Contacts” – as for “Overall IP ICD Stats”.

· “Contacts Abandoned” – only counts those that drop in queue.

· “Contacts Dequeued” – accurately counts those that are queued and then go to voice mail.

Suggested Strategy

· My suggestions are: don’t bother with IVR Historical Reports.

· Just after the call center closes each day:

o (a) Run the “CSQ IP ICD Stats” report and print the page.

o (b) Run the “Contacts Summary” report and print the page – the only statistic of interest here is “Inbound”.

The difference between “Total Contacts” from (a) and “Inbound” from (b) is the number of calls that were not queued.

The difference between “Abandoned” from (a) and “Contacts Abandoned” from (b) is the number of calls that dropped in the menu system.

[jasyoung]

If you look at this Historical Reporting FAQ:

http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_1/english/admn_app/hist_rep/hradvch4.htm

It explains exactly how all of that works, including how to manually mark a call handled (instead of abandoned) when it is not your intent to treat the call as abandoned.

[geoff]

jasyoung,

I understand that completely. This was being followed in the CRS script where appropriate. I had rigorously checked every exit condition. I did not write the original script at this particular site, and there were exit paths that I had to fix up. Even so, when all call handling was set, the stats are still confused.

What do you consider the word "abandoned" means?

[jasyoung]

Strictly speaking, it means the call was not marked as handled before the script terminated, either implicitly by the ICD steps or explictly with the Set Contact Info step. The typical case of this happening is someone hanging up before getting to an agent or otherwise being serviced.

That's not to be obvious or flippant, but it means slightly different things in different reports. There exist genuine cases of stats being wrong or broken due to bugs or whatever. However, I think that >90% of "my reporting is screwed up" complaints can be resolved by very carefully reading that FAQ.

First, you need to make sure you mark calls handled by hand if you didn't go to an ICD agent and the circumstance under which the call is disposed is one you don't wish to treat as abandonment. It sounds like you have that very well covered.

Then you need to thorougly understand the reports. The abandon stats from one type of report won't necessarily equal the abandon stats from another, because they're calculated differently and are telling you different things. For instance, the IVR Performance report will generally report higher abandon numbers than the CSQ reports, because a caller can hang up before being queued by the script, and thus there is no CSQ yet to "charge" for the abandon.

I'm not sure if you've fully read that FAQ, or just skimmed it and took it as "I need to set the call as handled". It says much more than that. I myself found a careful top-to-bottom reading to be enlightening, and if you haven't read it that way yet, I would encourage you to. I think it would explain the existence and the reasoning behind the different accounting that you've already exhaustively plotted out on your own.

If the solution (or the understanding) of your reporting woes is not found in that document, then you can troubleshoot by adding custom call variables at menu/choice points in your script. When you pull custom call variable reports after that and show specific calls that are being reported as abandoned, you may be able to learn more about what paths in your script are producing abandons. It's also a possibility that the CRA Historical Reporting app is malfunctioning; that FAQ URL also shows what the actual CDRs should look like if you poke through that database with SQL Enterprise Admin or the like. A combination of these two techniques should help you discover if specific calls are truly abandoned and if so, in what branch of the script they were abandoned.

[geoff]

Sorry, when I said "historical reporting package is useless" I meant the default package that just comes with two historical reports. I am not criticizing the extra cost option.