How To Talk To Technical Support

Many people would define their dealings with tech support as "annoying" at
best. Strangely enough most tech support people see it the same way. The
most basic issues usually come down to communication. The tech is too
technical for the user. The user does not understand the tech and/or
answers questions with information irrelevant to the problem. The
combination ends up being that the tech is frustrated and does not want to
deal with the user and the user feels that the tech is not being helpful
and/or has an attitude.

........................... Click the more button for the entire article ...................

(article to appear in the next issue of the DALnet zine)

Title: How To Talk To Technical Support
Author: Aaron Schultz (aaron@powertrip.net)

Many people would define their dealings with tech support as "annoying" at
best. Strangely enough most tech support people see it the same way. The
most basic issues usually come down to communication. The tech is too
technical for the user. The user does not understand the tech and/or
answers questions with information irrelevant to the problem. The
combination ends up being that the tech is frustrated and does not want to
deal with the user and the user feels that the tech is not being helpful
and/or has an attitude.

Retraining techs to ask questions in such a way that users can answer them
is the first part of the problem. Having a tech ask "what ports are
available on the machine" as an example doesn't work with the average user
which has never looked at the back of their computer. If the tech asks
"is there a place on your computer, probably in the back, that looks like
the place on your radio where you plug headphones in" they're more likely
to get a "yes, there are 3 of those holes" as a response.

The second tech support problem is the assumption that computers and
equipment are an exact science. There are many problems that can occur on
equipment - the newer and more functional the equipment, the more possible
causes behind the problem. Often a user will assume that if something
breaks, the tech already knows the solution and can instantly apply it and
send them on their way. Sometimes this is the case, but often a tech's
training will step in if it's not and the user will find that the tech
needs many pieces of information and will try a number of things before
things work correctly. The problem that comes in to play is that if the
tech is relying on the user to try the commands and provide feedback on
their success, it can be a slow process. Many users have felt that the
tech does not believe in their abilities to type commands given over the
phone, etc or that a tech does not feel that the user can learn to support
themselves when the tech simply needs to do a range of tests to find the
problem. Given that the tech knows what types of answers they're looking
for and that usually the techs have a grasp of the keyboard, it often is
faster if they simply do what they need to do.

And yes, the users are also part of the problem. If the tech asks the
user a question, they are not looking for a history of how the machine
used to work or how things have changed or for the user to repeat their
problem or for the user to explain how bad this problem if effecting
them.. the tech needs to know ONLY the answer to the question. Users have
a bad habit of doing everything I mentioned in the above line and not
answering the question that's been asked. When this happens a few times,
the person doing support will often become upset and the situation grows
into one where the tech only can do support for the user as hands-on or
gives up on the situation completely.

The other large problem users have is not accepting alternatives. An
example situation: A user's word processing software has failed for
unknown reasons, the tech is unable to correct the problem and the user
needs to write a report by tomorrow morning. The tech explains they are
unable to fix the immediate problem, but offers the user the ability to
install alternative software which won't be "exactly the same" but will at
least allow the user to finish what they need to do in the meantime. Many
users I've encountered will dismiss the idea and simply repeat their other
problem or counter the suggestion with comments about their need for the
other software to work. Some will actually not acknowledge the idea at
all. Any of these will usually cause a tech to hang up or walk away for a
bit while they cool down from dealing with a user who refuses to work with
them on their situation. Unfortunately, at the same time, users will get
the feeling that the tech was not interested in fixing the real problem
and only wanted to move the user to something "new" - regardless of if it
was the intention or not.

What does it all come down to? Communication, expectations and patience.
Once BOTH sides can communicate, the user's expectations of the tech are
valid and each side has patience.. the problems can be solved and everyone
can get back to work or play.

Posted by Aaron at August 28, 2003 10:03 AM