How Not To Talk To Customers

| 2 Comments

I really hate dealing with tech support and customer service reps, especially on technical issues. It doesn't matter if I'm calling or sending email, inevitably someone says or does something so incredibly stupid that the entire process gets set back minutes if not hours. It can be something as simple as rigidly sticking to a troubleshooting flow chart, or as egregious as being rude and sloppy.

Recently I had two negative experiences with tech support. In the first case, I tried to tunnel a Linux-based client over SSH to an X console on my workstation as a workaround until firewall rules could be implemented, but kept getting a segmentation fault (often a sign of bad programming, not generally indicative of something with the X session itself). In the second case, a vendor tech support rep was sloppy in reading the submitted ticket, replying with troubleshooting details that didn't apply to the appliance we had, despite the pertinent information being in the very first sentence (of a 4-5 sentence email).

Just Plain Rude and Wrong

"The [redacted] client is not meant to be used in this manner, x-forwarding, and is not supported. The [redacted] Client already has encryption built-in; a ssl based encrypted connection is used for client server communication, and sending this connection through a ssh tunnel after already being encrypted would add more overhead that is not needed. We do have a [redacted] client for MAC, it is bundled with the server much like our Windows Clients. During installation you would be prompt for a complete or custom install; selecting custom would give you the option to install just the client and not the server."

Not to go too far afield, but I basically see three problems with their response:
1) It was rather snarky and unprofessional. Yes, I know, tech support people deal with idiots all the time, but why do they always seem to start from the assumption that each customer is dumb? I know Jack Daniel will disagree, but I think you really have to take the perspective of "reasonably intelligent until proven otherwise." More importantly, no matter how dumb you think your customer is, you still need to be respectful, at least in the initial conversation.
2) It was based on a lot of very bad assumptions. The tech support rep seems to assume that I was using SSH for security reasons (more security data transport). Not true - I simply was trying to work around firewall rules that were pending. He also seemed to think that SSH introduced much overhead and that this was causing the problem. Since I was getting a seg fault after the app was already running, this seems unlikely. Last, he assumes that I'm not aware of the other clients, which is of course simply not true. I in fact had the other clients installed, but as already noted, I needed firewall rules opened up before I could get them to work.
3) It didn't answer the question asked. Perhaps the single most irritating thing to me is that my question was never answered. I wanted to know if this seg fault issue had been experienced before, or if this was a new issue. Rather than answering the question, I instead got a snarky response full of bad assumptions that was no help whatsoever.

It's the Little Things
The other tech support experience I had was related to a vendor appliance on the fritz. I sent in the email, specifying serial number and model number in the very first sentence. It blew me away that the response I received instructed me to push buttons that did not exist on the model of appliance I was running. In fact, I even had to go through this a second time on the phone with tech support. They told me I needed to remove the face plate from the server and wouldn't believe me when I told them that it was already off and that there was, in fact, only one (1) button on the entire server (there wasn't even a rocker switch for the power on the back). Eventually they realized what model server I was running and switched gears, but not before wasting 20 minutes of my time.

My assumption is that because of the volume of tech support requests, techs are skimming requests and not paying attention to details. This, for me, is a huge pet peeve. Don't waste my time if you can't be bothered to read through the information provided. Yes, I can be wordy at times, but at least read the first couple sentences! Anyway... suffice to say, I find repeating myself to be frustrating, especially when the initial written communication has that information, on file, in a ticket, where it can be readily reviewed. It ranks right up there with going through a phone prompt, entering your account number, and then the minute you get to a live rep having them ask for all that information all over again. Praytell, why ask me to punch it in for the system if you're not going to make use of it later? I digress...

What sort of tech support annoyances have you experienced?

2 Comments

Today my home internet did not work and called my ISP; since i know these guys blindly follow checklists i told (as i always do) that i have done the basic troubleshooting steps before calling in... but he was again asking questions like what error do you get on on the browser screen? did you reboot? clear cookies (WTF?), etc. I had to politely stop him and ask for the ticket.

I guess it is because of the running costs. Maybe the vendor is having a budget on which they can hire only agents from non-tech backgrounds; training can only help to a certain extent.

I work for a IMS outsourcing firm, lot of times while discussing on deliverable. I have dealt with customers who want to have 99.9% up time; on checking they will have a basic NMS which cannot give you reports? trends? no baselines, etc... some times they can be unreasonable also.

@Ramki - those ISP troubleshooting calls are always my favorite... me: "I think the connection is down." them: "Please clear cookies and reboot your computer." me: "uh, what?" :)

Of course you're right, too, about unreasonable customer expectations. Probably explains why tech support people get so cranky. :)

About this Entry

This page contains a single entry by Ben Tomhave published on December 9, 2009 10:03 PM.

Actually, Possibility IS Probability (As Is Likelihood) was the previous entry in this blog.

Quick Security Lessons From Target is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7