We're always looking for improvements in the customer's experience because we don't want to just be good at this, we want to be incredible.
We want to have the best possible product feedback loop and the best possible representation of our customer's voice.
In today's episode we talk to Nick Moreton, Director of Support at Hotjar, about how his Support team are working in unison with the Product team to create strategies that are centred around the voice of the customer.
We'll talk about the challenges most businesses face in capturing unbiased customer feedback and implementing it in wider business decisions.
Nick will also take us through how his customer support team has been restructured to work more closely with product, as well as how Hotjar are now using AI to analyse their customer support conversations and unlock in-depth customer sentiment insights they can act on.
Listen to the episode to understand some of the things you can do in your business to represent customer support insights in your product strategies.
Scroll down for the highlights or to watch the full episode 👇🏻
I think the thing about the voice of the customer is it can come from loads of different places. If you're in a product team you might see the voice of the customer being represented in some of the data metrics you measure. If you're a marketing team you might see VOC represented in feedback to product announcements. A support team will have a view of a voice of a customer coming through support tickets.
Each department is only getting quite a narrow lens of the customer's experience of a product and looking at it through their own subjectivity.
A smaller company might find it much easier to bring all those voices together to measure and compare for strategic conversations, but that becomes more of a challenge as your departments and customer base grow.
As your support team grows naturally apart from your product team, you start to understand each other's worlds and decisions a bit less. A support person will have a very subjective view of an issue that they want the product team to fix, but the product team will be coming from a completely different perspective.
A situation I've seen a lot in the past is where the product team, being very data driven, might be thinking that the support person's issue is a very low volume issue and it's not a priority, and down the road this might lead to frustration from both teams thinking they're not being listened to because they're looking at issues from their own subjectivities.
There can also often be an issue of timing - bringing different perspectives on the voice of a customer in early enough in a product journey to make informed decisions.
One of the worst experiences is a product team releases something and then a support team turns around and says "Oh, well if you'd have asked us we could have told you this", at which point it's a bit too late.
Sometimes there's a conversation that happens, that never quite sits right with me, where support will say "Hey, we're seeing this customer issue." and other departments will often say "Well, how many support tickets have you got about it?" - as if that's a measure of the actual impact.
For me, that's not a great measure of a problem. If I'm a customer, I would do everything in my power not to have to raise a support ticket. I would either try to self-serve and solve the problem myself or I would end up bailing on the product.
I think the danger that companies would fall into is if they try to quantify the qualitative without having the tools to do so objectively.
We've taken the approach of structuring ourselves in a focused way. We have people in our support teams who pay attention to certain product updates, certain bugs, and liaise with specific product managers, who they can speak to and build relationships with.
Previously we were categorising topics ourselves through manual tagging, but then you are just bringing just as much subjectivity into it. You also have limitations with how many categories or tags you can apply to a particular support ticket.
Now the tagging, among other things, is done for us in SentiSum - and at a much more granular level than we were able to do manually.
What we found really interesting from using a tool like SentiSum is we've discovered we've got this huge amount of tickets about this particular topic that no one in support ever mentions because it's one of those easy fixes. Like refunds, for example, we've got loads of these tickets, but they're easy to process so we never really talk about them as an issue. But us not seeing it as a pain point doesn't mean that the experience for the customer couldn't be better.
If I have a choice on where to invest my people's time, it would be in building out better experiences in the app, building a better product feedback loop, better self-service tools rather than answering support tickets. Because every time you answer a support ticket, you're answering it for that one person, but if you can solve that problem for a thousand people, you've had a much larger impact.
So we are trying to move the balance and find ways to have that deeper impact so that it becomes a cyclical thing, because the better you do in that one area the bigger the reduction of workload in another, which allows you to put even more effort into reducing the customers' time to success.
There was definitely a period of time where I'd see our product managers come to support and say "Hey, what are the biggest issues in this area?", and they get 20 different answers because, again, you get into that subjectivity. So a big leap forward using SentiSum has been the ability for the product managers to self-serve that information really easily on the dashboard.
I'm already seeing this shift, that I'm really excited about, where our support teams are going "Hey, listen, we've had this idea about how we can use this platform to tell you a story".
They're creating a views in SentiSum to specifically uncover things like UI issues for the product teams to look at. They can see all the topics or frequencies that are particular to that area.
It's going to allow the product managers and designers to look specifically for the areas where they can have an impact. A designer can't fix a bug, but they can fix a UI issue, so allow them to self-serve and see all of those UI issues the customers are bringing up in support.
We're also starting to segment data by particular cohorts of customers which is going to really help to drive those informed decisions and prioritisations.
We're still in the early stages at the moment, but once we progress, the product team will have their own log-ins to create views and all that sort of stuff for themselves. Our support team are doing that now, but allowing product to self-serve even more will just immerse them even more in the customer centricity of support.
Everyone who touches the customer in some way has a customer facing interaction and has the opportunity to think about whether they're putting the customer at the heart of what they're doing.
It might mean working on tiny micro gains, little tweaks to impact the customer's experience, which all add up for the customers and our teams.
Music: Savour The Moment by Shane Ivers - https://www.silvermansound.com