Untrained CSMs tend to over-communicate product feedback and over-promise on the timing for solutions. Not every feature or piece of feedback is critical, of course, and frankly, not every customer is either. But properly trained CSMs can help a company consistently collect and use this feedback to improve its products.
To be an effective partner to Product, the Customer Success team has to be in sync cross-functionally with all of its internal partners (i.e., Marketing, Sales, and Product) around how it collects and communicates customer requests. Requiring the CS team to use the same process, tools, and language around these requests will move the needle in building a good partnership.
There are two parts to training CSMs on how to appropriately collect feedback. A good starting point is enabling them to ask the right questions, followed by coaching the team to capture the types and categories of feedback with awareness of how they relate to the company goals.
Ask the right questions
CSMs need to know how to ask questions to get to the root of a problem. Otherwise, they risk collecting unvalidated, unnecessary feature requests.
Here’s a high-level script of questions that CSMs can ask to uncover an underlying issue when a customer shares an idea for a new product feature (beginning with “Thank you for identifying a new product feature that would be valuable to you, tell me a little more…”):
Are there specific teams, workflows, or use cases you have in mind?
How do you expect the way you’re using the product today would change should this feature be introduced?
Beyond describing the features’ functionality, can you explain how the feature will solve a problem?
What roles on your team would be most positively impacted by this enhancement, and why?
Is there a goal you’re responsible for that this new feature would help you reach more easily?
Can you share your screen and walk me through how you interact with the product, and point out an example of where you think this feature would add value in the part of the platform you already use?
What if we did not create this feature? How would it impact your ability to use the product?
These questions will help the CSM understand where the customer is coming from and almost always surface insights not included in the original request. There should also be exploration and expectation-setting around the case that the feature requested is not created. CSMs should aim to record the conversation with the customer to share it with the product team.
This type of training can happen in enablement sessions for the CSMs, if not already embedded in the onboarding or performance management process.
Tag the types and categories of customer feedback
Coach the team to document the “type” and “category” of customer feedback. “Types” of customer feedback include that which is given, requested, and observed.
Given customer feedback includes the types of feedback your customers are proactively sending in (via in-app messages, customer calls, etc.) without being asked or encouraged to do so.
Requested customer feedback is all feedback or suggestions. (e.g., NPS, onboarding feedback, reviews, surveys, or in-person interviews.)
Observed customer feedback is the feedback you get from monitoring how customers interact with your products, the paths they follow, and the documentation they read.
After identifying the type of feedback, team members should tag the “category” of feedback, which might include:
Feature requests,meaning requests for new features or functionalities
Product pain: Customer is having trouble using a feature
Bug: Something is broken, slow, or not intuitive
Education pain: A feature or workflow is not documented, or existing documentation needs to be improved
Unaware/hidden options: meaning a customer requested something that already exists in the product—these instances need to be tracked to improve onboarding
Billing: Any billing issues customers have
Using a consistent tagging mechanism across the customer success team will help the product team quickly understand tasks. The “category” may be broader or narrower depending on your company’s product complexity and its customer’s experience, but the agreement between the Product and CS teams will ensure clarity along the feedback loop.