Service requests are a constant stream of valuable user feedback. Actual users who are trying out your product are reaching out – a perfect time to start a dialog.
Last time I suggest that user feedback should be the main driver of product decisions. In this post I go over on the process I developed at Martial Arts on Rails for guiding the direction of the product based on user feedback, and specifically using customer service opportunities as the main source of that feedback.
I’ve worked at companies where customer service is completely separate from the development and product teams. And where developer time is too expensive for them to be bothered by issues that can be resolved by customer service.
I had the same approach years ago, treating issue reports that were not technically bugs as a nuisance. I would go to great lengths to avoid making changes. My developer bias was that if it’s not actually broken, it’s the user’s fault for using it wrong. I would often spend more time debating if a request was an actual issue than it was to actually address it.
Use support requests to start a dialog with your users
The turning point for me came after starting Martial Arts on Rails at the beginning of 2016. Unlike previous companies in which I the “technical” co-founder, this time it was just me running the show. I would be the one engaging users and providing customer service, always making sure to use the best CRM solutions from companies like Salesforce.
It was an ongoing process. Most of my users are not technical people and it took me a while to find the right voice to use in those interactions.
The first step was getting used to feature requests disguised as issue reports. I often receive issue reports claiming a feature “doesn’t work” because it doesn’t do something it wasn’t designed for. Instead of saying “I’m sorry, it doesn’t / can’t do that”, I started treating each such report as an opportunity to learn about what is missing in my product.
Users often frame their needs with your current product in mind. If they want to achieve something that is not currently possible, they will often say “I would like feature
x to do
y“. It’s up to you to engage them and figure out their intended result is actually
z which can be accomplished in a completely different way.
Sometimes things are cut and dry, and with a simple change you can make many users happy. Sometimes, changes that could benefit one user interfere with other users’ needs. Or you can satisfy everyone, but at the cost of adding complexity.
When I receive any kind of report that is not an actual bug, I always start a conversation in which I try to understand what is the user’s ideal flow and desired outcome. Once I have a better picture of what they’re trying to accomplish, I can make a much more informed decision on how to improve the product for all users.
Remove friction points to create a better user experience
By engaging users when they report an issue, I learn about their friction points with the product, and about how they run their business. This enables me to remove friction points and improve the product flow. Going through this feedback loop feel like I’m collaboratively improving my product with my users.
Reducing friction and creating better user flows has a compounding effect. When users have delightful user experiences, they are more forgiving when small things are broken or less than ideal, and are more willing to engage in a dialog to improve it. They become more invested in using the product.
Another common friction point is users needing guidance with how to use a certain feature. You can be sure that for every user that asks about a feature, there are several who didn’t bother and gave up on using your product because of it. Several users asking the same question is a strong indicator that a closer look is necessary.
Developers doing customer service?
At the start of the article I mentioned how my developer bias was getting in the way of me facing user feedback heads on. But it can actually be a big advantage once you learn to accept user feedback for what it is.
As the person who built the software and actively develops it, I know better than any support person how it actually works. I’m also able to quickly estimate time and complexity costs of making changes.
This allows me to suggest solutions and improvements that are outside the scope of what a regular customer service person could offer. I can optimize the development timeline by addressing low-hanging fruits that can provide big improvements in user experience.
Every customer service department would benefit from having developers assigned to it or rotating in. They can support service reps and provide the right level of support in real-time, while also informing the product team of potential friction points. Visit Qualtrics for more ideas on customer retention and experience.
This direct connection between user feedback and the people who build the product is often missing. Many companies employ non-technical product managers that act as liaisons between customer service and development teams, and much of the context is lost by the time a task is assigned for development.
Don’t scale customer service too early
Knowledgebases and chatbots can be useful when it’s time to scale customer service needs.
Be careful of implementing those solutions too early, or too widely as it can hide underlying issues with your product. If people often need to use online help, it indicates existing friction points remain that need to be addressed.
There are always tradeoffs, and some complexity is always present in software products. Some questions need to have persistent answers available to users in a help section or a knowledgebase. However, make sure you’ve collected all the feedback you can about that aspect of your product before you automate the response.
How do you handle customer service at your company? What is your process for improving your product? Let me know in the comments below!
To know when the next article is published, please subscribe to new articles using your Email below or follow me on Twitter.