At long last, we finally arrive at the end of the first Support Ops series. Here’s the email mashup that we started with:
Thanks for your feedback. Our app does not include that tool at this time. I apologize for that inconvenience.
We get lots of requests each day so we’re not able to respond to each one. But do know that we read each and every one of them.
Let us know if you have any questions or comments. We appreciate you using our app.
Have a great day.
The App Team
Over the past few weeks, we’ve tweaked this and swapped out that. Some of the email just got removed entirely. In the end, we’re got our better feature request email:
Thanks for checking out my Support Ops app!
There’s not a way to login with your Facebook or Twitter info yet. I’m sorry about that!
I can definitely understand why this would be handy, though! Having a single login would save time so you won’t have to remember all the different ones you have for apps that you use. I’m talking with my development team later this week so I’ll make sure to show them our email conversation and add your vote for this one.
If you have any other questions, just let me know and I’ll be happy to help. Thanks again for checking out Support Ops and have an awesome Friday!
– Chase Clemons
That’s a better email. Gone is the cold corporate feel. The better email hits all the right points in a short, friendly, and personal way. It’s an email that a customer deserves.
With our first series wrapped up, I wanted to leave you with a gift. Head over to see our first ever ebook on how to write a better email. You’ll take everything you learned in this series and put it to work with other common emails support teams get.
I love the blog and the focus, but I don’t think this email (the “after” one) is very good, let alone a shining example. If I received it, I’d think:
1. It uses too many exclamation points to be authentic. Almost nobody writes breathlessly when writing naturally.
2. The sentence “I’m talking with my development team later this week so I’ll make sure to show them our email conversation and add your vote for this one.” has two cardinal sins.
First, it’s not clear what the outcome is. Are you going to get back to me? Do I just sit on it and cross my fingers? Does it land on some “roadmap” that may or may not get used?
Second, it ignores your (or your product person) vision and defers to the least-common-denominator of product design, namely, design by committee. Votes on UserVoice, GetSatisfaction and the like are basically idea dumping grounds. If it’s worth implementing, great, say so. If it’s not in line with your vision for the product, also fine, say so and explain the thought process. And if it’s somewhere in the middle, that’s basically a no.
We all agree that the the “before” email sucks, but at least it’s clear what I’m getting (nothing) and I can plan around that.
3. Between the exclamation points, the high energy without specifics, and the “Thanks again for checking out Support Ops and have an awesome Friday!” closing, it feels like you’re pandering to the customer rather than treating them as a savvy peer. To paraphrase a co-worker who read the email: it felt like the customer was in daycare.
Thanks again for the great blog and the chance to talk about and work through issues like this.
Chase Clemons says
Thanks for the comment! I’ll tackle those in the order you pointed out.
1) It could be depending on your writing style. The big thing with emails is to match it up with your style rather than just copying what works with me. I’ve worked with people that use less exclamation points and a few that used even more. If your customers keep pointing it out in their replies, definitely scale back on using them.
2) If your team has completely ruled something out as a feature, then go ahead and let them know. You’re exactly right in that they need to know so they can plan. For instance, Gantt charts will never be inside Basecamp. When customers ask for those, I let them know that as well as some workarounds.
With things that aren’t a definite yes or no, I think it’s fair to be honest with a customer on that too. At 37signals, we don’t have a roadmap of upcoming features so literally anything is possible if we haven’t given a definite no. A middle ground could be no but it could also be not yet or even we’re working on it but can’t promise it’ll launch.
Re the design by committee and those dumping grounds, that’s another one I agree with you on. That can happen if you’re not careful. But keeping track of the common requests and problems that pop up from customers will let you know what you need to be focused on. That way, you can improve pain points and make your product better. But you’ll do it in a way that doesn’t give the reigns over to the customer entirely.
Bottom line – You company should be customer inspired not customer driven.
3) This one comes back to personal writing styles too. I’ve worked over the years to develop my own style so that it’s upbeat but still helpful. To some customers it might feel pandering but in the past two years, I can count on one hand the amount of times a customer wrote back to me feeling that way. Your customers are going to be different than ones I work with. Keep that in mind as you work on crafting your replies. What works for me might need to be tweaked to work with your customers.
Whew – I think I hit on all those points you mentioned! Thanks again for sharing what you thought on this one.
Would you mind sharing an example of a feature request email that you’d send to a customer? I’d love to see how you approach it.
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.
— START —
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.
— END —
Chase Clemons says
Wow – love it! Your reply is rock solid and your personality really comes through in it.
“They should have the opportunity to explain why I’m (we’re) wrong, just like a co-worker of mine would.”
That’s an awesome way of approaching these feature requests. As a customer, I’d love the honesty and transparency that it creates.
Overall, I think you nailed it! The great thing with feature request emails is that you can approach them from a few different angles. If I was one of your customers, I’d be happy with that reply. 🙂