How your support team improves your product
Main illustration: Kara Haupt
Blaming your customer support team for unhappy customers is like blaming weathermen for the rain. Sure they’re involved, but only on the receiving end.
If you outsource or silo your customer support team you’re destined to produce mediocre products. A product team that is numb to feedback will never learn about their failed launches, their confusing UI, their obscure labels, or their irrational defaults. If they can’t be guided by support metrics, alongside product metrics they’ll never understand what their customers didn’t understand.
The damage isn’t just in your product, it’s in your people too. Designers who fail to learn from their mistakes are destined to repeat them. Engineers who never hear about the impact of their bugs will continue to add more of them.
Similarly, an isolated support team evolve into apologists. With no direct connection to the product team they adapt their workflow accordingly. Instead of becoming excellent at communication, customer education, and case analysis, they behave like eskimos, creating 20 different ways to say “We’re sorry“.
Customer support cannot control, or be accountable for, how often customers contact them. They have no leverage there. The majority of contacts for a software product are due to confusion or error. Customers don’t understand how to do something, or they can’t see why something happened, so they click Support.
The team is responsible firstly for ensuring that all customers receive a fast, accurate, and friendly answer; and secondly for identifying product problems and passing them to their rightful owner.
Root cause and owner
Every problem has a root cause, every root cause has an owner. A customer couldn’t work out how to sign up? Why not? A customer asked how to add his teammates? Why did she need to ask that? A customer claims they saw “free” in an advert? Who put it there? The app crashed after they created their first project? Why did that happen? The customer’s invite mail got marked as spam? Why are we blacklisted? These all have owners, people who have the authority and ability to change the product to ensure future customers won’t ask this question again.
The 5 stages of owning your problems
It’s common for product owners to go through five stages of grief when faced with their problems. Attempts to dispatch, deny, discredit, or deflect the data will always precede any action taken.
It’s a natural reaction. The quickest way to accelerate through it is either for the product owner to sit in on some user testing, or start reading some support requests. Amazon solved it by automatically BCC-ing owners on every single customer issue until they starting solving them. As with any internal problem, when all else fails, go for for the jugular. The inbox.
Implementing this process
Using Intercom for customer support, the easiest way to start this is to tag messages from customers with their root case. This makes it easy to see which features or areas are resulting in most users asking questions, and easy for product designers and engineers to quickly see the implications of their work. It can also be useful to record the point in the customer lifecycle when the issue occurred, so you can see what the common “first day” questions are, and feed that back into onboarding.
It’s easy to ignore what your customers are saying when you’re focused on product design. But it’s not smart. If you don’t relay product feedback to your product team, it’ll create trickle down issues: your product gets worse and your customers get unhappier. You’re putting band-aids over bullet wounds, and before you know it you have a bad product and a bad product team.
