I wrote a comment reply on “A Better Feature Request Email” (at SupportOps) that covers the elements which I think go into a great customer support reply. I also rewrote an example reply from the blog post. My comment is reposted below or you can read the thread.

Your reply is absolute gold. I don’t have much to add. I completely agree it’s all about being authentic, whatever authentic is. I particularly love the “You company should be customer inspired not customer driven.” I can’t imagine any better way to state it.

My responses boil down to 3 things:

  1. demonstrating that I understand what the user asked for, whether it’s by restating it in my own words or talking through the pros and cons of what they propose.

  2. either clarifying what they’re asking for and why (the back story that led to needing it) or when none is needed needed (like because the request stands alone or we’ve already thought about it), sharing our thought process about it rather than just an answer.

    This is by far the most important part because it means the user is a peer in the process. They should have the opportunity to explain why I’m (we’re) wrong, just like a co-worker of mine would. if I’m suggesting some other way to solve the same problem, it forces me to talk through (justify) its pros and cons clearly.

  3. providing a clear resolution, whether it’s that nothing will be done, that’s the use is on our radar and I see the value but it’s not likely to happen anytime soon, or that we love it enough that it’s likely really soon. (We don’t do a roadmap or anything like that, and I think they – and committing to them – do more damage than good.)

Now I need to put my keystrokes where my mouth is. For a new user with whom I’ve never interacted, I might write something like the reply below. I made up the facts to show a range of responses, though I may only have one. For questions which I’d answered before, the meat would be based on an existing reply. I’d adapt it to the recipient’s apparent interest – is it more “I want..” or “You guys should..” – and technical ability.

Hi James,

Thanks for trying SupportOps and moreover, for caring enough about it to spend the time to send this suggestion. I appreciate it.

There’s not a way to login with Facebook or Twitter credentials. I can understand why you’d want to, though, especially if you’ve standardized on one of them as your login service at other sites. Right now I have so many passwords that Keychain or LastPass are the only way to keep them all.

We do one thing that’s made logging in way less tedious for me: SupportOps’ login time (session duration) is 4 weeks. If you’ve checked “Keep me logged in,” you should not see a login prompt more than once a month.

Based on your email, I think we’ll improve it by resetting the timer on every page view. I know that yet another password isn’t great, but at least you’d almost never see a login prompt. I can’t commit to it, so I’ll let you know if and when that goes live.

Abstractly, I’d like to add third-party authentication. would probably be what we used, since it’s most related to SupportOps. That said, basically all of our dev resources are going into the core service right now. might be used by 20% of SupportCo users, and we’re not done with big changes that improve the service for almost everyone.

(I might also write: “One thing I’ve learned is that aside from the actual integration, providing a great user flow with third-party services is a lot harder than it seems. http://viget.com/extend/facebook-connect-ux-challenges explains more. I think maintaining a great UX would mean we’d need to invest the time to get it right.” -Troy)

I’d welcome feedback here, and thanks again for giving me the chance to talk through our current thinking. if you have any other questions, just let me know.

Troy