re cases when the previous ticket is nicely documented, the engineer is even able to find troubleshooting commands as well as specifics on how to solve the customer’s issue.
Escalation engineers are usually the best resort for the TAC engineer but, given the ratio of escalation persons to TAC engineers, a TAC engineer will ONLY reach out to his escalations when he doesn’t know the answer, or is unable to locate a Cisco document that would solve his issue and is not able to find a similar previous ticket or at least a previous ticket with valuable and relevant information. Topic tool, however, is at the TAC engineers’ disposal at any time and readily available with a tremendous amount of information. The real challenge is being able to search for the information you need and be able to find the answers you want on topic in the shortest time possible. The goal is not only to solve a case but to solve it quickly.
Experience has shown that the more information added to the topic database and the shorter the time required to find that information equals the shorter the resolution time. This enhanced the overall customer’s experience with TAC. In some cases, the customer is a person with more experience than the TAC engineer himself but they still call in with a firm belief that their issue will be resolved because they know that a TAC engineer has the resources and will be able to find the answer from a previous ticket, filed notice, or a documented bug, all of which reside on our topic database. Out of all the resources available for TAC engineers there is consensus among TAC engineers that they get most of the answers to resolve their cases from the information found on the topic tool.
The goal of this proposal is to make topic search a richer tool by adding more information to it, hence enabling TAC engineers to find solutions to a wider spectrum of issues. Based on my investigation, research and discussions with other engineers I found that an engineer