ICM Scripting - Dynamic Call Type?

Unanswered Question
Apr 1st, 2008

Hi All,

I'm facing a scripting problem on ICM 7 which someone else might already found a solution before.

I need to create a script that collects various inputs from the caller with microapps, performs a DB lookup, changes the call type based on the previous inputs and sends the call to a queue based on caller input and DB content.

Changing the call type is a management requirement for having granular Webview stats on call handling.

My problem is that I have no idea how to implement this in a nice way.

I'm expecting having hundreds (maybe thousands) of call types, so adding IF+CALLTYPE nodes for each one of them doesn't seem to be an option.

Returning a label dynamically generated by the script and triggering a second queueing scrip by that is problematic as well as I need to preserve information from the caller.

I wish there would be a dynamic call type node.... or a way of accessing call type as a variable with a SET node.

Maybe this should be approached in a completely different way. I don't know.

Any thoughts on this would be greatly appreciated.

Thanks,

Attila Dancso

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
platkeet Wed, 04/02/2008 - 07:15

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.

adancso Wed, 04/02/2008 - 07:28

Thanks for the detailed answer,

I had a feeling that there isn't an easy way doing it.

I use hundreds of call types for reporting purposes. I always choose to map PV10 at the same time as I change the call type. This is just done so I can later say "if call type == x". Since you can't branch off the call type, as you know, I check PV10 instead.

I make the call type string and the value of the PV10 exactly the same so it's easy to follow and not confuse myself.

I have some paths that reset the call type 7 times as more information is applied to the call. For example, all calls from customer service, calls from a certain country, calls from a certain region of the country, calls with different DB lookup characteristics, and finally a queuing call type for ASA, abandon rate etc (in IPCC).

These nested call types provide a rich set of peg count statistics. Being able to branch off (effectively) a call type enables you to funnel calls back to a central distribution script (after say DB lookup) which is great for monitoring.

Regards,

Geoff

adancso Mon, 04/07/2008 - 01:06

Geoff,

thanks for your tips on the PV trick on checking call type value in the script.

My major concern is however that I'm going to end up with a script with hundreds of IF + Call Type nodes in this way:

IF(X) - (T) - Call Type = X

|

(F)

|

IF(Y) - (T) - Call Type = Y

|

(F)

...

If there was a dynamic call type change option, than it would be just only a single dynamic call type node.

Attila

Actions

This Discussion