How to make tech support work for you

The tech support contracts you buy along with a new storage system are every bit as vital as any hardware or software component. And thanks to all the newfangled stuff built into storage systems these days, I can assure you that you’re going to need a support contract for more than replacing the occasional failed disk.

Obtaining support resources trained to solve complex problems can be difficult at best. That’s why you have to know how to work the system. Learn how to engage support personnel, and you can save tons of time — and even avoid disaster.

Calling tech support isn’t fun

I can’t say I’ve ever met anyone excited about having to open a support ticket. It’s a last resort that usually means two things:

1. Something is broken.
2. Getting it fixed probably entails spending at least the next couple of hours on the phone navigating through a series of different people you’ve never talked to before and you’re unlikely to ever talk to again.

Nobody likes doing this, but here are some steps you can take to get the right people working on the issue, minimize the time required to resolve your incident, and decrease your exposure to additional problems along the way. Available support resources are tools just like any other — knowing how to use them can mean the difference between a quick resolution and a drawn-out debacle.

The reasons why you might contact your storage vendor’s support vary widely, but they generally exist on a spectrum that runs from noncritical feature-related questions all the way up to the most severe system-down emergencies. Support organizations of all shapes and sizes are fairly good at handling the two extremes of this spectrum, but tend to flounder when left in the gray area in between.

If you’re asking a simple question that doesn’t have a serious time restriction attached to it, chances are you’re going to be pretty happy with the result. The support tech that catches your incident has the time he or she needs to research the question and get back to you when they are able — often while fielding other higher-severity issues in the interim.

You might wait hours or even days for a response, but you’ll generally get one that will answer the question the first time. If you’re just looking for a replacement part, odds are you’ll be on the phone for a few minutes and may even have the part in your hands the same day.

If your whole storage infrastructure has just come crashing down, I certainly wouldn’t assume you’re going to be terribly happy about anything. However, it’s very likely that you’ll get a quick, directed response from your vendor. “Severity one” is usually a flag that allows support techs to quickly escalate your incident, dispatch on-site techs, and take themselves out of incoming support queues until they’re able to get you up and running.

The situation can grow significantly dicier between those extremes. While the increasing capabilities and redundancy found in modern storage devices are undeniably a great thing, they combine to increase the overall complexity of your storage infrastructure. This complexity, in turn, dramatically increases the possibility that any problem you’ll potentially face won’t have a clear-cut cause and probably won’t result in a full system outage that would grant it a high-severity support response.

Welcome to tech support purgatory (and worse)

These two factors can combine to force you into a support purgatory where your incident isn’t important enough to require calling in all the king’s horses and all the king’s men, but isn’t simple enough that a single support tech can make time for it in the midst of other incidents they’re tasked with. Worse still, these unexplained, hard-to-diagnose issues seem to have a nasty habit of spiraling into cascading failures that can often end in downtime if they aren’t resolved promptly.

Just this past week I was working with a customer who uses an entry-level SAN platform as a disk-to-disk backup cache. For some reason, the Web-based management interface that controls the SAN had started to act strangely. The screen wouldn’t refresh every time you clicked a different tab in the management interface, and occasionally it’d take a minute or so to load.

The system wasn’t mission-critical, so it didn’t get much attention. Whatever the problem, it must have snowballed because the SAN went down hard two days later. A full power cycle brought it back up with no problems — the odd management interface problem mysteriously gone.

Fortunately, this system wasn’t particularly important and the downtime had no real effect, but it’s precisely the kind of issue that can really nail you when you’re working with a mission-critical item. If the system administrator had called the vendor’s support (in this case, he didn’t), it would have been logged as a low-severity issue. He might have waited a day to even talk to someone, and once he did, they would probably have collected some diagnostics and gotten back to him the following day — just in time for the SAN to melt down all on its own.

Staying out of purgatory

Fortunately, there are ways you can try to avoid being relegated to support purgatory.

• Call, don’t write. Pretty much every manufacturer I work with has a means to submit support incidents online. This is a great method to get an incident opened for a simple question that doesn’t require a quick response. It can even be an expedient means of opening a high-severity case, but it’s a terrible way to open a case that might not lend itself to a fast resolution. If you call, you’ll generally get to talk to and engage (read: stuck with it) someone right away without giving the support team a chance to play hot potato with your incident in the background.
• Document everything. Log the call time, the call duration, and the name of the person you spoke to for any incident you open — regardless of how simple it might appear to be. If your problem turns out to be more complicated and you find yourself complaining about poor service or broken SLAs a few days or weeks later, you’ll want to have all the proof you need to rattle off exactly what has happened and whom you spoke to.

