Software

Solutions to the top 10 peeves of a support tech

It's easy to fall into a pattern of complaining about work annoyances and assuming there's nothing you can do about them. But IT pro Becky Roberts -- who wrote about the top 10 peeves of being a support tech -- found some ways to ease a few on-the-job aggravations.

It's easy to fall into a pattern of complaining about work annoyances and assuming there's nothing you can do about them. But IT pro Becky Roberts -- who wrote about the top 10 peeves of being a support tech -- found some ways to ease a few on-the-job aggravations.


Grumbling and whining about various aspects of our jobs, especially our users, is all too easy to do. Everyone does it, and it can have some therapeutic and entertainment value, but -- as many of you pointed out in response to The top 10 peeves of a support tech -- perhaps our energies would be better spent devising solutions to our problems instead of persistently complaining about them. So, as the perpetrator of the "top ten," I feel an obligation to get the ball rolling by offering the following solutions to my own complaints.

Note: This article originally appeared in 2005 and is available as a PDF download.

1: Users who insist on giving you their diagnosis of a problem rather than a neutral description of the symptoms

As with many user-type problems, a little education can go a long way. Is it really reasonable of us to expect the average user to automatically know how to report a computer problem? One simple method of training our users to accurately report problems is by asking them appropriate questions, just like a good car mechanic or doctor: "Can you show me where it hurts?"; "How would you describe the noise it was making?"; "Does it happen when you're coasting or only when you have your foot on the gas?" Instead of becoming impatient with the user, we can use appropriate questions to coach them and elicit the information we need to solve their problem.

Consider the following interaction:

  • User: "The e-mail server is down."
  • Tech: "Hmm, I'm so sorry you're having a problem accessing your e-mail. What exactly is happening that makes you think that the e-mail server is down? Are you receiving an error message when you try to log in? Are you able to access other applications on the network?"

In just a few seconds, the tech is able to validate the user's concern, extract the information needed to resolve the problem, and start the process of training the user to accurately report computer problems.

2: Users who hover around while you are troubleshooting, asking questions-and worse, making suggestions

Again, taking the time to train users may help with this situation, but if you're trying to troubleshoot a particularly intractable problem and being constantly interrupted, you could consider one of the following approaches: (1) take the computer back to your office to work on it in private; (2) troubleshoot remotely; (3) involve users by assigning them a role in the troubleshooting process. For example, ask them to try to reproduce the problem on someone else's computer or to make notes on what you're doing; this will either actually be beneficial to you or they will suddenly remember something else they had to do.

3: Users who deny having done anything that may have caused the problem

If you genuinely want to find out what they did, you have to make it okay for them to have done something wrong. This can be problematic because you don't want them to think you're condoning their actions, especially if they have violated company policy. The process of finding out what users did to their computer is rather like finding out where your teenager really went last night. Sometimes, to discover the truth, it's necessary to remove the threat of retribution or punishment, perhaps by offering amnesty in return for honesty. Once you've discovered what the users actually did, you can use other methods to discourage this type of behavior in the future, such as by informing them that the problem will take a while to fix and giving them the much slower loaner to use in the interim. The teenagers are another story....

4: Being treated like a user by tech support from another company

If you're dealing with a company on a regular basis, try to establish a relationship with a particular tech or techs and ask for them by name when you call. Or try talking to a manager or supervisor, explaining your problem and requesting that you can be put through to a higher level of support each time you call.

5: Purchasing departments that change purchase requests

This is a difficult one, and I would really like to hear from anyone who has successfully dealt with it. I've had discussions with our purchasing manager to explain the problem, but it was difficult, as she clearly felt that I was trying to tell her how to do her job. I did manage to effect a partial solution -- we selected a preferred VAR and then established that for any single item below a specified dollar amount, we could completely bypass the purchasing department. I pitched this as a way of alleviating the workload on the purchasing department. How useful this approach is depends upon the dollar amount established and the quality of the VAR. This arrangement also enables the building of a better relationship between the IT department and the VAR.

6: Internal junk mail

What can be done with this problem largely depends on company policies and the political atmosphere. If you're able to impose size limits on mailboxes, it can effectively limit the amount of junk mail stored. Given a choice between storing pictures of their cat and a proposal, users will probably store the proposal. I've also had a small degree of success in helping users establish personal mail accounts, making sure our firewall permits access. Routinely letting users know that there is no guarantee of privacy and that any mail in their mailbox overnight will be backed up to tape and stored forever may also help to discourage this behavior.

7: Users who think part of my job is to spend my lunch break telling them how to fix their home computers

