4
14 Comments

How to respond to customer suggestions/requests which you know you're going to ignore?

How to respond to customer suggestions/requests which you know you're going to ignore?

tldr: I've wondered this as a creator, and was reminded that I still don't know the answer when I ran into it recently from the customers' side. Does anyone know the best way to handle feedback you intend to ignore?

Long version: I recently spent about $3000 as a customer of a fairly early-stage startup. Their service is important to me, and they solve the problem, so that's all fine. But their UX enraged me for a variety of reasons which I felt were both legitimate and important. I wrote in with my perspective and potential fixes, and they (politely) placated me and brushed me off.

I understand their decision strategically (not every customer request should be done), but the experience of the brush-off for something I thought was important (no matter how polite) really felt terrible as a customer, and if they had competitors for me to switch to, then I absolutely would.

Has anyone found a correct way to handle this situation, where a customer legitimately wants something and you know for a fact that you won't be doing it? Thanks :)

on February 12, 2019
  1. 2

    I find this difficult as well to be honest. It's great to fulfil a request as customers are generally really happy when this happens, but to tell a paying customer that a feature is never likely to happen feels difficult. I've had lots of requests which would require months of development and take the project in a completely different direction as well where you really have to say no.

    Generally I ask them why they want the change because maybe there's a compromise that would make them happy, then explain the rationale about why the change wouldn't work. Most of the time they're fine with it and seem to understand.

    I wouldn't like to give a generic "thanks, we'll consider this in the future" reply you get from most big companies though.

    1. 1

      Lots of great suggestions across the thread, but for my particular experience, I think this rings most true. I think what made me so unhappy (as a customer) was that it felt like they hadn't even spent the time to understand why I was bothering to make the request, and why it mattered so much to me. If they had done as you suggest and sparked up a conversation asking why I wanted it, I think that have gone a long way toward making me feel respected as a customer, even if they had ultimately ignored it. Cheers for the input -- will keep that in my pocket for next time I'm back on the seller's side ;)

  2. 2

    We don't say No necessarily but for situations where we don't want to do it for the customer, we give them 2 choices:

    1. We can consider it for a future release but cannot prioritize at the moment as our pipeline is extremely full.

    2. You can pay for this customization and we will dedicate a resource to it.

    Remember that as a client, you may feel that your feedback is legitimate (and it very well could be) but a business deals with many customers like you who are entitled to their suggestions. In many cases, the suggestions don't make sense for the business from an overall perspective. You can only do so much.

  3. 2

    Seeing no one has mentioned what I'm about to say, I'll share what I do at my company.

    All my customers know that all feature requests are considered seriously. We also share with them that the feature request needs to generally benefit the application and its overall user base.

    Having said that, if a certain customer is someone who we've worked with for some time and has a reasonable request but the request doesn't really fall within the scope of what we're trying to do, we usually present with them the option of creating that option for them at a price.

    The reason we mention the price of it is to bring into the discussion our own (ie. my company's) cost of building this. We are truly taking a detour (from my developer's time, which costs money) for a single customer. The price of the app is really for what currently exists and the subscription to our vision for this app. If a customer wants to suggest a route we should take but doesn't want to put up some development costs, it's unrealistic given we (the operators of the business) are the ones assuming the risk.

    I'd present it to them that way. Most business owners understand this and appreciate the honesty that we both are business operators.

    1. 1

      Interesting...can I ask what your general template is for proposing this without sounding cheeky about it? e.g. "Yes, we could do that for $X". Do you get negative responses from this?

      Also, if you make these changes available to all customers, how do you prevent your product becoming a mishmash of competing features?

      1. 1

        Yes, pretty much that. I'd add that it's something we can look into, but it would fall under our special request category upon which we can consider. If they are still interested, I'd provide a quote of how much it would cost.

        In terms of choosing which features to implement (even with the paid development by the end users), I'd say that we still vet it to some degree. It's a case-by-case type of thing.

  4. 2

    Good question. Alchemist Camp exists only because a predecessor ignored my requests regarding UX. Strangely, that competitor has largely abandoned the market since I joined it.

    Maybe the best option would be to really think hard before ignoring heartfelt customer requests!

  5. 2

    If someone is asking for something that we can't and won't offer at any point, I'll usually let them know it's not in our future plans and explain what we're working on instead, sometimes with a brief why as to why that's important.

    I'll also usually ask if it's a dealbreaker and if it is, I'll happily point them in the direction of a competitor or (preferably) a complementary product which does what they need.

  6. 1

    Happened a few times and we politely tell them that if we get similar other requests or we decide that we'll need this feature in the future, we'll add it and let him know.

  7. 1

    I think its best to say directly you won't be doing it in the near future.

    Nobody who is interested in your product, cares beyond the near future of it. And most can read between the lines, that its a "probably never." And give as little reason for the decision as you can get away with, preferably none. If you give a reason you encourage discussion, and that extends the feeling of rejection.

  8. 1

    I'd just be honest and tell them that it's not something that was in our plans to do. And explain the rationale behind why. I don't like to bs customers, especially because I hate that feeling of people peeing on my head and telling me its rain.

    That way a customer can find a service that's a better fit for their needs.

    1. 1

      I also usually respond that this is not a priority and this is why.

      In a lot of times for my project https://diffy.website I got a question if users can provide steps before taking a screenshot. So my usual reply is that we do not do functional testing at the moment and if they want to do that -- please use our competitor X, Y, Z. We are positioning on different proposition.

      I usually can't refuse requests from non-paying customers. If they ask something that is missing if it makes sense I ask them to sign up for paid account and then we build it within X number of weeks.

      But that is a different story.

  9. 1

    Probably something along the lines of "Thanks for the suggestion, but this is something which is not in the pipeline for the immediate future."

  10. 1

    This comment was deleted 6 years ago

    1. 1

      It's a vetted marketplace of premium freelancers in a certain industry. There are plenty of other generic marketplaces, but none with the level of guaranteed quality that these guys have been able to pull together.