The right way to respond to feature requests

If you work in customer support, you’ll likely encounter a familiar situation: a user will ask about a feature your product doesn’t support.

Even the best products with the most passionate users will have these “success gaps” – a disparity between your product and the user’s desired outcome.

It’s easy to respond to these feature requests with a generic “Keep an eye on Twitter for updates” response or a pre-canned “We’ll pass your feedback onto the product team” message, but we’ve found that it’s valuable to mine these feature requests for deeper information so that you fully understand what the customer is trying to achieve. That way, you’ll be able to strike a balance between keeping customers happy and collecting valuable information that will improve your product’s core value.

”It’s perfectly okay to acknowledge that a given feature is not supported.”

Here’s our best practice guide for handling feature requests in customer support.

How to manage different types of feature requests

Firstly, it’s worth highlighting that not all feature requests are the same. They can be broken out into three different types:

1. Unresolved problems with an existing feature e.g. the customer has experienced a technical issue and is unsure how to make progress.
2. Feature improvements e.g. the customer is not sure on how to achieve a certain result with your product.
3. A brand new feature request e.g. the customer is asking for something that’s not yet supported in your product.

Let’s explore these in some more detail.

1. Unresolved problems with an existing feature

If you have a software product or web app, there are almost certainly parts of your product that aren’t always working as well as they should be. You’ll likely have customers writing in to say, “Hey, this feature I rely on (and pay for) isn’t working. I need help ASAP.” Sure, you could just log the issue in Github and move onto the next conversation but a good support team should be able to educate a customer on how to get to the right outcome, regardless of technical limitations.

In these cases, use the request as a jumping off point for a deeper conversation about what exactly they’re trying to achieve. Ask for specific examples and details about the issues they’re running into and act as a consultant on helping them achieve a given result in your product. (I’ve shared some tips for asking these questions in another blog post.)

Avoid committing to a specific time and dates when the issue will be resolved. It’s best to over-deliver rather than promise a specific date and fail to meet it. Instead, share any known workarounds for getting around the problem in the short-term. Quite often, customers don’t care if specific features or functionality aren’t working provided they can still get the job done. Going the extra mile and getting customers to their desired outcome will really help you build customer trust and loyalty towards your company.

2. Improvements to an existing feature

Another common scenario is when customers ask for a new piece of functionality in your service. Your Customer Support Reps are your front line, so they will likely be the first people to hear about missing features that are leaving customers disappointed.

Resources at any startup are limited and it’s simply not realistic for your product team to build every feature improvement request that comes in. Instead, you should take a step back and think about whether or not you can solve the customer’s problem without any product being built at all. Quite often, what looks like a functionality gap might actually be something that has already been addressed by your product team, just in a different way than what your customer would like.

For example, one feature that is regularly requested by Intercom’s customers is the ability to turn off the Intercom messenger outside of their working hours. This isn’t a feature on the product roadmap right now but we can get customers to the same outcome by helping them set customers’ expectations through setting their office hours and expected response time.

These answers may not be exactly what the customer wants to hear, but an honest explanation and workaround is often enough to satisfy what they originally asked for. In many cases, customers are simply unaware that an existing feature can be used just as successfully in your product.

3. Brand new feature requests

The trickiest conversations to handle are when something is really not supported in your product. Before you respond, ask yourself: Does this request fit into your roadmap and strategy for how you’d like to develop your product?

Instead of making promises on something that will never come into life it’s better to be honest and say no to it (so long as you’re suggesting a viable workaround).

It’s always important to be honest with your customers, so long as you share the context on where this decision is coming from.

If the customer is asking for something very specific that’s not on your roadmap, try suggesting a third-party solution or integration that fits that use case. For example, if a customer is looking to manage their calendar, YouCanBookMe already has a solution in place, while Zapier allows you to integrate with dozens of other types of software. Instead of making empty promises on something that doesn’t align with your roadmap, think of possible solutions outside of your own product.

It also matters how you talk about gaps in your software. Instead of trying to look for excuses or bending the truth, share some context with your users. It’s perfectly okay to acknowledge that a given feature is not supported yet (while explaining the cool features your engineering team are currently building) but that you’re currently looking at ways to improve experience around the customer’s specific pain point.

Sharing details about how you make these difficult decisions and explaining that you’re dealing with limited engineering resources will show your human side and help the customer see your perspective. After all, there’s never enough time to work on all the ideas you want while at the same time staying on top of bugs and issues and making sure you’re aligned with your company mission and long term strategy.

How to prioritize feature requests

Once you’ve gathered feature request data from customers, along with their relative importance, you need to find a way to prioritize the suggestions.

Potential factors you’ll want to include are:

1. Customer lifecycle. You might want to respond to customers who contact you in the first days after sign-up, as they are at the highest risk of churning.
2. High-value users. As they are the customers paying you the most money, you’ll want to pay particular attention to their feedback. Especially if this group plays a crucial role in your long-term growth.
3. Difficulty of implementing the proposed improvement. Some feature improvements might be relatively straightforward to implement, and provide 10x value to customers. On the flip side, some improvements look simple, but require months of complex engineering.
4. Volume of feedback. Logging the number of times each individual product improvement has been suggested can help you make a case for bringing a particular feature request to the product team.

Closing the loop

Once you’ve gathered and prioritized this feedback from your customers, you should think of ways to feed it back to your product teams. After all, if 50 customers can’t find a given button every week, this is a sure sign something in the interface needs to be fixed.

The way we manage this internally is by tagging every single question we get (in Intercom of course). It does require some effort, but once you’ve embedded this into workflow of your team you’ll get great data on types of conversations your team is having. On top of that our research team creates customer voice reports on a monthly basis showing the main pain points raised by our customers. This gets shared with the relevant Product Managers so they can prioritise working on specific features and decide what should make it to our roadmap. If you’d like to have some more powerful ways of organising this feedback you could take a look at third- party integrations such as Productboard, NomNom or Trello PowerUp.

But regardless of what tool you’re using, the most important thing is not just to gather feature requests, but to act on them too. Whether that’s with a polite, personal response, or an actionable idea handed on to product or engineering, when customers have made the effort to offer a feature request or suggestion, it is only right for us to make sure we respond in a manner that builds long-term customer success.