10 important lessons I've learned as a remote engineer

A lire sur:  http://www.techrepublic.com/blog/10things/10-important-lessons-ive-learned-as-a-remote-engineer/3758

By Jack Wallen,  June 14, 2013, 6:26 AM PDT

Takeaway: It takes a special kind of person to handle the remote support role. But for the right tech, the work can be enormously satisfying.

I’ve been doing remote support for quite a while now, and the journey has certainly been an enlightening one. At any given point, it has been an exercise in frustration, satisfaction, and humor. The biggest challenge to the remote engineer is that you have one added element between you and success — the end user. For many IT pros, that’s just not acceptable. Fortunately, those support personnel aren’t doing remote support. It has been quite the learning experience — one every young hotshot coming out of a comp sci program should have to endure. Why? Because, in the end, they’ll better grasp the fundamentals of the desktop PC as well as those who use them.
What are the more important lessons to be taken away from being a remote engineer? Here are 10 you can read and live vicariously though my experience.

1: The lack of computer literacy is astonishing

It never fails to amaze me that there are so many out there who depend upon the PC to do their job — while at the same time have zero knowledge of the tool. That is not to say they are completely bereft of skills or intelligence. But if you work at a PC all day, you should at least know how to enter a URL into a browser. I can’t tell you how many times I’ve instructed the end user to enter a particular web address into a browser only to be asked, “What’s a web browser?” Sometimes I want to respond, “It’s the application you probably use day in and day out to do your job!” Either that or… “Think Facebook.”

2: People want to get their jobs done

That’s right, the one thing in the way of end users doing their job is the remote engineer. No matter how frustrating your job is, it is crucial to remember that the person you’re trying to help can’t do their job until you do yours. That means the longer it takes you, the less patient they will be. The less patient the end user, the harder your job will be. I go into every remote session with the understanding that the end user just wants to be able to work. If they can’t work, they wind up staying late. And no one wants to do that.

3: Patience is the only answer

If you do not have patience, you should seriously reconsider doing remote support. I have spent hour-long appointments where the first 50 minutes were trying to walk the end user through just getting me into his or her machine and the last five or 10 minutes solving the problem. It takes a special hand to deal with that level of end user, and without patience, you are doomed to fail.

4: Occam’s razor almost always applies

It’s taken me a while to develop this approach — but no matter the issue, I always start with the simplest possible solution, even if it’s a reboot of the desktop. Often, the simplest answer will work, saving you time and saving the client money. That is a win-win. The client will love you for solving the issue so quickly, and you can move on to other end-user problems. Granted, Occam’s razor doesn’t always apply; but when it does, it’s a real blessing.

5: There are times when you have to step away

It happens: You dive into waters deeper than you can handle or a problem continues to evade you. In those situations, it’s always best to step away. That might mean putting the client on hold and catching your breath or telling the client the machine has to come into the office. A fresh pair of eyes or a fresh perspective could be all you need to get a win on this one. But it’s important to know when it’s time to put the mouse down and call it. And it’s usually best to call it sooner rather than later. If you continue to struggle with an issue, you’re going to wind up with an unhappy customer charged for your failure. Give yourself a time limit on certain issues. When you reach that limit, let the customer know that either you’re going to have to come out and resolve the issue or the machine will have to come to your office.

6: Smartphone issues require special attention

I have a number of smartphones at my desk. When a client has an issue with a smartphone, I try to match up the smartphone I have that best suits what the client is using. With that, I can more easily walk through the troubleshooting process. And having the phone on hand allows you to better describe to end users what they should see. If you don’t have a similar smartphone, you will need to rely on end users to describe, in detail, what they are seeing.

7: The more details you get, the better your chances

Even before you dive into the problem solving, you need to gather as much information as possible — the more detailed, the better. Find out what end users were doing when the problem started, what they have done since, what the expected behavior should be, what platform they’re using, any passwords they might have, whether they’re connecting to a server, etc. There will be information you won’t be able to get from the end user, such as IP addresses of servers, admin passwords, and router information. Remember, you have to set yourself up for a win even before you pick up the phone to call. Don’t set yourself up to put them on hold just to gather information.

8: It’s important to take notes (because the problem will return)

Remember that really obscure fix you used to solve problem X a few months ago? No? Well, it’s returned to another client, and now you have to retrace your steps to solve the problem again. That is wasted time. Instead of finding yourself in this position, make notes of what you do to solve issues (unless it’s a common issue). Doing this will not only make your job easier, it’ll make it faster. In the world of remote support, efficiency is king. Go into every job with as much information as possible and your chances of success are much improved.

9: Not all remote tools are created equal

RDP is great for servers. But when you’re dealing with desktop machines, you’re looking at tools like TeamViewer or LogMeIn. Both of these tools do a great job of getting you into a client’s desktop and even working with the Windows 7 UAC and multiple monitor setups and handling file transfers. If you’re using anything that falls short in those areas, you are doing yourself a serious disservice. You might wind up having to purchase a full-blown support license for such a product. But it’s worth it. Yes, some are costly, but they are a necessary cost of doing remote support.

10: You have to know when to call in the cavalry

There are certain instances when the only route to success is calling in vendor support. This is especially true when you’re dealing with niche software that has zero documentation and is not a friend of Google. In that case, your best first move is to get the third-party support on the phone, remote them in, and let them handle the task. In fact, when a client calls in about their niche software, the first thing I ask is whether they have a support contract with the vendor. If they do, I’ll tell them to call them first and if they can’t resolve the issue to call me back. This helps save them money and makes you look like the good guy in the end.

Fulfillment

Remote support is a special beast that requires a special kind of engineer. It’s not just about patience or a soothing voice. You must have a specific approach to the very work you do. After numerous years of remote support, I’ve learned that the position takes a certain kind of person for any level of success to be achieved. It’s not the easiest path, but it has its own flavor of rewards that most in the IT industry would find fulfilling.