The Customer Support Conundrum
This weekend has been a bear in the customer support world. I’ve been in communication with three separate customers, for three separate products, and all three situations have been a challenge for different reasons.
This post is not at all about any of these customers specifically, but over the weekend it made me think of the different types of support issues we as product and service providers must face and how to deal with them.
Customer Support Ain’t Easy
If you support your own product or service, you’ve likely received a support request including one of the scenarios below:
This type of request comes to you with a title like:
Not working… or Help…
with the description of each support request going something like this:
…your (insert product or service name here) is not working. Please fix.
How in the world are you supposed to take any action to fix the issue if you don’t have any clue on what the actual problem is. The only thing that can be done here is to ask for more information, which takes time.
This is already a stake in the heart of the customer service experience for your customer or client. They want a fix, and they want it fast.
Unfortunately, the only option you have is to ask for more information which forces them to write two emails, instead of one just to get started.
This is the type of support scenario where help is offered, but the submitter seems intent on debating your entire business model, your approach to support, or some other subject that has little to do with actually solving their immediate issue.
Sometimes these are warranted, but other times they just draw out a solution more slowly and in turn, frustrate both your customer and your support team.
Ah, the fighter. What can I say about these types of support scenarios that you can’t already assume by the title?
This happened. A series of 4 emails over the span of 2 hours starting on a Friday evening just before midnight. They went something like this:
- Your product broke my #$%ing website! (free plugin on the .org repo btw)
- Why haven’t you responded you jerks!
- I am going to tell everyone I know to stay away from your @#$ing plugins!
- You are a !@#ing (insert C word here)
Wow. Someone is angry.
The scenario that we wish all support would fall under. This person sends an initial contact by describing the issue they’re experiencing, the steps they take to reproduce the problem, the things they’ve tried to fix it, and relevant links, screenshots, or even a short screencast to demonstrate what they’re seeing.
More times than not, our support team can immediately identify whether there may be a simple settings issue that’s conflicting or an actual bug in our product and resolve it quickly with one email reply.
The Knee Jerk Reaction
Sometimes we can be tempted to offer a quick and snarky reply to some of the scenarios above, but I urge you to refrain.
No matter how vague, argumentative, or inconsolable an initial support request seems on the surface, always try to keep in mind that these are real people. Of course, some are better than others in asking for help, but that’s OK.
That’s part of your responsibility of offering any type of product or service.
Every support request deserves a reply. Yes, even the most nasty ones. You may disagree with me, and I get it. To each their own.
Here are some ways to mitigate your support time spent and options for replying in positive ways.
Collect information first, and make it required.
Create as narrow a support path as possible to ensure that all support comes from a contact form. Easier said than done in the age of social media, but here’s why.
Directing your customers to a form allows you the opportunity to collect very specific information for any particular product or service. The key ingredient with forms is to make several required fields.
When we first launched FooPlugins, we had one form for several of our plugins that only asked for:
We quickly found that we were wasting a lot of time asking our users for additional information we needed in order to troubleshoot properly.
Now our forms look more like this, with each field being required.
- License Key
- Product Version Number
- WordPress Version Number
- Description of Problem
Additionally, we segmented our forms and made them specific to each individual product and service.
Be nice. Be overwhelmingly nice.
I talked about this a bit in my Being Nice post, but responding to an already troubled customer can have an immediate calming effect and allow both you and your customer to move forward with finding a resolution much faster.
Most customers want one thing immediately. To know that you’ve listened and that they’ve been heard. Once you ensure that baseline is there, the rest is easy.
In the case of an angry or rude support request, this is also known as taking the high road.
Reason with them. Yeah, right.
You may find yourself wanting to appeal to someone’s common sense about the cause and effect of a certain situation. I urge you to tread lightly and take this approach on a case-by-case basis.
Reasoning and providing additional details from a provider’s perspective can be a great opportunity to foster a deeper relationship with your customers, but if you’re not careful, it can have the opposite effect.
Reasoning can sometimes be seen as argumentative by mistake, especially in text.
Keep it non-personal.
If you’re a friendly and social person it’s easy to make the mistake of getting too personal with your customers.
In and of itself, it’s not a bad thing, but again it’s one of those things that can setup a string of replies not at all related to the issue that needs to be solved.
On the other hand, who know? Maybe you’ll make a life long friend.