Hello Attila-
I faced a similar situation at a customer site that used custom TDM VRUs and ICM. The customer was looking for extremely detailed reporting information on call disposition, based on callerID and options selected in the VRU application. Additionally, after the VRU performed a mainframe database lookup, the VRU would include the lookup results and other related information to the ICM in the RUN_SCRIPT_RESULT message it sent when the VRU app was complete. (That information was also passed along via CTISVR to a CRM application.)
While designing the solution, I anticipated that these reporting needs would only become more complex as time went on, because the site had very little information of this type available prior to implementing ICM. (Once the information is available to users, experience has shown me that other users and managers succumb to 'report envy.')
After examining the different scripting options, we elected to use a combination of PVs and ECCs, and a custom reporting solution that leveraged the TCD and TCV tables that we would export from the ICM.
There is no way to assign a call type dynamically using the ICM product, nor could we trigger a DB WRITE of some kind to an external table using the ICM or the SCI layer with the TDM VRUs. Additionally, in this customer environment, bouncing the call back and forth between the source ACD and the VRU and back was limited to a total of three 'hops,' so the re-routing scenario you described in your post would not work for this customer either. An Application Gateway-based trigger to write to an external DB seemed like overkill, and would require custom development time.
Since the combination of call disposition and caller behavior in the VRU application resulted in (potentially) hundreds of different call types, and ICM scripting for call types is not dynamic, we concluded that using Call Types to track these items was not going to be practical, and would also present an insurmountable maintenance challenge.
The only other logical location for this information was the TCD or TCV tables, using PVs and ECCs set by ICM and the VRU during the SCI dialogue.
The challenge with the PV/ECC approach was that the standard WebView reports don't expose the PV or ECC variables, so custom reports were required. We first developed some reports using the Sybase InfoMaker product suite and were successful, but the product was difficult to use-and there aren't many folks out there that have worked with it.
We instead went with a Microsoft Reporting Services implementation on a SQL2005 server, and found that the .NET development environment for these reports was much less troublesome. The RS implementation allowed the customer to develop their own custom reports using a familiar tool set, and offered the flexibility that the Sybase tools did not.
We export the ICM's Termination_Call_Detail and Termination_Call_Variable tables nightly (along with most of the half-hour tables) to the RS server. (This is a Cisco best-practices requirement-queries to the TCD and TCV are resource-intensive). It's not an immediate, ad-hoc reporting environment, but so far, it has worked very well with this customer.
Any additional layer of caller classification would simply require an additional PV or ECC variable, and the reports could be altered to accommodate the new classifications. If the additional PV/ECC information does not affect call routing, then the ICM scripts don't have to change, either-the new PV/ECC is just included with the others when the call ends and the call is written to the TCD and TCV tables.
Please rate helpful posts.
