Most people have called a support, or “Help Desk” and they know that the better ones make a record of each customer contact in a ticketing system.
Tickets are more than automated “called while you were out” systems. On top of reliable ticketing software is the ticketing ‘design’. Service work by nature has many intangible qualities. A good ticketing design is what makes the efforts of a service operation visible, measurable and measurable.
An IT organization can purchase ticketing software on the basis of reliability, scalability, robustness, support and price. The ticket design, however needs to be created in coordination with the operational design for the service business, and modified when the business changes.
The heart of the ticket design is often called ‘CTI’ – category, type and item classification. Tickets are classified for many reasons, including: accountability, service assignment and ticket routing, and metrics.
Well designed CTI systems allow a service tech to classify a ticket into one of a thousand categories by picking one of ten categories, then one of ten types and one of ten items. Of course, this makes so much more sense than searching through a master list of dozens, hundreds (or more) of request types, but this is not the most important aspect of a well-designed CTI!
Poor ‘CTI’ coding can undermine metrics. When you look at tickets from badly designed classification systems, you will typically see a conceptually unusable hodge-podge of symptoms, diagnosis, prescribed solutions, prognosis and follow-up.
Good ‘CTI’ ticket design is difficult. Perspectives on ticket classification change throughout its life cycle. What starts as a call for, say, email assistance actually becomes an anti-virus issue. Agents all too often will second guess themselves, or make too much use of the “Other/Miscellaneous” or “User Error” buckets.
The answer to effective use of ‘CTI’, and confidence ticket classification by agents is not simply “training”. Organizations fighting a bad ticket design can find themselves putting agents through –months- of so-called training before they have confidence that the individual can answer the phone and screen a call.
The answer is not another layer of automation. Another layer of macros or templates doesn’t solve them problem, it simply moves it. Also, correct selection of ‘CTI’ should drive a service organization to templates and standardized processes, and not the other way around. (Templates or macros should be reserved for the ‘Top 5’, or at most: a ‘Top 10’.)
A properly organized ‘CTI’ classification system should reflect the business design. It should recognize that, at first contact, there may not be enough information for a –complete- ticket classification. It should drive the request for service into standardized processes and template solutions, and not vice versa. And finally, it should support conceptually useful metrics.