March 18, 2009
Answering to Customers
Answering feature and support requests consumes a significant portion of my time, but I've found that one simple rule of thumb has been priceless when crafting responses.Early on, I made the decision to answer every request or suggested with a personal response and a detailed justification of our decisions. That is, if someone asked for a feature, I wouldn’t just say yes, no, or we’ll think about it, but rather, I’d offer some insight into whether it had crossed our minds yet, how we’ve thought about approaching it, or why we decided against it.
I told myself that if I can’t justify our decisions or philosophy in writing such that a customer can understand or respect our thinking if not agree with it, then we owe it to that person to reconsider our position. On the surface, this seems simple enough, but it takes time to respond to people. Writing is difficult. Defending or communicating your thoughts in writing can be even more challenging, and that’s a good thing.
It’s easy to tell someone “No”, “Just because”, “We’ll think about it”, or “It’s complicated”, but that doesn’t do much for either party. Taking the time to explain yourself is as much an investment in your own understanding as it is in their understanding. More importantly, it turns the whole encounter into an open-minded two-way conversation. That’s much more valuable because now you’ve got an extra mind that might just be determined to help out. Then everybody wins.
Of course, not all companies could do this because it would mean that the support team would have to have a pretty intimate understanding of the vision and implementation details for a product, but it has worked wonders for me. It might not be sustainable as we grow because it does require so much time to write detailed responses, but I don’t plan on letting go of this practice without a fight.
Comments for this article are closed now, but you can still .
Hi. I’m Garrett Dimon, a freelance designer/developer in Dallas, TX. This is my site about people, design, and technology. I designed and built a bug and issue tracking application called Sifter. Still have questions? Feel free to .
Comments
Comments are closed for this article. If you have a comment or question, feel free to .
That’s an interesting point of view, and one that I agree with for paid products.
I’ve recently been working on a couple of completely free products. The benefit of providing a product for free is as an individual, I don’t have to feel obligated to implement what they request.
I can have the freedom to simply say “Yes”, “No”, or “Just because” at any time. It’s my product, I can do what I want with it and you can use it as is for free. That drastically reduces the amount of time it requires for me to support users.
While I agree that what you’re doing is the best way to go for a paid product, I’m simply mentioning that there is more freedom with a free product.
-beau
That’s a great attitude - I hope the incoming comments and suggestions are equally positive. I know I’ve said it in person, but for anyone reading the comments, Sifter is awesome.
Love it. Also forces you to examine your decisions and philosophy with new insight from actual people who interact with the product. This examination leads to a better product, I’m sure.
Agreed 100%. We don’t use autoresponders or even MailTemplates for our responses, and while it takes longer the positive response from customers is worth it.