3 Simple Reasons your Support Team Should Never Manage Product Feedback
You can generally separate the tickets your Support team receives into three distinct categories.
First, there’s the actual legitimate questions, where a user doesn’t know how to use a particular feature, perhaps because there’s a gap in your help documentation. These are the tickets your Support team should be dealing with.
Next up, you have the bugs. This is where your product doesn’t work as it should do, either because it’s broken, or because the bug is actually a thinly disguised piece of product feedback (we’ll get to that). Actual bugs are useful and can help the Product team fix any problems. Great.
Finally, you have the product feedback & feature request tickets. Sometimes these are disguised as the aforementioned bugs, but most of the time it’s a user who isn’t happy with the current functionality of your product and has some ideas on how to improve it.
Now, it might turn out that their idea is brilliant, but here’s the thing: Your Support team should categorically NOT be dealing with this kind of ticket.
Here’s why…
1 — It’s About Time!
Your Support team are there to support the customer, the clue is in the name. Spending time thinking about feature requests, ideas, and product feedback, and then having to pass them on to the relevant people isn’t, or at least shouldn’t be, in their job description.
It wastes precious time they should be using to actually help customers. Not only that, but it wastes other teams’ time as well.
If your Product team have to rely on your Support team for the data they need then it creates a bottleneck, preventing them from making any product decisions until the Support team get the opportunity to pass on any information.
The solution to this is to provide your customers with a self-service product feedback portal. For smaller companies, a simple email address or survey will be more than enough. For larger companies, you might need a more dedicated product feedback solution. You know, something like Receptive.
2 — Lost in Translation
If you think about a game of ‘Telephone’ then you end up with a pretty good idea of what it’s like when feedback is passed from department to department.
Your customer sends in a support ticket with an idea for a feature. Your Support team member digests that information, then relays it to the Product team. The Product team then add it to their backlog where it stews for a while. Eventually, they look at it again, and they have no idea what it means, who it was from or if it even matters anymore.
This is a common state of affairs in companies that have their Support teams deal with product feedback & feature requests. The Product team will end up lacking the context surrounding the idea. Why do they need it? What are they trying to achieve? Do they have a workaround? Without context, any feedback is meaningless.
Instead, you need to enable your Product team to speak directly to your customers, so they know exactly what they want, and more importantly, why they want it.
The product team is eager to hear what customers need first-hand, and not to have it filtered. A direct communication channel between a customer and the product team removes the need to manage expectations.” — Lisa Starita, (previously) Head of Customer Success Operations at Beekeeper.
3 — Who Answers Back?
Following on from the previous point: The fewer teams involved in the feedback process, the clearer the process is.
In the earlier example, both the Support team and the Product team were part of the feedback chain. In cases like that, who exactly is supposed to respond to the customer and close the loop?
We’ve written about the dangers of the black hole of feedback over and over — it’s vital that you respond to the customer, either for clarification or to update them on the status of their idea. But who should respond?
Now both the Support team and Product team have to work out between them who should communicate with the customer, wasting even more time and generating a great deal of confusion.
If you have a good Product Feedback Policy in place, everyone knows what to expect.
The Support team knows how to handle feedback effectively and pass it on to the Product team.
If you open up a separate channel for your customers to submit feedback and feature requests ongoing, then you will see a dramatic increase in support tickets, your Product team will be getting the information they need, and it will be easier to keep customers in the loop. This creates a better experience for everyone.
Here are some typical results for B2B SaaS companies using Receptive to manage their feedback:
So, there are three very good reasons why your Support team shouldn’t deal with product feedback. But I suppose the bigger question here is…
How do I Prevent my Support Team from Managing Product Feedback?
Well, with a little bit of process, it’s actually fairly easy to do.
Step #1
Create a Product Feedback Policy (PFP).
A PFP is essentially a service-level agreement for your Product teams. It tells your customers how they can submit feedback, and what will happen to it. This helps get your customers on board and sets expectations both inside and outside your organization.
That’s a simple process that helps take your Support team out of the equation when it comes to product feedback, saving them time and energy.
Step #2
Set up your product feedback portal. As I mentioned before, this can be a dedicated email address or a survey. It needs to be something easily accessible that your customers can use as and when they please. If you are a scaling or Enterprise B2B SaaS company then Receptive was built especially for this purpose.
Step #3
Next, you need to choose an employee (often part of the Product team) whose job it will be to regularly check through the feedback and highlight any ideas that are particularly relevant.
If your company is scaling or has already outgrown the process above, then it’s time to consider a solution like Receptive, which saves time and energy across the whole organization, not just the Support team.
Realizing that your Support team should NOT be dealing with product feedback and then putting a process in to enable that will work wonders for your business — and your Support team will be extremely grateful too.
