Customer Happiness Can’t Be Measured With Bullshit
A few years ago I worked for a tech company that wanted to determine whether their customer support was “successful” and if customers were “happy.” A system was integrated that allowed customers to rate our support emails without prejudice – Let’s say we didn’t offer a feature the customer wanted. They just had to vote that our response was BAD to voice their opinion. If a customer didn’t like us saying “Hi” instead of “Hello”, they could rate our reply poorly and we’d be held accountable for that. The endgame for this seemed simple enough: The more poor responses meant that support person was doing a bad job, and swift action would be taken against them.
This whole idea absolutely enraged me, and not because I’m against customers having a voice about how they’re treated by support. I never actually had any fears about what customers would say about me, but I did know that relying *only* on my replies to unsolicited emails as a way of judging customer “happiness” was complete bullshit. At the time, I didn’t have a great confidence in my communication skills, and often shrunk under pressures of explaining why things didn’t work for me or why I challenged ideas. What I know now, all these years later after reviewing countless support teams to improve customer experiences, is that this idea is still total bullshit. Here’s why.
Rating a response to your support email is a purely emotional event. You’re either overwhelmed with joy because the person was so fast and friendly, or you’re annoyed because they wasted your time to tell you the app doesn’t do what you want. How is that in any way an accurate depiction of the overall “happiness” of all your users? It’s not and it never can be. It is instead only a small, small portion of what you should be considering when you want to look at to see who’s happy and why.
Imagine you launch a new feature and support is inundated with questions about it. Is a feature too confusing? Let the designer of the feature take the brunt of the blame instead of the support person who’s job it is to defend bad design decisions. Did you get 150 complains about the feature? The happiness rating should apply to the person who created the feature, not the one who had to answer to all the emails in a rush and make sure everyone was still friends.
It’s part of your job as a product manager or startup founder to listen intently to your support agents. Unless you’re answering 80% of the support emails yourself, you have zero idea what customers are really asking or complaining about. Your support team knows, and if they’re good at their job, they’re keeping track of the general feeling customers have about new features, old features, lack of features, whatever. They may even keep lists or track tags of the top requests – data that you as a product leader need to make your product better.
When you choose to tell this team that it’s more important for you to see Red, Yellow or Green next to their name, you rob them of the joy of being part of your product development. Instead, you throw back on them this idea that they’re on constant alert to just smooth things over, and it’s their job to make everyone’s emotions about your product positive. They’re not there for any other reason when you equate their entire day’s work to a thumbs up icon.
Instead. Instead. Please read that word again, since we’re not talking and and/or here. Instead, the leader of a great support team demands excellence in a much more practical way: By asking support agents what customers are feeling, what they’re saying, what they need, and what they want. When your support team presents to you a case for changing a feature, it’s based on their experience with multiple customers and that particular feature. If your reply is, “I don’t get that problem,” or “Well, we designed it that way for a reason,” you really don’t give a shit about customer happiness, do you? It sounds like you care more about your design philosophy and ego than the response of people paying you money for a product.
You’ll know you give a shit about customer happiness when you stop rating just customer responses to support emails and start rating their responses to features. Each time someone emails about feature X, tag that email so it cross-references their rating of your support agent. You’ll start building actual customer responses on issues instead of just emotional reactions to particular people. You’ll know customer happiness is a goal of yours when you stop relying on customers to take the time to tell you what’s wrong and instead implement a passive rating system of your app they can take part in – a survey or interview, or even a quick phone call with support to talk about what they like. Hell, ask people on Twitter to tell you what they think – everyone has a lot to say on Twitter!
Heres some practical ways you really accurately measure customer happiness or their feelings about your app:
- Measure speed of reply by your agents. You don’t even need your customers to tell you, “Thanks for the fast response” when you see the average responses time is 30 minutes. Is it over an hour? That’s something to work on. Most helpdesks will tell you this info, but UserVoice has the best built-in ratings system I’ve seen.
- Track number of support requests vs. number of customers. Do the math. If 25% of your users need to write support each month, something is wrong. If it’s more than that then…I’m not sure even I can help 😉
- Use customer’s thoughts on your support to gauge their emotions using your product. Not just whether they liked your support agent. Not just on if they said “Thanks!” Measure based on words they use such as love, hate, annoying, doesn’t have, need, want. Split these into “happy” or “unhappy” categories and again, just do the math.
- Keep track of feelings on new features and take it back to the designer. Let’s stop being assholes to support, ok? They deal with customers complaining about new features all day long and never get a chance to chime in with their design ideas. Your designers are making choices that affect customers, so let’s hold them responsible, too. Set a threshold for the percentage of love vs. hate to know when you need to change a design.
Only using customer ratings of support responses to determine whether something is working is as good of an idea as issuing traffic tickets based only on how the person responded to receiving that ticket. Real customer happiness is a mix of things, and never just one or the other. If you’re thinking that customer support “success” is going along with emoticons and never really digging much deeper, you’ll never really have a true representation of what your customers really like, really want, and really need from your team.
customer support design email leading support teams product development