This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
I am under no illusions about the majority of your customer interactions.
…If you’re having them at all.
I’m writing this book with developers/makers launching and running their own companies in mind. Unfortunately, unless you’re at Stripe or another customer-driven company, you’re probably quite insulated from customers.
Yet if you are talking to customers, the majority of those interactions are probably not leisurely interviews. They’re probably not usability sessions. They’re probably not screenshares with someone testing out a prototype.
Most of your customer interactions are probably good ol’ customer support.
Someone having an issue. Someone saying your site doesn’t work (when the problem is that they’re using Internet Explorer.) People asking to reset their passwords. People asking you to add a new feature.
By contrast, customer research seems like a calm oasis. A faraway tropical spa where we can luxuriate in proactive product development.
Customer support? Reactive. Unpredictable. Sometimes quite stressful.
…especially when people are upset.
And so given that the majority of your customer interactions as a very very small software company owner will be in the customer support context, it feels worth diving into here.
Empathy is an incredibly powerful tool for product development and figuring out what to build. It’s also a powerful tool for diffusing customer support situations and turning them into opportunities to learn more about the customer’s use case and overall goals.
I will not claim that it is easy. Providing empathic customer support is a skill – one that way too many companies undervalue.
Yet I know you can learn it. (Even those among you who are conflict-averse.)
In keeping with the practical toolkit approach of this book, I’m going to provide a few sample response templates below.
But before we do that, I want to tell you a story.
The grumbling users
Nate Bosscher is a consultant and was working with a client to build a new system that would be used by multiple departments. The project had been going great for several months, and towards the end, it came time to onboard another department that would be using the software.
On the onboarding call, people from this department were clearly unhappy. They were finding every chance they could to snipe at the product and grumble about having to use it.
Before I continue, I want you to notice what your instinctive reaction would be to this situation. (Not the one that you think you should have after reading this book… but what the first one that comes to mind is.)
Is it to ignore them? Is it to silently roll your eyes and try to get the call over with? Is it to call them out for their boorish behavior?
Nate took a different approach.
He was able to short-circuit that “gahh, people complaining” response. The people in this department were critical to the company’s adoption of the software, so he found time to listen to them on their own in a separate venue. (This is Right Thing to Do #1)
When he got them on the phone, he didn’t call them out, or prepare a defense about the software, or have his client explain the value of the software. He instead let them rant.. for half an hour. (This is Right Thing to Do #2)
This is powerful because it makes people feel heard. They didn’t feel heard by the software, and that led to their grumbling on the call.
One thing about learning how to show empathy is that you start seeing how many people were never shown empathy themselves growing up, and consequently really need some as adults in order to process their own feelings.
Even the adult men Nate was dealing with.
They just needed to feel heard. Nate realized that, and that allowed him to diffuse his own feelings of rejection (they didn’t like what he built!) to center their unprocessed feelings (they didn’t feel included – the software and whomever built it was beside the point).
After they were able to process their feelings, Nate was able to get to the root of the issue: turned out that the software didn’t quite match some paper forms they were used to. The mental model was off.
He made the changes, sent it back to them, and they we thrilled. The software now matched their familiar physical model, and they were ready to go.
Now, the solution isn’t always so simple. But the thread to pull from this is to validate people first – even if they’re acting in a way that isn’t exactly constructive. Validate the person first and the problem they’re experiencing.
Without further ado… let’s stock up your tool box for those customer support interactions, shall we?
Template: Responding to a feature request
This one is emotionally easier, so let’s start here.
It’s also an easy way to do research without setting aside time for it.
The key here is to dig into the context of why someone needs something and when they would use it. If we can, we also want to dig into who is requesting it. (If it’s a higher-up who has final say over buying our software, we want to know that information.) You probably instinctually jump to thinking through whether it’s possible and how you might implement it, but I have to ask you to tamp down that urge until you’ve figured out what the person is truly asking for.
If someone emails (or Slacks, or posts on Twitter, or etc) you a feature suggestion, first try to get them to elaborate. The goal is to get back a 3-4 paragraph response with their full process, and which you can then ask more follow-up questions about. Most of the time, I can pull that out with one of the following responses.
Your reply should be short and open-ended.
The formula is: 1) thank them, 2) ask for broader context, 3) use a deferential tense (could, would, might), and 4) use positive clarification words (curious, wondering)
Thank you for this suggestion! Could you walk me through a bit about when you would need this and what it would help you do overall?
Thank you for taking the time to share this idea! I’m curious – might you be able to give me the broader context on how this would fit into your overall process? I’m interested to hear how you currently solve this.
Thanks for suggesting this! Would you be able to tell me a little bit more about what you’re trying to do overall and how this would fit in? I’m wondering if you might be able to walk me through a specific situation where this would help you.
When you’re talking to someone–whether it’s on the phone, in person, or on Zoom– it’s easier to follow more of a scripted format. This might be in a sales setting, customer support, or even a conference when those can happen again.
The questions to hit are:
- Could you walk me through a situation when you might use this?
- Could you tell me more about what you’re trying to do and how this fits in?
- How do you currently solve this?
As an example, this might look like:
Customer: Hey, do you guys do [X]?
You: Not at the moment. Could you tell me a little more about when you might need that?
Template: Someone is unhappy
Ok, this is harder, so we’re doing this second.
(But it’s also critical. And so easy to get wrong.)
Think back to the worst customer support experience you’ve ever had.
Got it in your head?
I’m willing to bet there was some combination of the following:
- The person you were talking to was unable to solve your problem.
- They told you the problem you had didn’t exist.
- They told you that the way you were using [their thing] was wrong.
- They told you what you wanted to do overall was wrong.
- They were straight-up unreachable or unavailable for support.
- They did something shady, like not refunding you when you had a valid reason.
All of those have a commonality: they are *telling* you something. They are *doing something* to you (or not doing something).
Nowhere in there are they listening to you. Trying to understand. Leaving space for your problem and trying to see it from your perspective. Just jamming the company’s view of something at you and trying to make it fit, as if they were doggedly trying to put a soup ladle into one of those adorable little glass jam jars you see at hotels.
The idea here?
Validate them as a person and the problem they’re having FIRST. Without getting defensive. Without explaining to them what was supposed to happen, or what they are doing wrong. See them first.
Phrasing is really important here, and what we want to make sure to avoid is fake empathy – the kind you so often see in celebrity apologies. It might feel to you like you’re showing concern, but these phrases just make things worse. Don’t use them!
- I’m sorry you feel that way.
- I’m sorry you see it that way.
- I’m sorry you were confused by that.
- I’m sorry that wasn’t clear to you.
(This goes for personal life too.)
Better phrases center their problem and validate it, like:
- I can see this is causing a problem.
- I’m gathering that this could work better for what you’re trying to do.
- It sounds like you expected this to work a different way.
- I apologize. That should not have happened, and I can see how that is frustrating.
You’ve effed something up, and they’re upset
Let’s say you have an outage. Someone is pretty justified in being mad in that scenario.
The best thing you can do is be proactive, and notify them of the outage before they are even aware of it. This way, they know you’re on it.
What you want to communicate is:
- You’re aware of the issue
- [You’ve fixed it]
- You’ve credited their account for the downtime, if applicable
- You’re doing things to prevent it from ever happening again
But sometimes people come to you, and you have to find a way to respond in a way that acknowledges the problem and centers their experience.
Customer: Uhh is your API down? Our app is 404ing because of this! This is a serious problem.
You: Yes, our API is down. We recognize this is a serious problem. We are currently working to fix it and will update you as soon as it is fixed. We will write an after-action report that details what happened and what we are doing to prevent it from happening again.
Everyone fucks things up.
But not everyone follows up or does the work necessary to make sure it never happens again.
(This is one of the great perks of having your own company: the freedom to prioritize infrastructure work rather than throwing a bandaid over it and getting back on the feature release treadmill.)
Someone is insulting you
I urge you to try to distinguish between when someone is mad for a justifiable reason but comporting themselves appropriately (people are allowed to be mad) and when someone is mad and insulting you.
Even if they have a good reason to be mad, there’s no justification for toxic behavior.
Usually this stems from someone who only knows the fight response to difficult situations. They will usually exhaust themselves ranting, and when there is a beat and they wait for a reaction from you, a way to diffuse it is to relentlessly agree with them. Even if what you’re agreeing with is only a small part of what they said.
This is a trick I learned in negotiations training, and it’s helped me time after time.
Angry customer: Your software sucks! It doesn’t do what I needed! How are you even in business! You are incompetent! I’m going to [threat]! [Tantrum!] [Rant!]
You: You’re right, it sounds like our software didn’t do what you needed. I can see how you would be frustrated by that. I’m going to go ahead and refund the charges now. I’m wondering if [competitor] might be a better fit for you. Would you like me to delete your account, or would you like to do so yourself at [link]?
Use phrases like “you’re right” and “I can see what you mean” and “I agree.” People who are in this mode need to hear that they are right before they can calm down. It doesn’t even matter what you agree with… as long as they hear that.
But I want to be clear: just because the customer hears that they are right doesn’t mean they’re right. It doesn’t mean you have to cater to them.
So if you get in this scenario, the formula to follow is:
tell them they’re right + gently fire them.
(This is another one of those perks of having your own company. No one lording over your head with metrics to meet that mean you have to deal with toxic people.)
Because who has time for people who treat us with disrespect?
I certainly don’t.
Let’s go to a less violent example.
Someone reports a bug
The key here to show that you take them seriously is to reply as soon as possible and promise to follow-up. There is a problem, they had to take time out of their day to tell you about it, and chances are, there’s someone else inside or outside their organization asking them about it. Your goal is to give them confidence that the issue will be resolved.
The key here is not to wait until you’ve solved the issue. You may be tempted to wait replying until you can tell them it’s fixed, but it is better to give them the comfort of knowing someone is looking at it first. (This seems to be an instinct that engineers in particular struggle with. Acknowledge the problem first, then fix.)
It might go something like:
You: Thank you for bringing this to our attention. We will investigate this and get back to you [optional: include timeframe].
I’ve found that, perhaps somewhat paradoxically, saying “We take this seriously” comes off as hollow, so the way you show that it’s taken seriously is by replying quickly and following up in a timely manner. Actions speak louder than words, you know?
The need for speed also applies to payment inquiries. The goal is to prevent it from becoming a chargeback. You first need to establish that you a) acknowledge them, b) are capable of helping them, and c) give them concrete places to figure out why they used your service.
Person: Why was I charged [$]? I don’t even know what this is??
You: Hi, I can help you sort this out. It looks like you [did action on the product] on [date]. You can see that activity [here].
With payments, proactive is always better than reactive. No one likes a surprise bill. So any time you have pricing/payment/payment frequency questions, I encourage you to think about how you could communicate that proactively through transactional emails/documentation on your website/information in receipts/etc.
Neutral: they’re having an installation/integration issue
I call this sort of scenario neutral because while they’re not exactly happy, they usually aren’t mad either. They want to use your product, they’re just having trouble getting it to work.
What you want to do is establish that you are there to help them, and that you are competent to do so.
This has similarities with people reporting bugs and also feature requests. You want to:
- Ask for clarification about what they’re trying to do overall
- Figure out what they’ve already tried to do in terms of the installation
It might go something like….
Customer: Hi, I can’t seem to get your python library to work
You: I’m happy to help you with this. Can you share some more specifics on what you’re trying to do and where things seem to be going wrong?
It’s not all bad
It might seem from this like customer support is not a very fun part of running a very small company. It’s a skill to learn, and it makes sense why the first hire a lot of people make is customer support.
I found that once you get a handle on the basic concept of validating people first, and get over the fear of angry customers, it gets a lot easier. More often than not, it’s an untapped well for ideas about how to improve a product.
And also… the vast majority of customer service interactions tend to be more neutral. People making a sales inquiry. Basic questions about the service or pricing.
Occasionally, truly amazing compliments. Just the other day, we got one from someone about how our service had directly positively impacted her career path within the company she works for.
So I hope this doesn’t scare you.
I hope it gives you some confidence, or at the very least, something to fall back on in those harder situations.
If you only remember one thing from this, let it be:
Validate the person first.
[Are there other scenarios you wish I’d covered? Any tactics that have worked particularly well for you? Reply and let me know!]