(Figure 1)

Classification schemas usually are tiered from the general topics to the specific details. For example, in the above model, a user could classified a call as

Technical Issue» Hardware» Desktop » Video

for someone who is experiencing issues with their system video specifically relating to the hardware device that provides the video functionality.

Important Considerations

Due to the design of validation constraints within HEAT systems and the common methodology of creating cascading fields; it is important to note the usage of syntax regarding the design of your fields. Typical, the design uses the word as the constraint within the cascading field structure; this design concept limits the tiered structure if using the same descriptor for multiple tiers.

To clarify this shortcoming, Figure 1 would not constrain the system from displaying the data from one branch to another if the same field name/data is used as the constraining field. Thus, if a user defines Technical Issue » Hardware and Service Request » Hardware the menus below the Hardware choice would not be constrained by the parent and the menu displayed to the user would include all choices available to ‘hardware’. An abbreviated example (Figure 2) is shown below for reference.

Tier 1	Tier 2	Tier 3
Technical Issue	Hardware	Desktop
		Laptop
		PDA
		Equipment Move
		Employee Set Up
Service Request	Hardware	Desktop
		Laptop
		PDA
		Equipment Move
		Employee Set Up

(Figure 2)

However, there exist three primary schools of call classification design:

1. Unique signifier for child fields

This provides for unique sub-levels, however, this limits the reporting because Service Requests no longer contain the descriptor ‘hardware’.

Tier 1	Tier 2	Tier 3
Technical Issue	Hardware	Desktop
		Laptop
		PDA
Service Request	Facilities	Equipment Move
		Employee Set Up

(Figure 3)

2. Parent signifier within child fields

When designing the call classifications, some choose to carry the parent fields into the child field to prevent duplication of data across the wrong tiers.

Tier 1	Tier 2	Tier 3
Technical Issue	Hardware (TI)	Desktop
		Laptop
		PDA
Service Request	Hardware (SR)	Equipment Move
		Employee Set Up

(Figure 4)

3. Same signifier across table by using primary keys to provide constraints

This design provides the easiest to use interface for the end-users because terminology remains the same across the different tiers. However, the administration of this method becomes more invloved since the use of backend/blind fields, the primary keys, are incorporated to provide the common named fields for visibility.

Tier 1		Tier 2		Tier 3		Tier 4
PriKey	Field Name	PriKey	Field Name	PriKey	Field Name	PriKey	Field Name
1	Technical Issue	1	Hardware	1	Desktop	1	CD/DVD-ROM
						2	HDD
						3	Video
				2	Laptop	1	CD/DVD-ROM
						2	HDD
						3	Video
				3	PDA	1	Blackberry
						2	Palm Pilot
2	Service Request	2	Hardware	1	Equipment Move
				2	Employee Set Up	1	Cable Drop
						2	Request System

(Figure 5)

The Field Name is used to show the various accounts of values required for reporting purposes; whereas, the PriKey field would be used to provide the constrain to the validation. Thus, using our intial example:

Technical Issue» Hardware» Desktop » Video

The validation constraint would be:

1» 1» 1 » 3

This would be the unique identifier for the call classification.

Recommendations

1. In conjunction with available resources, a call classification schema should be developed for the service desk / help desk by the managers and key participants involved in the project. Items to be examined should include the number of tiers needed and whether the classification schema will meet reporting requirements. Determine if the lower tiers need requirement of data, as the example above the “tier 4” would not be required whereas “tier 1”, “tier 2” and “tier 3” would be. Furthermore, some clients choose to incorporate the CallType field into their Call Classifications, it is important when designing the schema to keep this field in mind as it drives the detail screen’s functionality. Typically, when using a multi-tiered system of classification and using the CallType field, CallType would be on a middle level to low level of the tier. A history of issues logged by the helpdesk can also provide valuable insights in developing the call classification schema.
2. It is important when designing the schema that a call can be classified using one tiered path, analysts can misclassify calls if there exist multiple or confusing methods to classify one ticket.
3. Support analysts should receive training in the classification of calls using the schema developed to ensure proper usage.
4. Second and higher level support resources should also receive training in call classification as they may be required to reclassify calls to reflect the actual source of the issue or create a classification for call closure.