Handling Tech Support Interaction Effectively

Network engineers deal with technical support frequently. That’s the nature of the networking business: the products often don’t work as advertised or break down under their own complexity. Throw in some ambiguous documentation that leaves you scratching your head, and you’ll finally resort to opening a case with the vendor to resolve the issue. In theory, the vendor’s crackerjack support team will come up with a resolution to your quandary. You might think of them as the oracle – the mighty ones on high who have the big answers to your difficult questions. In real life, this is not always the case. In fact, I think it’s better to go into a tech support exchange a bit defensively. To keep your guard up.

One consideration is that no matter what tech support tells you to do, ultimately, *you* carry the burden of responsibility for carrying out their instructions. Therefore, each bit of advice, recommendation to upgrade, and request to run a diagnostic tool comes with an asterisk next to it. That asterisk references a footnote that says, “Sure. Do what I say. But if it craters your data center, it’s not my fault.” And in fairness, how could it be? How could a tech support engineer know enough about your environment to be able to recommend any particular action with 100% confidence? You must take the responsibility of understanding exactly what the support engineer is asking you to do, and then making your own determination regarding potential impact. An attitude of, “I trust them. They’re tech support. They’re supposed to know. That’s why we pay for it,” is insufficient, in my opinion.

Why would trust in a support engineer be misplaced? Well, not all tech support engineers are equal in experience or ability. Therefore, you just don’t know what you’re going to get. Recent experiences of mine have demonstrated engineers with expansive and intimate product knowledge who were a joy to work with, as well as engineers whom I’ve had to nudge shove to get going in the right direction. Assume nothing. You could be talking to a product genius. Or you could be talking to someone who just starting taking calls yesterday.

Let’s assume that after working with an engineer that you have no confidence in them, however they might have earned your mistrust. What can you do about it? The simplest thing you can do is ask for an escalation. Most service organizations I deal with have a policy that supports this. Certainly this policy could be abused by customers who reflexively ask for escalated service no matter what the issue, but in the few times I’ve requested escalation over the years, I’ve always gotten it. What does escalation accomplish? Ideally, your issue is moved up to the next tier of support: from first level to second level. When reaching escalated support, you should be dealing with an more seasoned engineer who has seen more issues, deeper knowledge of common customer problems, and potentially access to lab gear to replicate your issue or vet ideas.

Even if you’re dealing with the greatest support engineer your vendor has, there’s a burden on you to articulate the problem to them clearly. Your chances of talking to the right engineer and that engineer knowing how to deal with your problem improve greatly if you’ve given them the right information.

  • Create the proper context. Did this problem happen after you did a software upgrade or unexpectedly? Does the problem show up consistently or sporadically? Is there one user with the issue or a thousand? Are there unique circumstances that might be relevant (such as an unusual user OS, the fact that you’re being DDoS’ed, one power supply in the device is fried, etc.)?
  • Use detail to articulate the problem. Don’t say “high availability is broken”. Say, “We noticed that our HA is broken because the primary and secondary units are complaining about blah in the log entries, which I’ve attached. We also had both boxes go active, and had to shut one down to restore service. We verified heartbeat and all network connectivity, so we’re stumped. Please help.” And if you got into a specific problem even more deeply, don’t hold back. Add all the information you gathered. “Here’s a packet capture that shows the issue I’m describing. Take a look at the HTTP session starting at packet 58, and then compare to this other capture I took when things were working right.”
  • Anticipate what else the vendor will need to start reviewing your issue. A simple network diagram with device IPs might be helpful. Logs relevant to the issue along with device configuration is probably useful. Cisco usually wants the output from a “show tech”. F5 usually wants a “qkview”.

The last point I’ll make is that you need to keep up with your open cases. A sad reality of modern tech support organizations is that often they’ll close tickets, even if unresolved, if they wait too long for you to respond to a question. If your case isn’t urgent and you’re busy (aren’t we all), you might skip updating a ticket for a day or so. I find that you need to stay in touch, or risk having to start the process all over again. Twice I’ve had cases closed on me because I didn’t touch a ticket that was waiting for my input in a 24 hour period. While I find this practice to be horrible customer service, that’s increasingly just the way it is. Therefore, if you open a case, be ready to put the time in to get it resolved quickly, even if it isn’t an urgent matter.

Ethan Banks
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
Ethan Banks
Ethan Banks
  • Yostie

    When I create TAC cases, I usually am very detailed with the problem description as well as background on the network such as versions of code, devices involved, network diagrams if I have them, etc. What annoys the hell out of me is when I take 15 minutes to write up all this stuff and the engineer asks a question that is already covered in the information I opened the case with. Grrr…

    • http://packetpushers.net/author/ecbanks Ethan Banks

      An all-too common occurrence, true. I have run into that exact issue many times, although sometimes it seems to be the fault of the infrastructure, and not the support engineer. I’ll upload a file, and they won’t see it on their end until the magical sync unicorn rides in and cries on the database.

    • Alex__Clark

      That is one of the reasons I actually prefer to open TAC cases via an automated text system or email. I have found I am better at explaining in detail with IPs or even attaching a very basic diagram rather than orally communicating a detailed system. Also, always assume the TAC engineer will need to know all serial, model and licensing information and gather it prior.

  • Tyler

    One _major_ problem that isn’t addressed here is the language barrier that often exists when opening TAC cases. I can articulate a given problem perfectly to a peer, but it is made much more difficult when trying to explain the problem to a TAC engineer in most cases–either they don’t understand how I’m explaining it or (more often) I have trouble understanding what they are saying due to an accent.

    • http://packetpushers.net/author/ecbanks Ethan Banks

      That’s a fair criticism which also crossed my mind, but I ended up leaving the point out of the post because I feel that language barrier is a universal problem not only in IT/tech support, but in the global marketplace in general.

      Companies who primarily do business in English farm out work to businesses housed in countries that do not. In addition, folks who have immigrated or are in an English-speaking country on a work visa are employed locally, but do not speak English very well. Therefore, they are often hard to be understood, even in person. In my “day job”, I work in a business park filled with technology companies. It’s common to hear people talking on their mobiles in the hallway, speaking a language other than English.

      While I still find the language issue frustrating at times, I’m “over it.” I try to anticipate the challenge of interpreting poorly spoken English, and muddle through it. I also try to keep my communications simple and straightforward to avoid the chance that what I’m saying will be misinterpreted.

  • Nuno

    Good article. It is indeed our responsibility to probe and understand the impact of the instructions they give us. We shouldn’t blindly execute “debug all” on a Cisco router because they tell us to. I also call support *hopeful* that I’ll get someone good, but I’m prepared to get someone that’s subpar.