Every user of your product has valuable insight to offer your team. That’s why it’s imperative that every user who fills out a support ticket gets a thoughtful, human response that goes beyond simply answering their original question.
In my last post I argued that all engineers should do their own support. When engineers are answering support tickets, interactions with customers act as a compass to guide product quality improvements and new feature development. In the early stages of product development, users with something to say are your most crucial lens on the world because they’re the ones who will get you to product-market fit.
When an engineer or product manager answers your support tickets, you get the chance to dig deep into the root of the problem and have a direct and immediate line to fix the real issue.
David Oates, a designer on the Signals team, says that customer support tickets are a lot like roaches. Seeing a roach in the kitchen is usually an indication that there are thousands more roaches in the basement. Similarly, for every frustrated customer that tells you about a bug in your product, there are likely hundreds more customers affected by the issue that aren't going to write in.
When developers and designers have such a close relationship to the customer base, it allows them to understand the customer's frustration firsthand. The alternative is common in product; there are dedicated support reps that relay customer frustration and bugs back to the product team.
Getting to the real issue in when a user writes in is not easy. Customers are usually reporting the symptoms of a problem rather than the problem itself, and they often struggle to articulate exactly what they are seeing, so it’s important to engage with that customer and figure out exactly what is going on.
Delving into the heart of the issue is worth the time, because it's likely that you are tapping in to a cause of frustration for a number of other users who are having the same problem.
When we're trying to understand the root problem of a support ticket, we avoid going back and forth over email, which is frustrating for all parties. Instead, we will invite the user to speak with us directly over a screenshare. By inviting the user to show us their problem, and not forcing a solution on them right away, we can get to the real problem faster. This allows you us to:
Once you've established this context, you're ready to dig deeper, and ask:
There are times when you’ll make users angry. It happens. See these situations as opportunities rather than failures. A good support team can turn a raging customer into their biggest advocate, and better off having had the issue than if they had never contacted support.
In order to turn these angry users around, you need to treat them as you would your friend (because, after all, they are your friend if they’re using your product). Tell them very calmly that you’re there to help them, that you want to help them, and that you will get to the bottom of their problem. Work around their schedules to fix things for them. Use the entire conversation as a learning experience, not was a way to get defensive about your product. This person is angry about something that likely many other people are frustrated about; they're just the most vocal.
Remember, your loudest customer is going to be loud in both good times and bad times. If you put in the effort to wow them, they will reward you with a tweet of satisfaction and a referral to their friends.
--
Want to learn more about customer-driven product development? Follow my personal blog at http://bilotti.org