1 / 7

TAC SRs Initiation Best Practices

TAC SRs 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. Issue Identification and Definition.

wei
Download Presentation

TAC SRs Initiation Best Practices

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