While great support is founded in the day-to-day interactions, there’s always a surprising situation or two headed towards the queue.
Some of these conversations can be quite hectic, and that’s where a little preparedness goes a long way. Unfortunately, the curveballs of support don’t often get the coverage they deserve. It’s hard to form a plan without some examples, right?
Let’s fix that. Below are a handful of troublesome scenarios you may come across, and some guidance on how to handle them.
Security and social engineering
Support’s natural inclination to help can leave team members open to social engineering if they aren’t careful.
Here’s an example: If your app has different account standings that deal with security or payment responsibilities, you’ll have customers ask you to switch their roles, such as switching the account owner.
You’ll want to assist right away. You might even hear the plea of, “Please, we need this right now!” Hold steady. You’ll need approval from the current account owner, but don’t want your reply to create a standoff.
See, that wasn’t so bad.
“But she’s away on vacation!!” There’s always something, isn’t there?
Consult with your team, but know that you are most likely in a situation where you’ll have to delay the change until you hear from the owner. Reinforce the fact that you’re doing this to keep your customers safe; your standards are high because one slip-up with security is one too many.
That isn’t as easy to stomach for some people, but you must do the right thing even when you predict an irritable reaction as the outcome.
Responding after downtime and outages
The app has been down for two hours, maybe because something went wrong over in engineering, or perhaps you were hit by a DDoS attack. Most customers won’t care; they just want the product to work.
Here come the emails (my condolences if your team is using Gmail). Even with the right tools, you’ll still need the right responses.
Excessive technical details won’t concern many customers. The DDoS attack you’re experiencing doesn’t make the inability to access your product or website any less annoying.
Apologize outright, explain the game plan (if you’ve identified the issue), and let them know how you’ll be in touch. You’ve got their back, and you need to communicate that clearly.
Saying no to a feature request
Your product is built to serve the most important outcomes needed by the majority of your customer base. There will be many times when you have turn down a feature request.
If it’s suitable, make a few relevant suggestions for alternative products. But your response should be kept simple for an obvious “no” request because you don’t want to tread the line.
Your priority is to be impossible to misunderstand. Setting unclear expectations will result in confusion; you’ll end up saying no again like you should have the first time, but now with far more disappointment.
You’re wrong, but refunds won’t make right
Whoops. Something went wrong and now a customer is asking for a refund. You should have guidelines in place. If you do, you know that even when you’re in the wrong, compensation isn’t always the way to make it right.
I’ve personally had bad luck in the past with writing apps. Drafts written end up vanishing, or they become corrupted and the “backup” is nowhere to be found. Woe is me!
Let’s take that scenario to a more complex product. Say that out of the blue, a bug deletes some of a user’s settings, and you’ve never seen this happen before.
Getting hypothetical, let’s say the team has deemed a refund as not the right response for this situation. You’ll run into those instances, and problems aren’t always fixed with freebies, even when someone asks.
Offering some of your time is a fair exchange for a small glitch. Be polite but firm that you’re unable to offer financial compensation, but you’re ready to make things right through any alternatives available.
Dealing with an abusive customer
This isn’t an irate personality. This is someone who has clearly crossed the line and is mistreating your team member.
Shut it down, no exceptions. But don’t lose your cool; you must notify the team so they can commit to a swift, immediate action.
The steps to take:
- If you are on the receiving end, you must loop someone else in—a support lead or other team leadership. Do not handle this situation yourself.
- Cancel the account.
- Tell them to not contact you or anyone else on your team again.
Nobody enjoys these situations. They’re a mess. But the chances of not running into something similar over years or decades of experience is slim. Will you be prepared?
“I need to speak with a manager.”
If you messed up, pass the conversation on with context to the team lead and you’ll both figure it out from there. Mistakes happen.
If this is someone’s response because he didn’t get his way over a small request, the team needs unity on what to do. If you hire people you trust and trust the people you hire, the answer is most often to let them take ownership.
That doesn’t work for me. Look, I don’t want to waste my time, just get me your manager so I can get this done and over with.
There’s a way to handle this with finesse, and it doesn’t always require passing someone along when they’re just trying to boss around the next person in line.
The buck should stop with you if a customer requests “the manager” just to get around an accurate, honest response. If you have any doubts, it’s always better to ask than to guess. But when you’re acting with certainty, speak with kind authority.
Difficult support situations aren’t easy (or fun) to handle, and there’s no “perfect” solution for every problem. But with a little preparation and guidance from your team, you’ll be better suited to approach with tact and grace. That allows you to keep standards high and make better decisions—no matter what comes your way.