We're compiling a list of tricks here in the IT department. You know, little things that seem to make the job go smoother while keeping to the all-important "I've quit...in my mind" rule. We share these within the department, to make everyone's lives a little easier. I'll also be sharing them here with you, dear reader, in the hopes that you can use them to your advantage.
I've decided (with unanimous support from the department) that any and all tricks must conform to the following three guidelines before they can be considered for entry to The List. These three guidelines have been dubbed "The Holy Trinity", and are detailed below:
The Holy Trinity:
All rules...
* ...must keep tech support from going crazy, even if only as a by-product.
* ...must not endanger the "I've quit in my mind" mantra. Bonus points if the trick actually obscures this mantra, and makes you look more productive than you actually are.
* ...must train the end users, administrative staff, and/or bosses and suits.
Today's trick is called The Nag Lag, and it's very simple. If you work in tech support, you know that there are end users who call you up the instant something goes wrong, no matter how trivial the problem really is. They're either scared of computers in general, or just don't like to think. After all, what's the point in learning anything about your computer when tech support's just a phone call away? This happens quite frequently at the Company here.
As a result, we delay our solution. Via email, this is easy: simply don't answer the email for an hour or so. Over the phone is a little more difficult. There's only so many times you can say, "I've written down your problem and I'll get back to you ASAP, but I'm in the middle of a server crisis right now", or words to that effect. Perhaps I'll have the team here compile a list of suitable "Nag Lag" phrases for a future post.
So, why do we delay our support? It's simple: at the Company here, we've noticed that, if the end user is left to her own devices (e.g., while waiting for tech support to call back), she will usually figure out the problem on her own. She may even follow up with an email or phone message saying, "I figured it out! It was stupid. Nevermind!" and all is right with the world.
Remember, the trick is to slack off as much as possible while keeping everyone else as happy as possible, and therefore completely clueless to the fact that you're an entire IT department who's already quit their jobs but are still collecting paychecks from the Company.
We like this trick for a number of reasons.
First, it keeps us from pulling our hair out by answering the same five stupid questions every day.
Second, it works: you don't get burned for slacking off if you use this trick--just claim that you're absolutely swamped and can't get back to them right away, but you're seriously looking into the problem and will have a solution shortly.
Third, it trains the users. If you give out immediate answers, the end users will assume that you will give out future answers and solutions in the same time frame. As long as the users are used to a distinct time delay between when they request help and when they get their answers, you and your IT department won't be pressured by the "FIX IT NOW!" types as often as you would otherwise. It also makes you look very, very busy if you do it right.
You can see that the Nag Lag follows all three Holy Trinity guidelines. It's a good trick. I heartily recommend it. Post a comment below if you've used the Nag Lag, or if you have a better idea.
Tuesday, April 17, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment