When there has been a deliberate change though—one that is important for future development and that almost certainly won’t be changing back—then that sort of apology can be counter productive. If you know that a feature has been removed and is gone for good, it’s unhelpful to offer false hope to a customer of “recording your feedback” and “voting for that to be returned”. It will probably never happen.
Stop apologising to customers and start leading them – Mathew Patterson.
People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.
I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.
In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”
It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.
In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.
If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.
Full stack writing (and publishing). Craig Mod writes about Hi, which is now open to the public. I’ve used the beta a few times. It’s a neat tool.
Why grad schools should require students to blog. Great post about the impact consistent, public writing has upon dissertation work.
In 2010 I wrote nearly 11,000 words in WordPress for my senior thesis. While it’s less polished I spent the last two days writing 8,300 words. My fingers are ready for a break. On to 3 weeks of vacation now.
What is the business of literature?, by Richard Nash, is one of my all-time favorite essays about authorship and publishing. The entire piece is phenomenal and this bit was perhaps my favorite:
It was a sign, almost one hundred years ago, of the book beginning to achieve what most technology will never accomplish—the ability to disappear. Walk into the reading room of the New York Public Library and what do you see? Laptops. Books, like the tables and chairs, have receded into the backdrop of human life. This has nothing to do with the assertion that the book is counter-technology, but that the book is a technology so pervasive, so frequently iterated and innovated upon, so worn and polished by centuries of human contact, that it reaches the status of Nature.
Add that to Instapaper and settle in for some thought-provoking reading.
Bonus link on a related note is Fetishizing the Text, by Kieran Healy.