Dealing with tech support--is lying OK?

If someone is reading from a script, is it OK to lie to them about what you have and have not done already?

Michael Horowitz

Michael Horowitz wrote his first computer program in 1973 and has been a computer nerd ever since. He spent more than 20 years working in an IBM mainframe (MVS) environment. He has worked in the research and development group of a large Wall Street financial company, and has been a technical writer for a mainframe software company.

He teaches a large range of self-developed classes, the underlying theme being Defensive Computing. Michael is an independent computer consultant, working with small businesses and the self-employed. He can be heard weekly on The Personal Computer Show on WBAI.


Michael Horowitz
2 min read

A number of incidents recently illustrated just how poorly trained most tech support people are.

I suspect that they have the jobs they do because they are willing to work cheap. Period. It seems that companies offer very little training to tech support personnel whose main job boils down to reading from a script and being polite.

If you are dealing with a technical problem where you understand the concepts involved, you are likely to be frustrated talking to someone who does not understand the concepts, but is mandated to do step 1, then step 2, then step 3, and not let the facts get in the way.

In this situation, is lying OK?

Hard to say. On the one hand, when script-reading support persons tell you to do x and then y, they may be lying to you. That is, they may have no clue what x or y does or how it might solve the problem. If you know that x and y won't fix the problem, is it OK to lie and say you did it?

I recently had a problem with a standalone VoIP unit the first time I plugged it into a router other than my own. The unit plugs into the Internet on one end and a normal telephone on the other end. The Internet connection was fine, the lights on the router were all normal, but there was no VoIP dial tone. So I called the vendor of the VoIP box.

The tech support person said to first turn off the router, the VoIP unit, and the cable modem and then turn them back on again. This is a reasonable starting point, assuming you have no interest in gathering any additional information about the problem. In my case, I couldn't turn everything off because the Internet connection was needed for something more important than this VoIP problem. That was the end of debugging. If I didn't do step 1, they wouldn't go to step 2 in the script. The fact that the Internet connection was fine, never made it to the radar screen.

I stewed on the problem some more and narrowed it down a bit. Then I called back to provide my additional information about the problem and another support person said the same thing: turn everything off first. Neither support person had any interest in understanding the problem beyond the simple fact that there was no dial tone.

Apparently, they can't handle a full problem description that requires understanding what's going on. For example, neither person asked about the status lights on the front of the VoIP unit.

Eventually, I figured out the VoIP problem myself (it had to do with DHCP vs. static IP address on the LAN) and fixed it without turning off the router.

Update May 23, 2008. Clarified that in the example, I was talking to the vendor of the VoIP unit, not the ISP.

See a summary of all my Defensive Computing postings.