Researchers at UC-Riverside did a study on whether people preferred to receive and deliver bad news first. While most people were more likely to respond favorably when bad news was delivered first, and good news delivered after; most people wanted to perform the latter. That is: more people (70%, according to the study) wanted to say the good thing first, and then deliver the bad news later.
In customer support, we must overcome our instincts, and deliver the bad news at the start in order to get the hopefully best response from our customers.
So, take for example that someone is asking for something that you know is never going to be built into your product. That’s rough news to share and is a little bit more difficult than the typical feature request response. A great way to do this, following the bad-news-before-good-news formula is:
Hi there,
Thanks very much for emailing about this — that’s a great question. I could certainly see how this might be useful for you, but this isn’t something that we have planned on our product roadmap. I know that’s probably hard to hear, but luckily I do have a workaround I can recommend. Check out [documentation] and you can read a little bit more about how it works.
I hope that helps, but please let me know if I might have missed the mark or you have any other questions.
As you can see, it follows a similar format to the feature request template but does have some slight tweaking to adjust for introducing your workaround. If there isn’t documentation for the workaround that you are telling your customer about, replace that sentence with information about how to do the workaround that you are recommending — maybe even make a saved reply for it if it’s something that you do frequently!
When you write the response in this way, instead of leading with the positive and ending with the negative, your positive workaround will be the last thing in the customer’s memory.