stupid support feature

Your support query isn’t stupid. You are.

Written by on September 18, 2013

This is a follow-up to my post from a couple of weeks back on The Perils of Making Customers Pay for Support. We’ve been getting some pretty interesting comments, and invariably, most arguments there seem to turn towards two interrelated premises:

a. Why should your nicer non-complaining customers be subsidizing the noisier ones?
b. Charging customers for supporting them deters stupid requests, or at least adds an ROI to servicing ID10T errors.

Interesting. This raises a whole new can of (quite unintended) worms – there is no reason you should be servicing those idiot customers, right? Let me start by breaking the suspense right away- I vehemently and completely disagree with the very notion of idiot customers, idiot support queries or idiot issues. And here’s why:

The problem with IDIOT errors and Stupid requests

Remember the old PC tech-support joke where a lady calls in about a problem with her cup holder? After a few troubleshooting steps, the support rep finally figures she’s been talking about her DVD drive all along. That’s just one of the thousands of hilarious “idiot” error examples from the last decade. In fact, the idiot error was once so famous, it goes by a whole bunch of names – user error, ID10T error, PICNIK (Problem in chair, not in keyboard), PEBKAC (Problem exists between keyboard and chair).

But wait a minute.  Users can’t really be idiots… If I built something for you, and you’re not able to even get started with it, who do you think is the idiot?

Lucky for the rest of us, while the industry was coming up with witty acronyms, a few smart people, further south (and a logo that looked a lot like a fruit), started worrying about usability – building products for the people who eventually used them. Little click-wheels with tactile response replaced clumsy buttons on MP3 players. And that changed everything.

The biggest problem with the idea of user errors is it allows support teams to conveniently forget that they are in business because of their ability to solve very specific problems of a very specific customer.

There are no user errors. Your users aren’t here to learn, understand, feel and “engineer” your product. That’s your job. Your users come to you to get their problems fixed, and your success depends on your ability to solve it for them. If 80% of your customers think your DVD tray is a cup holder, it’s probably time you put one there!

But what about edge cases and feature request nightmares?

You create things and put it out in the market intending to change the way people look at something. Let’s say you just built the perfect 12 inch wooden ruler. It is art, made of strong-yet-soft wood. It is so precise, the International System of Units could use it to set dimension standards. You believed this would become every carpenter’s first love. Just that it’s found more love with truck drivers because it’s perfect to scratch their back with.

This is where most entrepreneurs meet their demons. Why are people using your product in a way that it is clearly not intended for? How do you support customers you never set out to have? This is so wrong. Perhaps you should just pull the plug on your entire operation.

Or you could embrace your new customer base, pivot, and win.

The deal with edge-cases is, sometimes, they  open you up to that new market you never knew you could serve. If Airbnb had back-pedalled when people who had no intention of attending a conference wanted to couchsurf, they would’ve been extinct already.

Of course, if you had the entire carpenter community, and just a couple of truckers on board, you might be better off not supporting the back scratchers, but you’d never know unless you opened your eyes and support lines to those edge case users. There is a fine line between saying NO to a customer when you really have to, and just outright closing your doors to suggestions. It’s called common sense.

When you are new and trying to make a headway, edge cases and pivots are probably not a bad thing. Support every customer, listen to every request, and work on the most promising ones. Let a hundred flowers bloom – one might just be your chance for a $1B investment.

But what about all those Tantrum-i-zers?

Agreed, there are some customers who fall to the ground, and flail their hands and feet until you serve them. For the most basic of support issues at that. It’s probably something trivial. It may even be earth-shatteringly important for all it’s worth but after the fourth time around, you feel like punching through walls.

Now would be a good time to step away from those walls and put yourself in your customer’s shoes. Your customers definitely have more fun ways of spending their time than screaming at your support agents. So first, if your customers are actually taking the time and effort to get in touch with you, you should be genuinely glad that you’re so important to them.

And second, most customers actually feel bad to come to you with relatively “stupid” questions – like “how do I get this thing working”. After all, when was the last time you didn’t know something very basic and walked away feeling good?

At the end of the day, these handful of angry tantrumizers are helping you realize the ground realities affecting the larger majority of your customers. Better still – they are giving you an opportunity to build better products for your entire user base.

But.. but it couldn’t possibly be YOUR fault, could it?

At the end of the day, your customers have a choice – to choose you, or to walk away. And you have the choice – to either earn this customer, or not. But if you can’t solve the single problem of a single customer you tried so hard to acquire, you’ve failed. The idiocy is probably closer to home than you think…

After all, if your customers think your DVD tray is a cup holder, (a) your support hasn’t invested enough on evangelizing the DVD tray, (b) your marketing isn’t really targeting the right users for your culture, and (c ) your product management seriously needs to consider putting a cup holder on the cabinet!

PS: If you still worry about idiot customers, see how a stupid support issue at 2 a.m. made Ron Burley’s Broadcast Software into the company it is today.

