Support is hard, really hard, and it’s not something that most people are naturally good at. In fact, I’d say a very, very small minority are even remotely good at it without a lot of practice. That number might even be zero. Being able to provide high quality tech support AND also being able to resolve issues for customers is a skill that takes a long time to obtain. I am to a point now that I believe I’m pretty good at tech support, both in terms of maintaining good customer relationships and actually being able to track down the problems and their causes, but this is something I’ve been practicing for several years now.
Providing top-notch support is not just about being good in dealing with customers, especially angry ones, or even being good at hunting down problems, whether they be in your own source code or the code someone else wrote. Top-notch support comes from balancing these two aspects and many more at the same time.
There are some that are amazing at customer relations. These people can deal with the happiest and the most vitriol customers with equal poise.
There are some that are amazing at troubleshooting. Give them a problem and they will solve it, or at least track down its source.
Unfortunately, when it comes to providing tech support for code-based products, you often need to have a high proficiency level with both, and that is where most support technicians come up short.
Let’s look at a few scenarios.
A customer buys your plugin and discovers there is a conflict with their current theme. Since your plugin was the latest thing they installed, they assume the fault is yours (regardless of where true fault lies, if there is any at all), and they open a ticket in your support system that looks like this:
I just bought this and it is completely broken. Nothing seems to work at all. I can’t believe I just spent $49 for this piece of junk.
First of all, my sympathy goes out to every single support technician that has had to deal with this kind of ticket. I can almost guarantee that if you sell plugins, or work for someone that does, you have seen a ticket like this.
How do you respond? Do you ignore them? Do you throw back an equally angry response, perhaps like this?
Obviously your theme is a piece of crap and you have no clue what you are talking about, our plugin works perfectly.
Hopefully you choose to respond with a bit more eloquence:
I’m sorry to hear that you are having trouble, but we are more than happy to help you work through all of issues you are experiencing. Typically this kind of problem comes from a simple conflict with your theme or another plugin. With just a little information from you, we should be able to diagnose the issue and track down the source of the problem.
Learning to hold back your gut reflex to lash out and to step back for a moment in order to compose yourself can take a lot of practice. I promise you, I have lost my fair share of customers due to not remembering to take a step back before answering.
Dealing with unhappy customers takes practice, lots of it, and learning to not let hurtful words cut you too deep takes even more practice. You absolutely must grow a thick skin if you want to work in product sales or support.
People say mean things, it is one of the absolute constants of this industry.
What about when a customer opens a ticket detailing a really complex problem, perhaps a bizarre conflict with another plugin. Imagine it is a conflict you have never heard of, can barely imagine, and have absolutely no clue whatsoever where to start.
To put it bluntly: what the fuck do you do here?!
How do you troubleshoot a problem that is so bizarre you cannot even think of a reasonable hint to what might be causing it?
That’s where practice comes in. Problems like this get easier in several different ways:
- Intimate knowledge of the platform you are supporting, whether that be your plugin or WordPress core
- Hours and hours of practice hunting down tough problems
Having an intimate knowledge of the system you are working with always helps, for obvious reasons, but sometimes it only gets you so far. Just because you know what function is getting fired and where doesn’t mean you know all of the possible ways other plugins or themes could interfere with the function.
Really tough trouble shooting simply comes down to practice, and that practices comes from doing your absolute best to work out a customer’s problem at 2 in the morning when you are running on 3 hours of sleep and your 7th cup of coffee.
I see a lot of people fail in support because they are given a tough problem and their response is simply: “I don’t know what to do with this.”
From personal experience I can tell you that no tough problem simply gets easier by ignoring them. You get good at solving challenging situations by jumping into them headfirst.
A true sign of a great support person is when they are given a really hard problem to solve and, instead of cringing and backing away, they dive in and start working their way backwards, line by line until they find the answer.
Remember, a possible answer is a thousand times better than no answer at all.
I have a small group of developers that assist me with support for Easy Digital Downloads. Some of them spend quite a few hours every single week working through tickets and some spend one, maybe two hours, but I try to do the same thing with all of them: intentionally assign them tickets that I know are over their head.
Why do I do this? It’s simple: if you want to become better at anything you must challenge yourself, so I challenge my support team by asking them to solve the problems they don’t know how to solve. Even if I know the answer to the ticket and could have it solved within a few minutes, I still prefer to assign it to one of my team and pay them for an hour or two of their time. Yes it costs me more to do that upfront (sometimes), but it also makes them better and better at providing tech support, which pays off in the long run.
The key to getting good at support is doing it and working really hard.
In the development world, there is a mantra that goes like this:
Just fucking ship it
The idea behind this is to simply work on getting something out the door and then working to improve it. If you never get your product out the door, it will never get tested, never get better, and will never make it into the customers hands.
Support is much the same way: you only get good at it by providing a lot of support. If you want to be good at support, you have to spend countless hours helping customers resolve problems.
There is no other answer. Period.
Nice write-up, Pippin.
Support is somewhat of a mixed blessing. On one hand, it’s an opportunity to show customers that they matter. On the other hand, it can burn countless hours, and is a possible sign of poor documentation.
Aside from hiring support staff, is there anything else you’ve been doing to improve your support infrastructure? How many of your support requests are duplicate questions and/or something already covered in the documentation?
I try to use support as an indication of what needs to be documented better, and as an excuse to write more documentation. Sometimes I succeed at that and sometimes I fail.
Making it easier for the support staff and myself to answer tickets has been huge. That includes being able to assign tickets easily, being able to view your assigned tickets, having quick access to all open tickets. Details like that can go a long ways.
Ah, documentation. You can never have too much, and there will always be someone who thinks it’s crap.
But worse, there’ll be more than a few people who don’t even read it. You get those “How do I do X?” and politely point them at the documentation – which already has highlighted links to it.
I tried over-documenting my last plugin with mega tool tips and use of the WP pull down help. Nup. Still got the “How do I … ” and “There’s no documentation” tickets. Sheesh!
Why is that so? Coz a lot of people expect things to be dead simple and super-intuitive. Those people think they should be able to use your plugin without documentation. So when they need it, they yell loudest.
And when you’re a one-man shop, like a lot of us, it can be a real challenge to stay on top of documentation.
I find documentation goes largely unread, but is a great resource to have so you can point users to it when they ask a question that is already documented.
Well said! The anger, hostility, frustration, and aggression launched at the very people that can help is something that takes years of practice to deal with constructively. Being able to determine the root cause of a problem can be very difficult. I tell my clients, “the answer is simple, we just have to find it. It’s kind of like E=mc2. Simple answer, but it took 3 million years of human evolution to come up with it. This won’t take 3 million years, but you get the point.” Often, they do.Thanks for the great article and the important reminder that we do indeed need to continue challenging ourselves.
Hehe, I like that.
One thing that I have found really helps is learning to ask the right questions. And as with most other aspects of support, this is something you get good at through experience.
Example: A couple months a customer was having an issue with our Franklin theme, which runs off Easy Digital Downloads. I probably spent about 1-2 hours working through their issue, but in the end confirmed it was due to a WP Super Cache compatibility problem, a problem which incidentally had already been diagnosed over on the EDD forums. Now, as soon as I get a question that suggests someone is having this issue, I ask them straight away if they’re running WP Super Cache, and if so, direct them to EDD for the solution. That 1-2 hours of initial investment will continue to save time in the long haul.
Question for you, Pippin: When you are doing support in a team environment, as you’re doing with EDD, do you have a system for relaying these little lessons to the rest of your team?
Cheers,
Eric
Most definitely, learning what the right questions are to more easily diagnose problems is vitally important. That’s one of the reasons why built the “System Info” page that gives us a snapshot of their current system. We simply ask that they provide us the information listed in the System Info and then that tells very quickly if their problem is caused by a known conflict with another plugin or server setup.
We have an internal chat room that we leave open at all times that let’s us easily communicate as a team. We discuss tickets there throughout the day. If one of us discovers a strange conflict, or confirm that there is a repeating conflict, we let the others know.
Obviously your theme is a piece of crap and you have no clue what you are talking about, our plugin works perfectly.
Hahaha! You are so damn right!
Great post!
Pippin,
You summed it all up very nicely.
One of my old bosses (before I worked for myself) would always say…
“take the helicopter view”
Its easy to get in a tizz when a customer is upset right from the get-go (thankfully I have few of those).. but I just take a deep breath, and get in that virtual helicopter and look at the big picture of whats happening.
Then I usually ask myself “If this were MY installation.. what would I do next?”
That usually sets the problem solving processes in action.
.. and if its nothing to do with my product then of course Google pretty much answers everything! haha
..or the line.. ‘actually you really need to talk to Pippin about that’ 😉 haha (jk!)
Well done on speaking all of our support/developer minds
Taking a step back and looking at it from a different perspective (such as from a helicopter!) is something I’ve found to be consistently important.
You hit the nail on the head with this. I can’t tell you how many times in a week that I would have one of those aggressive support tickets like the one you mentioned. It took me a while to get used to stepping back, putting myself in their shoes, replying kindly, and finding a solution no matter how long it takes. Most people are one curly bracket or disabled plugin away from remedying the issue.
Lawyers and doctors claim they’re “practicing” their craft… maybe Software Developers should be “practicing” support.
Good to read, and good to know even the best guys get the same sort of support requests as me!
The hardest thing for me is managing my time dealing with support tickets, and doing full-time projects.
A great tool that’s helped me out a fair bit is Helpscout. It’s made it much easier to deal with emails as tickets, and assign tickets to whoever.
How did you go about hiring a support team? Did you need to train them on the inner workings of your plugins? Do you pay them hourly?
Every current member of my support team is someone that made themselves available and visible to me by taking it upon themselves to contribute to Easy Digital Downloads. Most of them were users of the plugin before they started contributing, so they all knew it pretty well. They all get paid hourly.
Pippin, I have to thank you for something I heard you say a while back. I’ll paraphrase: “If you get the same question twice, add it to the documentation.” I’m convinced this is a huge time saver in the end but it’s often so hard to force myself keep up with that habit. Every now and then I realize I just answered the same question for the 10th time and it’s still not in the docs or FAQ. That’s when I hear Pippin’s tweet in my head, speaking all kinds of sense. Documentation is never done!
Support on pippinsplugins.com is really good. Answers are timely and relevant. Not so in some other places. I find myself asking fewer questions here, as compared to other places, because of the very helpful videos and support documentation. Pippinsplugins might dispute that I ask only a few support questions 🙂
I am going to release my first premium plugin shortly so this has definitely been helpful. But I was wondering: in the scenario in which the issue is due to a conflict which arises specifically on that user’s blog, do you think it would be fair to ask them to set you up a temporary admin account for you to inspect the problem?
It can be, though that’s entirely up to you. I’ve done it a lot and had great success with it, though I have also failed miserably and accidentally brought a customer’s site down by causing a fatal error while trying to fix the conflict. Anytime you have admin access, you have to be exceptionally careful.