Life is grand. Your data center is running on all cylinders. People are using the computer system as it was designed. You have your feet up on your desk listening to your Bee Gees 8-track tape. Then, out of the blue, you get beckoned to come down to the warehouse because “something just isn’t right.” Of course, the call came just as Barry Gibb was hitting the high notes, so you already have a little chip on your shoulder.
You trudge down to the warehouse and talk to the culprit, because you just know it was his fault. HE did something – sat on the keyboard, hit 5 keys and a bunch of special characters at the same time, spilled water, did something that is not humanly possible. Whatever it is, he did it. You take a deep breath, and start asking questions. As you inquire, you realize that he wasn’t entirely at fault. There was a hidden “feature” in the software. Under normal circumstances, this “feature” would probably never see the light of day. But, since your company does these particular procedures on occasion, “surprise, surprise” – you win! Your prize? You get to call tech support to report the problem to a tech support line that may or may not be in the same time zone as you.
In any case, it is your duty to report the issue that made your call necessary, and all the steps leading up to it. Be prepared: have the information at your fingertips so you can explain the issue in detail when asked. It is so much easier to gather the information in advance, than to end up calling multiple times, in which case you may end up running into even more delays such as limited availability or wait times (“Due to the unusual amount of support calls today, you are the 259th caller. Your estimated wait time is approximately 2.5 years…”).
What do you need to know before you call? First off, how did you arrive at this bug/issue? What steps did you take/run/choose? Which versions and releases of the software, hardware, firmware (any applicable) are you using? Which version/release of the operating system are you using? Get the serial numbers of each piece of hardware that is involved. Document everything you can think of – you are far better off calling with too much info than trying to run back and forth, especially over multiple calls.
Now comes the fun part. After you have established the case with tech support, you finally get a response. It could be an easily solution, or it could be something else, like one of my all-time favorites, and I am sure yours, too: “hmm…we’ve never seen that before…” or a variation, such as, “hmm… well, that’s unusual!”
Granted, quality testing is quite involved in most software, and the software provider cannot test for every situation, but it is frustrating when obvious situations or not-so-unusual usage brings about errors. I have been on both sides of the call, and I have had my teams test every situation we could think of, but things sometimes act differently in real-world environments. It’s no excuse, but I take it into consideration when I need tech support. What it really comes down to is that both patience and knowledge are needed when placing and answering tech support calls. Get your point across accurately, and make them aware of the urgent nature of this issue, and you will find that the stress levels will be more manageable. Most importantly, you are more likely to get an effective and useful solution.
