I understand the dilemma. Call type instrumenting of your scripts and subsequent call type reports are really aimed at the customer experience.
I have used the following concepts - not pushing my views, but see what you think.
I have three types of call types:
1. Entry call types
2. Segmenting call types
3. Queuing call types.
I like to attach all the dialed numbers for a "line of business" to a single call type (say US_E_CS - I use the "_E_" in the name as a naming convention) and schedule this against an "Entry" script.
I would rather bring all the dialed numbers for a specific line of business through a single call type attached to the "Entry" script (also part of my naming convention for the script) and then examine the Dialed Number to peel off calls, setting a "segmenting call type" so I can count these.
Other script writers may set up different dialed numbers associated with different call types and bring them through one, or several scripts, but I don't like this as much. I like to have a single entry script for the business and then partition the call using a call type and a "go to" script. This enables the monitoring of the script to give a complete view of the calls for the business - I can look at just one script in monitor mode and get a complete picture of the incoming traffic.
The entry call type reports only numbers (not ASA, abandoned rate, service level etc). All calls will "overflow out".
As the call travels through the various scripts I use call types to report on further segmentation of calls, just aiming to get numbers. For example, you have a call type for all calls entering the specific business script, then a call type for holidays, a call type for after hours, another call type before DB Lookup (say) and further partitioning. Many of these call types will overflow out, although some will end the call (play the holiday msg and release).
Finally you reach a script that is going to terminate the call with an agent. In my experience, you want to set a call type at the top of this script - I call this a "queuing call type". This type of call type can never change to another call type - it is the last in the squence. No matter how complicated the scripting below this point - including multiple skill groups, use of overflow, use of RONA etc. I will not change the call type.
The reason is that the queuing call type will accurately show ASA, abandon rates, service level and so on. No matter what happens to the call while it is queued, we will know the really important service data. If I were to change the call type, I would lose an accurate view of the customer experience - which is what the call type at the end of the line is measuring.
This method is accurate but does not help you do what you want. This has been recognized as an issue and Cisco have introduced new tables for 8.x that John mentioned above - call type/skill group associations - that may solve your problem.
Instrumenting scripts with call types for reporting is a tricky business and if you have multiple queuing call types in a single script - as you are describing - it is difficult to get an accurate view of the customer experience. Cisco presented a session on this very topic at the last Cisco Live in Vegas.
Regards,
Geoff
