Best Practices for Opening TAC Cases
A guide on initiating TAC cases for Cisco customers emphasizing issue identification, detailing, and prioritization. Tips on providing specific information upfront to expedite troubleshooting and assigning the correct engineer.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
TAC SRs Initiation Best Practices A non-exhaustive list to serve as a Best Practices reference for Cisco customers before/while opening TAC Cases 3 I s to Customer Success 1. Issue Identification and Definition 2. Issue Detailing 3. Issue Prioritization
Issue Identification and Definition Not only important to provide information to TAC engineer for troubleshooting, but equally important to be able to reach through a TAC engineer timely and hence get a prompt response as needed. Identify the category (start with a high level) to define the issue and keep breaking down till we know the root problem. Simple logic: Identify issue -> Define issue -> get TAC to help
Issue Identification and Definition Try to close-in on the issue as much as possible and have the information upfront while opening the service request and document it as specific as possible. From the results of the above, ensure to choose the appropriate attributes (technology and sub-technology) while opening a case to avoid any misrouting delays. For instance, if the issue is on a distributed platform, on a specific line card, try to fill in information based on actual feature/technology in question first (NAT, Routing, Spanning- tree etc), then the interface type (Gig, POS, T1 etc) rather than just focusing on ONLY the platform or ONLY the feature. Being specific would help us get the correct engineer assigned to you much faster saving crucial time.
Issue Identification and Definition Few examples: Issue#1 MWR2800/3800/1800, which is primarily serving as mobile wireless router Issue#2 : Issue with ATM/POS SIP/SPA on 7600/6500, not related to any layer2 feature : Issue with T1 card on INCORRECT choice while opening a TAC case: Technology: Lan Switching Subtechnology: 7600 SIP/SPA Module - layer 2 Issue Problem Code: Error messages, Logs, Debugs INCORRECT choice while opening a TAC case: Technology: Wireless Subtechnology: Wireless Interfaces on 1800 Modular/2800/3800 Services Routers (ISR/HWIC-AP) Problem Code: Error messages, Logs, Debugs Integrated CORRECT choice while opening a TAC case: Technology: Lan Switching Subtechnology: 7600 SIP/SPA Module - WAN Issue Problem Code: Error messages, Logs, Debugs CORRECT choice while opening a TAC case: Technology: WAN Subtechnology: T1 Problem Code: Error messages, Logs, Debugs
Issue Detailing Have basics facts ready upfront and documented as much as feasible: (8 Ws to start work) 1. Worked before or New setup ? 2. When was the failure first observed ? 3. What were the last changes ? 4. What was done to restore ? 5. What was working and what was not ? 6. What is the current status ? 7. Whether the issue is reproducible ? 8. Whether relevant logs, debugs, outputs are attached ?
Issue Prioritization Ensure due diligence while deciding on the priority of SR. If the issue is critical and requires an engineer on call within 20 minutes from the time of opening the case (for instance a Maintenance window or conference call is scheduled), it would be better to open a Severity 2 instead of severity 3 case and have the engineer with you right away to avoid any delays or last minute rush. If the issue is critical, but you re NOT able to provide access OR able to work on webex OR call with the engineer, Priority 1/2 setting won t help. Ensure engineer is aware of the business impact so that he can timely involve more resources if situation demands.