I have not found a consistently effective method for dealing with this, as I do not like to be rude and unfriendly. In some instances, it's easy to plead ignorance and direct these users to other resources, such as their local computer store. In other cases, I‘ve suggested that if they buy me lunch, I'll be happy to give them 30 minutes of advice. In another instance, I traded computer knowledge for tax advice. It's hard to make generalizations about this peeve, as it really depends on your relationship with particular users and how they approach you.

8: Users who complain about not being able to use new applications when they "didn't have time" to attend training and refuse to read the painstakingly prepared documentation

Depending on the circumstances, one of the following approaches might be effective: (1) Ask users to schedule an hour with you when they have the time for a private tutorial; (2) Inform users of the time and date of a makeup class; (3) Let users know that you can schedule external training, (4) Provide users with a cheat sheet -- enough info to enable them to get by, since you don't want to be accused of preventing them from doing their job.

9: Being summoned to a user's office to resolve an urgent computer problem, only to be kept waiting

Wait for a few moments, but when users shows no sign of ending their phone call, leave a note on their desk asking them to call you when they are free -- and walk out. With one user who did this on a regular basis, I would write a friendly message on a post-it note and then call her as soon as I arrived back at my office, interrupting her phone call. Depending on your relationship with these users, you could also try telling them how you feel.

10: The positioning of the IT department in the organization

Quit and make sure you ask this question at your next interview.


Finally: 10 Things... the newsletter!

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

10 comments
danpat1_2000
danpat1_2000

How about peeves of a user: (a) Programmers who program what they "think" the user wants. (b) Programmers who design the output product for 15% of a user area. (c) Programmers who hand a user a deck of punch-holed cards and tell them to review the holes and when they find the right hole causing the problem, come and see them. (this is ancient) (d) Program supervisors who insist on supporting a programmer who is wrong (e) Programmers who consistently "swag" completion dates on a project (f) IT support shops who provide "untrained" personnel initially until later supplying the most knowledgeable tech specialist (g) Programmers who, when asked a question, retrieve a foot high of paperwork and say "your answer in in there." (h) Program supervisors who refuse to let a user talk to the programmer on the job (i) Program supervisors who keep the programming personnel away from the functional test [so we only have 9]

sschafir
sschafir

I will address 2 of these. #2 (even though it may seem harsh) I tell them that their continuous interruptions will slow down my solution to the problem because I cannot possibly listen to them and work on the problem they are having at the same time. So how long do they want to wait for a resolution to the problem. #7 I state my hourly rate to come over and look at the problem because it is nearly impossible to troubleshoot an issue without looking at it. I don't barter or trade for my services as they are as valuable off the job as on.

ShoePhone
ShoePhone

But some of my callers have only rebooted the monitor ... several times, in fact. I do try to distinguish the power users from the n00bies and trust the power users when the say the *did* reboot already, but it's a fine line. I'm sure I have pissed off some technically minded callers here and there.

sidekick
sidekick

I also find it helpful to, whenever I call for tech support, let them know upfront what steps you have already taken. Most of the time, they don't make me repeat them. This also clues them in that you have some idea of what you are doing.

Snak
Snak

Our latest project is (currently) 150,000 lines of code. Every page delivered to a browser is constructed, in real time, on the fly. Even after explaining this, we still get asked for a page or applet doing some taks or other and moaned at because it's not done in 5 minutes because 'I've done a web page and I know it's just a hypertext link'. Some of danpat1's comments are valid, but there's always another side of the coin :)

oldbaritone
oldbaritone

j)Program supervisors who buy-in to a project with a specification that is vague, meaningless, or no specification at all - so neither the programmers NOR the users know what it is or what it's supposed to do...

Old-Timer
Old-Timer

Lunch - leave, go somewhere to eat! Emergency Visit to an empty Desk - Leave a Sticky note on the Monitor explaining, that others need your time also and calls will be handled in the order, that they were received. And theirs is now at the bottom. Ask the "helper/Tech wanna-be" - did you touch it? Never repair on the spot - take the CPU in to the bench area.

oldbaritone
oldbaritone

[quote] Emergency Visit to an empty Desk - Leave a Sticky note on the Monitor explaining, that others need your time also and calls will be handled in the order, that they were received. And theirs is now at the bottom. [/quote] Works great EXCEPT when it's a VP or C_O (insert whatever letter, CEO, CIO, CFO etc) and they're the WORST offenders...

ozchorlton
ozchorlton

I always eat lunch, at the cafe, at the end of the street :-) I'm close enough to get back, in an emergency, but too far way to be asked questions!

Hobbesl
Hobbesl

I would wait two minutes then leave a note politely stating I have another appointment and they can reschedule this one with the help desk at their convenience. That usually worked because they knew their department co-ordinator would want to know why they need to reschedule.