• Insist on a timeline. Never, ever hang up the phone or end an email exchange without asking for and receiving a very clear commitment on when you will be in contact next. The first thing most support techs are going to want to do is dig into logs and diagnostic reports. This can take hours for a complicated problem, so it doesn’t make sense for you to sit there and wait on the phone while they do it.

  However, leaving them to do that without a hard time commitment leaves them open to work on other issues in the interim. Instead, insist on a specific time (not “in an hour,” but “at 2 p.m. EST”) that they will contact you and provide an update on their progress, regardless of whether they have finished their task.

• Get a case manager involved. If your problem doesn’t look like it’s going to be solved within a day, ask for a case manager to be assigned to your incident. Though this position goes by many different names by different vendors, nearly all vdendors have a staff of nontechnical case managers (sometimes “escalation managers” or “technical account managers”) whose job it is to shepherd a multiday incident and ensure that the correct resources are brought to bear.

  Though these people may seem like a needless addition, as they can’t directly solve your problem themselves, they can be very, very useful if a small problem starts to escalate into a larger one. Because a case manager can assemble the case notes and ensure that the higher- and lower-tier engineers have the time to connect and discuss your case, they can also prevent you from being forced back to square one if you get escalated to a higher-level support engineer.
• When in doubt, escalate. If you feel that the tech handling your case is in over their head or is simply not giving you good service, don’t hesitate to request that your incident be escalated or transferred. Under these circumstances, it’s better to do so with the help of a case manager or the tech’s manager. The tech may be more than happy to give up your incident, but they may not be strongly motivated to make sure someone else picks it up immediately (after all, it’s not their problem anymore).

• Insist on a root cause analysis. If you and the support tech are able to resolve the problem by doing anything that even resembles turning the system off and on again, never allow that to be the last word on the issue. In the storage world, a reboot is not a fix — it’s a failure. Insist on knowing what caused it and what you need to do to prevent it from being necessary in the future.

  The problem you just fixed with a service restart or unplugging/replugging an item may be the leading edge of a firmware problem or a faltering piece of hardware that can cascade into a full-blown failure down the line. The tech probably won’t seem particularly enthused about it, but stick to your guns. This can be another place where case managers can be exceptionally helpful — they often have the ability to request dedicated time on a support engineer’s calendar to deal with these kinds of requests.

• Involve the sales organization as a last resort. If you’re not getting anywhere with your vendor’s support organization, it can sometimes help to involve the poor guy who sold you the thing in the first place. This should only be used as a last resort when the support organization has repeatedly failed to fulfill promises they’ve made and you have clear documentation detailing that fact.

  If you need to do this, ask for an emergency conference call with your salesperson, their manager, and that manager’s manager (you’re generally looking for someone with “regional manager” in their title). Calmly, but forcefully explain that the support you are receiving, if not immediately improved, will impact your decision to buy any more of that vendor’s products in the future, nor will you recommend that any of your peers do so. In other words, threaten to hit them in the pocketbook.

  If you get enough high-level folks on that call, a back-channel conversation — usually resembling a metaphorical brick being thrown through someone’s window — will take place and you’ll magically get the attention you need.
• Observe Wheaton’s Law. Above all else, be calm, direct, and reasonable, no matter how bad the situation. Working with support folks as often as I do and having played a support role in the past myself, I can tell you there’s no better method to get your problem ignored than yelling, screaming, and being nasty. It may seem like a good way to get attention, but trust me — it’s the wrong kind of attention. Being calm, forceful, and very persistent will get your point across much better; will keep the person you’re talking to focused on actually solving your problem rather than figuring out how to get rid of you; and won’t permit them a plausible excuse for ignoring you.

As good as some of them are, no support organization is perfect — your experience with them is unlikely to be perfect either. However, these tips can help you avoid some of the most common pitfalls and speed up incident resolution. If you have any ideas that I didn’t cover here, please let me know in the comments below!

This article, “How to make tech support work for you,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.