Subscribe for blog updates

  • Diego Zanella

    I work in the IT industry, specialising in software development, and, for the past fifteen years, I had to deal with customer questions almost on a daily basis. In my experience, the reason why a question sounds stupid to an expert is that the expert already knows the answer, and that he gave it to other people many times before. The right word, therefore, is not “stupid”, but “boring”.

    If we see questions from that perspective, then we can turn them into something useful by using a simple logic: question is boring -> I don’t like being bored -> I should prevent the question. Thinking like that transforms a question into a task, which then becomes a solution to prevent the question from appearing again.

    Good software developers love such way of thinking, because it’s very similar to one of their favourite best practices, which is “no error should ever be reported twice”. The meaning is that, if a user reports and error, fix it once and for all, and never reintroduce it again. Just replace “error” with “question”, the logic works perfectly. The side effect of it is that the products improve, the boring questions disappear and more exciting work is done. Everybody wins.

    The most difficult trick, though, is not answering all questions, but filtering out truly bad customers. They are the one not worth spending time with, and it’s not always easy to identify them. Ironically, they are not stupid, but clever (that’s why the can be a pain) and they don’t ask stupid questions, but malicious ones. They are the ones who should be ditched, because they cause nothing but trouble. Luckily, they seem to be rare.

  • I12BPhil

    What?! How could it be that something I’ve spent years to master…you don’t know automatically?

  • Bobby

    Yes there is a difference between stupid and boring. I agree with Diego. Its probably no different than a bus driver telling a passenger what bus to catch for the 20ith time that morning. But thats why they create timetables and we build knowledge bases or FAQ’s. But sometimes its just easier to ask someone the question then looking it up, if you get a few of these may I suggest (let me google that for you) http://lmgtfy.com/

    But I had a whole new level of stupid one morning.

    A staff member called me up from an office 80km away saying her computer wouldn’t start. I could hear the machine beeping in the background with the sound of one of the keys on the keyboard being held down.

    I asked her more than once whether there was something on the keyboard, she was adamant that none of the keys were being pressed. So asked her to use a different machine while I got a replacement and drove over.

    This resulted in her manager calling me demanding why I’d got her to use a spare computer in a different part of the building, and her manager also calling my boss to also complain (more than once!!) about the lack of our support.

    I quickly prepared a new machine and drove over. On getting to the problem machine I found that there was in fact a wedge of chocolate stuck in the F4 key pinning it down and stopping the computer from booting up. This may be a very rare case, but this was just incompetence!

    • Had a similar problem once, and its a good story on never assuming the user is being dumb.

      We were constantly resetting this one professor’s password because he kept screwing it up.

      It was random, but often enough that we were doing it with a batch script.

      All the other techs called him and idiot and they had become accustom to it.

      The next time it happened, I asked him to use another computer for a bit. I was going on site shortly, so it wasn’t a big deal. While there, I had him do what he normally did while I watched. The problem was immediately obvious: the professor’s desk was so messy that a book was constantly hitting the shift key.

      It seemed that he was an odd duck and would only use the caps key to uppercase letters and never ever used the shift key. When he was writing, he would just hit caps lock to switch between the ‘shift modes’. The issue was that during typing his password, the only indication of caps was if the caps lock light was on or not.

      I ended up ‘fixing’ the issue without telling him how.

      I told the rest of the techs to get me if the password issue happened again. The next time I had him on the phone, I walked him through typing out the word “typewriter” into the username field – “just to make sure that all the keys were working.” Strangely enough the password worked then next time we tried it, and the problem never happened again. He never did tell me what was wrong with it. 😉

  • athensguy

    A computer is a tool. If it is a tool you need to use to get your job done, then it’s probably a good idea to learn how to use said tool.

    You mention Apple, but the users of products from that company tend to be among the most difficult for me to help due to their general lack of willingness to learn how to use the tools they’ve chosen.

  • Wonderful post.

    The notion of “the idiot user” taints the interaction between everyone involved. Sadly, it seems that far too many IT support people come from that mindset of “the user is stupid”. I’ve always fought this assumption because it seems to stem from a pop-phsycology notion that grows within helpdesk culture. I’m much more willing to say “I do not know why the user did this” if I can’t come up with why – I see it as a failure on my part if I need to result to “the user is just dumb”.

    A good example of the failure inherent in this way of thinking is to assume that an upswing in malware is a result of users ‘going to porn sites too much’. The result of this way of thinking is to knee-jerk to tightening website filters or petitioning management to buy something that can as the ticket load becomes unmanageable. The correct action, however, would have been to update adobe reader and look into the business impact of disabling activeX on IE. I saw this happen a couple of times when there was a new browser exploit in the wild or especially when TDSS was making its rounds.

    its very had to emphasize with the end-user – but a key part of the job. I see it as culturally encouraged laziness.

    —-

    The one thing I haven’t been able to deal with are situations where you get called in to replace the paper in the printer. While I agree it may be a failure on our part in targeting the right clients and setting clear boundaries, I still can’t figure out where it comes from or how to approach it.

    This type of request (which I categorize as “do my job for me”) is so prevalent that I feel it is a culturally ingrained expectation more than an IT specific one. That is to day, the ideas that spawn this kind of perspective over the duties of IT are spread from peer-to-peer and may very well be outside of what the helpdesk can effectively manage.