STFU && RTFM

Having worked on-site support for most of my career, I’ve seen a lot of things that can bug you. There are a few things we can do to make it a little more survivable, such as:
 

• Bring your tools
  • Whether they are hardware or software tools, bringing them shows the client you’re prepared, and puts them at their ease while you work
• Take notes, and lots of them
  • I have more than once needed to explain what I have done, and usually try to document new solutions whenever necessary (more than a few of my blog posts have come about that way). Taking copious amounts of notes allows me to work with off-site techs even if I’m no longer onsite, as the notes show me what diagnostics I have performed, and what results they have returned.
• Take a deep breath
  • When the storm blows around you at its worst, take a few moments to stop and breathe. No one will die from it, and you will be better off for it, working more efficiently, and delivering better results. By doing so, you also allow yourself time to stop and think, instead of biting off the head of the poor guy who has just lost his work, or even worse, your boss.
• Take a break
  • From time to time, put whatever you are working on down, go outside and look at the world. Sit down and read a few pages of a book, magazine or newspaper. Even changing from one task to a radically different one (say going from user administration to swapping hard drives in a computer) helps. Whatever you do, make sure to take time to get those shoulders down from ear-level to the base of your neck.
• Listen to some music
  • If listening to music is your thing; do so. Bring an Mp3-player, a radio or play music off your computer. Music can help take your mind off the stress of the job, and help you focus.
• Leave work at work
  • The most important thing to remember about on-site support, is that, however challenging, difficult or aggravating your client might be, don’t take the stress home with you. That’s not always as easy as saying you’re going to do it, but make an effort. You, your loved ones and your client will all benefit from it.

 
There can be no doubt that on-site support is one of the most challenging jobs for a support tech. You can’t hang up or ignore that email, your client is in the same building (and sometimes even in the same room). Do your best, and keep the above advice in mind. That’s all anyone can expect.

Working in IT, I often have people ask me about issues they are having with their computer. Now, while I’m happy to help out, I often find that the problems I solve for them are problems they could have solved themselves. Mitch Tulloch, a Microsoft MVP and lead author of the just-published Windows 7 Resource Kit (Microsoft Press, 2010; ISBN: 9780735627000; 1760 pages), has created a short e-book called “What You Can Do Before You Call Tech Support.” Here are the opening paragraphs:
 

Your sound card has stopped working, your computer seems sluggish, the network is down, your hard drive is clicking, you can’t view a website, your monitor is hard to read, your new webcam isn’t working, your favorite program won’t run, and a funny burning smell is coming from your computer. What can you do on your own to try to troubleshoot the issue before you pick up the phone to call tech support?
 
If you’re running Windows 7, quite a lot. Microsoft has included a lot of self-support tools in Windows 7 that you can try using before you seek the help of others, and we’ll examine these in a moment. Then there are the tools you were born with—your five senses (see, hear, smell, taste, touch) and most importantly your brain. And by brain I’m including your memory, experience, and capacity for logical reasoning. Finally, there is ancient and sacred lore passed on in secret from Master to Disciple over the millennia. We’ll see shortly how your brain, your senses, and the secrets of the Wise Ones can be very helpful for troubleshooting computer problems. But first let’s look at what troubleshooting tools are built into Windows 7.

 
You can download the e-book in XPS format here and in PDF format here. Enjoy!

Working for a large-scale support department, we have a good solution for remote control and support for users who work for the companies I support. I am, however, from time to time called upon to provide support for friends and family. While I do prefer sitting at the computer in question, whenever that is not an option, I have a decent backup solution.
 
The backup solution is called TeamViewer. TeamViewer is free for non-commersial use, and supports all Windows versions since Windows 98 (including Windows 7), as well as Mac OS X. The download link can be found from the main website, and when downloaded, the program offers options to install or run the program.
 
When run or installed, the program displays this screen:

 
In a supporter role, all you need to do is ask the person at the problematic computer tell you their client ID and Password, enter the ID into the ID-box in the create session field, and click “Connect to Partner”. When prompted, you enter the Password, and hey presto! – you’re in.
 
There is also an option for manually setting a password, which can be useful if you want to remote control your home computer whenever you want, and are unable to rely on others being there to provide the information.
 
All in all, TeamViewer is simple to use, and effective to boot!

In my last post, I wrote about one of my recent support tickets. What annoys me about that ticket is that I could have solved it a lot sooner, if only the tech that had logged the call had taken down more information that “Video replay doesn’t work”.
 
When logging a support ticket, especially when you are going to pass it on to another tech, it is important to log as much information as possible. I’m not telling you to write the Great American Novel, but if you properly log what the problem is, when it occurred, and what has been done to resolve the problem, you solve two potential problems:
 

• First off, you avoid having to perform the same troubleshooting process more than once
• Secondly, when the user complains of insufficient help, and some of them invariably do, you can prove otherwise

 
Another practical upshot is that by documenting your process, you will be able to retrace your steps, and ultimately create a procedure for solving the problem.

