1 / 7

Best Practices for TAC Case Initiation: Ensuring Customer Success through Effective Issue Management

This guide provides a non-exhaustive list of best practices for Cisco customers to follow when opening TAC cases. It emphasizes the importance of proper issue identification and definition to facilitate prompt responses from TAC engineers. Key strategies include categorizing issues, gathering detailed information upfront, and accurately selecting technology and sub-technology attributes. Additionally, the guide highlights the significance of issue prioritization to ensure timely support, especially during critical situations. Adopting these practices can greatly enhance the resolution process and lead to successful outcomes.

wei
Télécharger la présentation

Best Practices for TAC Case Initiation: Ensuring Customer Success through Effective Issue Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TACSRs Initiation Best Practices • 3 I’s to Customer Success • Issue Identification and Definition • Issue Detailing • Issue Prioritization A non-exhaustive list to serve as a Best Practices reference for Cisco customers before/while opening TAC Cases

  2. 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: • Identifyissue -> Define issue -> get TACto help

  3. 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.

  4. Issue Identification and Definition • Issue#2: Issue with ATM/POS SIP/SPA on 7600/6500, not related to any layer2 feature • INCORRECT choice while opening a TAC case: • Technology: Lan Switching • Subtechnology: 7600 SIP/SPA Module - layer 2 Issue • Problem Code: Error messages, Logs, Debugs • CORRECT choice while opening a TAC case: • Technology: Lan Switching • Subtechnology: 7600 SIP/SPA Module - WAN Issue • Problem Code: Error messages, Logs, Debugs • Few examples: • Issue#1 :Issue with T1 card on MWR2800/3800/1800, which is primarily serving as mobile wireless router INCORRECT choice while opening a TAC case: • Technology: Wireless • Subtechnology: Wireless Interfaces on 1800 Modular/2800/3800 Integrated Services Routers (ISR/HWIC-AP) • Problem Code: Error messages, Logs, Debugs CORRECT choice while opening a TAC case: • Technology: WAN • Subtechnology: T1 • Problem Code: Error messages, Logs, Debugs

  5. Issue Detailing • Have basics facts ready upfront and documented as much as feasible:(8Ws 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 ?

  6. Issue Prioritization • Ensure due diligence while deciding on the priority of the SR. • If the issue is critical and requires an engineer 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 on call 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.

More Related