Wednesday, March 22, 2006

10 steps to a better IT support process

As an IT professional, you need to have a structured mind to be able to think through all the different problematic situations that can present themselves to you on a day to day basis. After having worked in IT for a while, you should eventually start to develop a certain methodology that will help you solve most problems quickly and effectively. The goal of this article is to help junior IT workers in the task of supporting users in a corporate environment. I also wanted to put down on paper something that I've been doing for years, but never actually took time to document.

Good stuff. Definitely going to keep a link to this post hanging around for our newbs to read.

It's also a good idea to have some kind of stress-release mechanism. Sometimes the troubleshooting goes smoothly, sometimes it's a long and painful process. By the time the phone is put down, or you've returned from an on-site visit, the frustration of either the problem itself, or trying to talk to a user who doesn't listen/care/understand can be pretty intense. At the helpdesk where I work, we have a black wiffle-bat that you can grip menacingly (or something) after the client is gone. There's also usually someone around that can watch the phone for a minute while some quality banging-of-head-on-desk takes place.

Sometimes, I wish I could have a big punching bag with the face of a clueless user on it sitting right in the corner of my office, with a baseball bat hooked to the wall beside it. Whenever I need to let the rage and frustration out, I could pick it up and bash it with a "finish him" move à la Mortal Kombat ;)

I've often wished for a voodoo doll, or something with a face, or something that could gracefully withstand a good pounding. Unfortunately, our helpdesk is also the lobby of our department. The wiffle bat hides under the desk most of the time.

[This sounds like a flame, but it's not. Pretend you hear a stand-up comedian's voice reading it :)]

My writing style may be a bit subtle, so please lean in real close and listen carefully: DO NOT EVER USE THAT PHRASE AGAIN IN YOUR ENTIRE LIFE.

What are you thinking, man? That tech support is poor because of all the lazy workers who simply don't appreciate how good they have it? It's hard to believe you've ever done CS/TS with that anachronism dwelling within your cortex. Most people do this job because they can't find anything better. They may be intelligent and skilled but lack degrees or connections to get positions with genuine upward mobility. High volume call centres are generally hell on earth.

Here are the reasons CS/TS is so poor: the employers desire to save money any way possible. They overwork call centre workers who burn out and lose empathy for the customers. They impose strict, asinine procedures and constraints upon the workers which interferes with their interaction with the customers. They use the workers to wear out the customers who don't call back and co$t the company any more money.

The call centre is there to insulate the company FROM the customers, not to reach out to them. We all get a laugh when someone demands to speak to the president. Not even our head manager knows how to do that! Ask for my supervisor, and i'll give another tech a quick briefing and then hand you off to her.

The rest of your suggestions are very good, but CS/TS workers don't have any time to do them properly, even when they honestly want to. They have a supervisor breathing down their necks about their average call times, and the phone will ring again the instant they end the last one.

I realize that there are some truth in what you said, and yes, most big company's support department employ people who do not give a "beep" about their jobs, but this guide not only applies to CS/TS people, but also to system and network administrators, desktop specialists, operators, phone system admin..[And the list goes on]. If you take a minute and think about it, you could apply this guide to about any problematic situations that comes into your life, and it will help you deal with it in the best way possible. Thanks for the great comment.

What about better tools? I think that part and parcel of improving the process is using better tools more effectively. For eg: I use a tool called Spiceworks. I can quickly check the user's computer in Spiceworks to get all the information I need. (in practice I have it set up to alert me whenever a user installs a new piece of software, and I periodically compare computers to see if there are any differences from my original build image (the software does the compare for me)). More importantly, I run reports on which machines (and users) are causing the most support tickets. This way when I go to my boss asking to upgrade some machines I can back up my claim that doing so will reduce the support cost/time.

I think automation is they key to reducing the workload so we can focus on the important stuff.