different. The decision to write a knowledge document upon trouble ticket resolution is a vague decision point and usually is made in a way that does not support the goal of your knowledgebase system. As with most quota systems, engineers do not have to write a knowledge document on every ticket, so the reason and content of your knowledge system may not be tightly bound to your customer’s needs.
“It should be evident that any question or issue that a customer opens a trouble ticket on is worthy of a knowledgebase submission. The challenge to be focused on is improving search capability to insure relevance of the search results.”
|
What do your engineers consider when making the decision to write a knowledge solution? Some common answers are:
- If it’s an unusual problem.
- Behind on quota for the month.
- How specific the problem is. Does it easily lend itself to a knowledge article?
- Whether someone will need to know this information.
- Required much research and difficult to find answer, may save steps in future research.
With the wide range of answers above, the reader can see that this decision is made at an individual level and not always customer focused.
It should be evident that any question or issue that a customer opens a trouble ticket on is worthy of a knowledgebase submission. The challenge to be focused on is improving search capability to insure relevance of the search results.
For future productivity and customer satisfaction improvement, support organizations should rollback the mindset that a trouble ticket is just that; a ‘trouble ticket’. What is actually taking place during trouble ticket resolution is the creation of new knowledge; thus a ‘Knowledge Document’ is being created instead.
Most engineers are not asked to record their trouble ticket in a way that is conducive for knowledge documents, long fed the notion that only problems are entered into such transcriptions. In order to begin to move your organization to developing knowledge that can be leveraged, you’ll need to address what is recorded and how it is done. Let’s focus on what should be recorded.
Start with clear, concise problem descriptions. Engineers need to see this as an important function of the document, not just a record of work performed. It should be as thorough as possible using the customer’s language. Engineers should be coached that descriptions the customer is giving is important information of record and ‘translations’ can be added during subsequent entries. Electronic submission systems allow the customer to type their own problem description, so those trouble tickets will have the most fidelity. If the problem description changes, be sure to have engineers update this information in a new entry. The use of ‘text tags’ or XML, such as <probdesc> </probdesc>, can be used to mark problem description entries and may be used by software tools to automatically feed expert knowledge systems. At the end of the problem record, be sure to summarize the problem description again as to what the actual problem was and how it was resolved, marking this with the tags from above. Then add the solution as a separate paragraph and mark it in a separate tag, with perhaps <solution> </solution>. The solution should be as thorough as possible and ‘stand alone’ without unneeded references to other entries, places or things. This is your knowledge record.
“The trouble ticket should be regarded as a knowledge document from the start.”
|
All communication between the customer and the engineer should be recorded such as telephone calls (summarized), emails (copy and paste) and all troubleshooting steps taken by engineers. Keep record of each attempt to solve. You will save engineers time and effort by recording steps that were unproductive.
The tagged entries can be gleaned from the record and inserted for use in a knowledge solution database for customer access. It should also be noted that the ticket system itself is extremely valuable source of information, containing the entire troubleshooting process. Due to privacy concerns, the ticket database should be restricted to ‘internal use only’ since proprietary information concerning customer environments, configurations and networks are contained within. Each of the problem descriptions, including the final problem description summary, should be included as key words into the knowledge record. These are critical search terms and will better help customers to find the appropriate solution to their particular problem.
Developing knowledge is straightforward. The trouble ticket should be regarded as a knowledge document from the start. What most organizations lack is the fortitude to demand good documentation from their engineers, which in summary include:
- Carefully recorded problem descriptions in the customer’s words.
- Record of all troubleshooting steps, including unproductive attempts to resolve.
- Full problem summary and solution at the end, noting all steps necessary to resolve the issue.
By following the above steps, you can begin to transform your support group into Expert Knowledge Developers where the work recorded in trouble tickets is swiftly used to solve incoming customer problems and help engineers quickly find solutions. The human aspect of your knowledgebase system will be capable of higher efficiency, lower turn around time and world class customer satisfaction.
Ken Webster is an ITIL Certified support manager with IBM. He can be reached by email at web@us.ibm.com
|
