Solutions Worse Than The Problem

Joel Spolsky wrote yesterday about customer service. Now Joel has been doing what he has been doing for a long time. He’s certainly qualified to talk about customer service. And while we are on the fringe (as a Unix/PHP shop) of FogCreek’s customer base, other than wanting more transparency in our FogBugz product (like a read-only view or similar) — we are largely happy with it. It’s a good product, and a good company.

However, in his post, he relayed one of the customer service strategies, that while a reality of life in technology and technology support, is one of the most absolutely, most fundamentally damaging service strategies in Information Technology (or any industry for that matter).

He called it “Suggest blowing out the dust” after a Raymond Chen article.

What it actually is: lying to the person you are supporting to avoid dealing with the real issue.

I’m not going to deny that we all have come to the point in Information Technology that you often have to metaphorically make up stories about PS/2 connectors getting dusty to get people to plugin their keyboard.

The problem is though, it’s a lie. We all might think that there’s some understood language happening that says you know that their keyboard is unplugged, and they know you know. But I’m not so sure anymore. Maybe about the simple binary issue of a keyboard plugged in or not or XYZ setting turned on or off in the software — but not about more complex issues about browser settings and add-ons, interactions between software applications, or “just how exactly are you trying to print that again?”

What I’ve seen over and over again is that the crackpot IT lies become truths, passed around either from customer to customer, or even worse, by front-line support staff because they don’t understand your products and services either and the developers/systems people just lied to them about what was wrong and what the solution was.

Those wrong answers pervade a long, long, time. And they often prevent the real triage from occurring. That is, they often forestall Joel’s very, very, excellent first point — “treat each support call like the NTSB treats airliner crashes”. All too often, both product support and the customer completely give up when the problem goes away. (It might not be that’s it’s unplugged, you might have had a quality control issue on those connectors, and “blowing the dust out” masks the real problem).

The only winning move is not to play.

At some point in this industry we have to start telling the truth.