Solutions Worse Than The Problem @ RambleOn

Solutions Worse Than The Problem

Posted on February 20th, 2007 jasonadamyoung 5 comments

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.

Uncategorized reflections, Uncategorized
5 responses to “Solutions Worse Than The Problem”
- dbt February 20th, 2007 at 13:58
  
  While I agree with your general point, the idea is that they go look at the back of the computer to “blow out the dust” and see that the thing is unplugged, rather than you telling them they didn’t plug the keyboard in and them arguing that no, they did. Subterfuge, yes, but they discover the problem on their own and fix it.
- jayoung February 20th, 2007 at 14:13
  
  Yeah, that’s the problem with metaphors. The lie “works” for the binary issues of the keyboard and for the “Yes I set that setting” But it breaks down for the rather more frequent shades of gray problems. Rarely are support issues so binary. And metaphorically maintaining the lie that sometimes “the connectors get dusty” or “let the software write out the settings” for those non-binary support situations is worse than the problem.
  
  Computing users desperately need to have a greater understanding of how these complicated systems we build and create work. A whole lot of their lives depend on these IT systems, and my core point is that the more we gloss over them, hiding the mysteries of their operation in some IT back room – the more we do them a disservice.
  
  Ignorance maintained for the sake of avoiding offense is worse than offending someone.
  
  (and yes, there are ways to say things that point it out directly without causing offense, it requires an amount of humility and self-deprecation. It’s hard, but it can be done).
- bmo February 21st, 2007 at 19:05
  
  Of course you can take the policy of guiding users too far – a user is not an interface to be exploited, a user is a person. Blowing-out-the-dust is good advice in a very specific set of circumstances – when you, as support, have a reasonable suspicion that X is the case, and the user, through lack of experience (or accumulated frustration), is in the state of mind where they are filtering X out as a possibility. It is used to bypass their filters and get them to notice that X is, in fact, the case.
  
  You shouldn’t lie to your users just to get them off your ass, or give them incorrect information that will contaminate downstream. But people are organic systems and require organic inputs, and sometimes you can’t solve someone’s problem by calmly repeating The Truth at them while they’re tearing their hair out.
- jayoung February 21st, 2007 at 21:21
  
  Yeah. I’ll grant that and completely agree. I didn’t mean to suggest that you can deal with support issues like the correct answer to a math problem.
  
  If they are keyed up such that they won’t listen to you – if it’s not a “teaching moment” – you certainly work through it in a way that’s best going to reach the person and get their problem solved.
- Adi February 22nd, 2007 at 04:33
  
  Pingback from http://dotmad.blogspot.com/2007/02/blow-dust-out-of-connector.html