I was reading Jen McCown’s post the other day and something struck me as…well…missing. It’s the part that has to do with how you would talk to your mechanic, and how that relates to questions that get posed to IT support folk. What do I think is missing? Great question.
What’s missing is the fact that most people still don’t know what to say, even if they know they need to provide details and context for you.
Take me for example. My dad is the parts manager at a local car dealership. Growing up I was in and around garages and mechanics quite frequently. I am not a mechanic, but I can put your car on a lift and change the oil as well as anyone else, and even rotate the tires. It’s not rocket science, there are very few tools involved. But most people reading this right now probably wouldn’t be able to put a car on a lift without asking a handful of questions such as “does the metal thing go under the car here, or there?” or even “where’s the button for the lift?”
Now, I know that there is a language that car mechanics speak. If I show up one day and say I hear some “knocking”, that means something to the mechanic very different that if I say “rapping”, or “tapping”, or “pinging”, or “ticking”. You can see an exhaustive list of sounds over at the Car Talk website. Now, even though I *know* that my choice of words will mean something very particular to the mechanic, I still try to describe it to him. (Yes, despite all my years around garages, I never learned the language, just enough to know that it was very particular).
At some point I stopped relying on words with my mechanic. Instead, I have him come for a ride with me. When the noise happens, I point it out and now he knows more about the problem than if I had tried to describe it. I prefer doing this than simply describing the problem and having the mechanic drive it himself later. What if he doesn’t hear anything, or hears something different? Then the issue I wanted resolved remains unresolved and we both get frustrated.
I avoid all that by having him sit with me. And I think that makes me a good customer, something else you can find over at Car Talk, and what I believe was the point of Jen’s post. It is one thing to offer good customer service, but quite another to be a good customer.
So, when those helpdesk tickets come in and they are less than helpful, try to remember that not everyone is going to be able to describe the problem effectively, no matter who they may be. Chances are you will need to sit with someone and look at the problem together.
Good point, good blog. Still, we must do our fair share to educate where we can. User education, like fragmentation, requires regular maintenance.
Jen,
Oh my yes, we always need to educate where (and when) we can.
I don’t get frustrated when users run up against the limits of not having my domain-specific knowledge; that is, after all, why I’m a DBA and they’re accountants and whatnot. I do, however, get frustrated when they don’t even make an effort to try and describe what’s happening.
I wouldn’t take my car to my mechanic with only a Post-It reading “not working, fix ASAP – I have a meeting in 30 minutes and I need it to work!” But that’s the sort of information we often get in tickets. I understand if a user can’t express the problem to me any better than “it’s slow when I try to do X in app Y, and it happens every time.” I’ve got no problem with that.
I have a problem with a ticket like the one we got a couple weeks ago:
Subject: ABYSMALLY SLOW!!!!!!!!!!!!!!!!!!!
Content: [nothing]
Matt,
Have you ever taken your car to the mechanic (without making an appointment) and asked them to look it over (for whatever reason) because you are heading out of town and you need to make sure it won’t break down? I am guessing that to a mechanic that is the equivalent of the post-it note. You are asking them to put other things aside for you at the very moment, same as your customers do to you.
I wish I could say that I have never seen a similar ticket to the one you described. I really, really, really wish I could say I have never seen such a ticket. But I can’t. I’ve seen those and others just like it.
I like that. I like Car Talk also so that helped. I can see both sides of your discussion – it’s a lot easier to let someone experience the problem for themselves, and it’s good for the mechanic(or tech guy) because they aren’t taking your word for it. I may not be alone when I say that I’ve been on trouble calls and gotten THIS close to telling someone they were crazy and then right before my eyes, they are able to recreate an error. Admittedly, sometimes the error is a user issue, but again, I’ve seen real-life errors that I thought wouldn’t be possible ever and then they did – right in front of me.
I love Click and Clack. I think I am going to ask Buck Woody if he’d like to do the SQL version of Car Talk with me, maybe once a month we just talk for an hour about SQL and professional development and stuff like that. I wonder if anyone would watch/listen.
Often I would find it best to sit with the end user that I thought was crazy. At Confio we don’t hesitate to get someone on the phone or a ReadyTalk conference line so we can see the issue they are talking about. It really helps to clear the air.
I had an experience like that. As a customer of a mechanic I couldn’t explain a particular noise well enough (a high whining sound) and it was only after a drive with my mechanic that I could point it out.
After finding the noise, he ordered and installed a part that fixed the problem. Then he explained what the problem was very clearly.
But today, a year later, I wouldn’t be able to tell you the name of that part.
Now in the I.T. world, you can and should educate when you can. But it’s going to be a stretch to expect the lesson sink in completely every time with everyone.
By the way, the “educate when you” strategy has been very effective in my experience, I have lunch-and-learns twice monthly for my colleagues and they’ve been extremely effective.
(p.s. I’m tempted to spell “mechanic” with two a’s 🙂 maybe you found that too?)
Michael,
Thanks for the comments. Lunch-and-learns work well when you have people that are interested in learning. Sounds like you have that in your shop.
Yeah, I’m really really lucky that way. I don’t even provide lunch and I get a good turn out.
People interested in learning is par for the course here (my company is named Desire2Learn).