Customers suffer when Customer Support and Product/Engineering don’t work well together
Disparate objectives are much to blame for the broken relationships between Support and Product/Engineering in high-growth companies. Support teams are focused on fixing customer issues as quickly as possible while trying to keep customers happy. Product and Engineering teams naturally gravitate to new-feature creation to generate more revenue and reduce lost deals from the lack of feature parity.
So herein lies the tension: Support feels like they get penalized when Product/Engineering teams don’t prioritize fixing customer issues because this means increases in support costs, wait times, and handle times, and decreases in net promoter scores, customer happiness, and ultimately, customer retention. All bad things for the Support team. Product/Engineering teams are frustrated when Support shares information about top issues but can’t provide data that makes it easy for them to diagnose and solve root cause issues. All bad things for the Product/Engineering team.
Result: Gridlock. Support loses. Product loses. And most importantly, the customer loses.
However, Support and Product/Engineering can agree on overarching objectives. They want customers to be happy and products to work well. So how can they fix the relationship?
Digging into the root cause
Product managers don’t have the data they need to act. Sure, they have dashboards and weekly emails summarizing top issues, but Support data contains too little and too much detail at the same time. For example, product managers will get reports with labels like “Log in Issues” on a pie chart (too little detail). They also have access to ticket notes from support agents detailing their communications with customers, but it is hard to consistently synthesize large volumes of tickets with notes that aren’t standardized (too much detail).
To solve customers’ issues faster, better, and easier, product managers need the right data with the right amount of detail.
Three secrets to fixing the Customer Support-Product relationship
Over the past year, DrumCV surveyed dozens of product managers to find out what the right data and details look like. Their answers were overwhelmingly consistent and uncovered three secrets:
- Detailed reasons – They need to know specific issues that customers contact the company about.
- Detailed resolutions – They need to know specific actions that support agents take to resolve a given issue.
- Data filtered by ownership – They need to see the aforementioned reasons and resolutions that pertain specifically to their team.
Secret #1: Product managers need detailed reason data
Before anything else, product managers need to know the specific reasons why customers are contacting Support. Detailed reason data shrinks the set of problems worth solving and helps to put some boundaries on discovery efforts. It helps you allocate the right resources from discovery through implementation.
Imagine you’re an airline pilot. You’d never take off without knowing the airport that you’re traveling to. It would be insufficient to only know the city or state of your destination. But if you know the airport, you can confidently take off and focus your efforts on arriving safely. There are key details to work out along the way, such as the runway you will be landing on. However, with the coordinates for the airport, you can get started and make progress toward your end objective.
In a comparable manner, it’s not enough to know that customers are dealing with “Credit Card Issues.” That’s like being told to fly to California. But when you find out that they are “Unable to process credit cards” or that “Credit Cards aren’t displaying correctly in an online account,” then you have something you can focus on. You can confidently investigate the issue and take logical steps to solve it.
Action #1: Convert vague reason labels to detailed reason labels.
Secret #2: Product managers need detailed resolution data
It’s a game changer to know specific reasons for customer contacts, but product managers also need to know how support agents are resolving customers’ issues. If Support can provide to Product teams the specifics on how they solve problems, then product managers can start with a list of solutions that will guide them to more effectively and efficiently fix the problem.
Support agents may already be describing resolutions in ticket notes. But resolutions can’t only be contained in the notes. There are simply too many tickets to read and synthesize every day. Product managers need detailed resolution labels.
Let’s say customers are contacting Support because they can’t create an online account. When product managers only have reason data such as “Account issues” or even a more detailed reason such as “Unable to create an online account,” potential root causes need to be discovered before moving on to building a solution.
Now, imagine that Support is resolving the majority of tickets for this issue by instructing customers on how to fill out the account creation form correctly. If data was reported on resolutions, such as “Trained the customer on how to set up an online account,” then a product manager could identify root causes faster and assign the best resources to solve the issue. In this case, they would probably assign a UX designer to create a more intuitive experience for customers. They might add clearer instructions to the account creation page. Or the interface recognizing when a customer is stuck could prompt them with the next step.
Action #2: Create detailed resolution labels.
Secret #3: Product managers need to see the data filtered based on their ownership
Imagine you’re an airline pilot again, and you receive the itinerary list for the day across all pilots, but there is no way to filter the list by pilot name. You can only filter by flight number. This would turn a simple task, finding out where you are going next, into a nuisance.
Just like pilots need to easily access their personal flight itinerary by name, product managers need easy access to reason/resolution data for the products and features that they are responsible for. When this type of filtering exists, it helps product managers spend more time on solutioning than the tedious parts of discovery.
Action #3: Link ownership of products and features to reason/resolution data.
You can fix the Customer Support-Product relationship
It is valuable and possible to fix the broken relationship between Support and Product/Engineering teams. When your Support data has detailed reason and resolution labels, and data can be filtered by product and feature owners, product managers can act faster, better, and easier to solve customers’ top issues.
Result: Support wins. Product/Engineering wins. And most importantly, your customers win.
About the Author
Dr. Carlos Kemeny is the Co-Founder and CEO of DrumCV, an innovative provider of technology and services that transform customer support data into customer intelligence. DrumCV fosters strategic alignment between Support and the rest of the company by bringing clarity, accountability, and actionability to customer support data.
Acknowledgement: Riley Corrigan, language technology specialist, contributed to this article.
« Return to Blog