A while back, I wrote about giving better support to users. This time, I’m turning the tables; here are five tips to get better support:
 

1. Curb your anger and annoyance
   • While I’ll concede that giving the person on the other end of the line a piece of your mind, keep in mind that their job is not to be your personal punching bag.
2. Be patient
   • Support techs will often need time to research a solution. Give them that time.
3. Be honest
   • Did you fiddle with it? Say so. Do not lie to a tech, it will only make the time to solve the problem longer. Much longer.
4. Describe what happened, and when
   • Instead of saying “It don’t work”, say “I’m not receiving emails. This started when…”
5. Don’t claim skills you don’t have
   • This ties in with no. 3. If you say that you know everything about computers, but in fact barely know how to send an email or use search engines, you will not get better support. If you lie about your skillset, you will be given solutions that you are not capable of implementing. If, instead, you tell the truth about your skillset, the tech will be able to explain the solution in more detail, getting you closer to solving your problem.

The number one biggest error many techs make when diagnosing problems for users, be it on the phone or on site, is going the complicated route. There is a reason why most ISPs have a script for their 1st tier techs to follow, to make sure that the basic errors have been corrected.
 
While I was an apprentice, I was called out to solve a print problem for a user. The user had a printer connected to her computer with a USB cable, and all the cables were connected. The printer in question didn’t have much in terms of diagnostic lights and such.
 
I head out to the user, and start troubleshooting. I try everything I can think of; print spooler, drivers, ports etc., and find myself no nearer to a solution half an hour later. Then I decide to check the back of the printer…
 
Sure enough, the power switch in the back had been toggled, probably by the cleaning staff.
 
The point of my story is that had I checked basic stuff first, that half hour hadn’t been wasted. The moral: Keep It Simple, Stupid

Having worked in tech support for close to five years, I find I still enjoy my work. Yes, at times, I feel like a target at a live fire exercise, but at the end of the day, I still find fulfillment in knowing that I am able to help my users. Here are five tips to giving better tech support:
 

1. Let the user talk, and listen to what they say
   • Allowing your user to talk may yield not only clues to what has gone wrong, but also clues to reproducing the problem as well as to fixing it.
2. Ask open-ended questions
   • By asking questions like “what were you doing when this happened?”, you invite the user to communicate with you, again prompting them to describe their problem
3. Don’t expect knowledge or skillset
   • The level of a user’s knowledge will vary, depending on their job role, which might be virtually anything (in my current position they range from CEO to warehouse clerks)
4. Ask leading questions
   • Instead of saying “could you give me your IP address”, say “do you know how to find your IP address”, allowing an opportunity to teach the user something
5. Be understanding
   • Many users have little or no knowledge of computing, and will oftentimes be apologetic about that fact. Try to assure them that you are there to help, and help them to the best of your abilities.

One of the tasks I am called upon to perform as part of my job as a desktop service tech is checking and troubleshooting VPN login. One fo the ways I do this is to log in as the user on my own machine. My employer uses RSA SecureID key fobs combined with a personal password for authentication.
 
As you may or may not know, RSA SecureID key fobs change the code they display every 60 seconds. Almost invariably, when I ask the user what the current code is, I am told to wait, as it is about to change. All well and good so far. Twenty seconds later, the code changes, and the user tells me what the new code is.
 
At the end of it all, I am left wondering, wouldn’t it be quicker to give me the code in the first place, instead of arguing?

Part of my job is setting up new computers. Part of the routine is to make sure all hardware devices have been installed. Now, this can be easier said than done, when all the information I have to go on is that the device in question is called “USB Device”…
 
Now, a while ago, a colleague of mine showed me a piece of software that so impressed me that I immediately put it on my on-site troubleshooting kit. The software in question is called System Information for Windows, or SIW for short.
 
SIW is a powerful bit of software that can be found here. The application to solve the aformentioned problem is as follows:
 
I plugged in my USB drive, and started SIW. I then found the entry “Devices” under Hardware. There I found the errant device, and found it to be identified as “vid_0c24&pid000F” A quick Google later, I knew the culprit to be the onboard Bluetooth card.
 
Instead of spending a lot of time trying different drivers, the above approach allowed me to find a solution, and implement it, within the space of ten minutes.

When instructing a user to type something, when reading a serial key or when spelling anything via a phone line, radio connection or similar, a problem arises at times; the person on the other end either does not understand what is being said, or understands what is being said as something different to what is actually being said.
 
This is easily remedied by replacing each letter with a word. The problem is, not all words are suited for this. Many attempts to standardize what words to substitute has been made, but the scheme I have found the best, most logical and easy to understand, is the NATO phonetic alphabet.
 
Since I adopted it, I have only seen three instances where it has failed me, all of which were due to the recipient having a preconceived notion of what I was about to say. It is clear, simple to learn, and easily understood.