“Does that help?”

There’s a company I rely on. Sometimes something goes wrong; I create a support ticket. Often the response is: “I’ll forward this to an engineer.”

Days or weeks go by. No reply. Then I get an automated message saying: “We’ve closed the ticket because there isn’t any activity. If you want to re-open it, you can’t. If you still want help, create a new ticket.”

This company tries to use automation to keep things more efficient for their support agents. They hope the efficiency trickles down to their customers - the fewer inactive open tickets, the more tickets they can actually spend time fixing. They’re trying to be helpful. But they’ve let automation screw this conversation up.

One thing I was taught to do as a young employee was to end all my emails with: “Please let me know if you have any questions or concerns.”

Which seemed funny. It was used by everyone, like an automated part of our email signature. I found many of us using it, when, in reality, we didn’t want a reply. It started sounding like a polite way of really saying: “I hope this email has everything you need. Please, for the love of god, let it have everything you need, so this conversation can be done.”

But I cherish the support conversations I have today about Draft, the software I make to help people write better.

Of course I’d rather be making useful things than answering email all day, but I still acutely feel the days when I didn’t get to answer any support email because no one was using the things I was making. Now a lot of people depend on my work, and I don’t want those conversations to end. Those conversations help me make even more useful tools.

So I end support replies a little differently to see what happens. Instead of: “Please let me know if I can help any further with this (but you probably don’t think I expect a reply),” I explicitly ask for one.

I end with: “Does that help?”

The short question generates quite a few responses. Instead of the support ticket going dead as soon as I reply, I get: “Yes, that helped. Thank you!” And I can sleep a little better knowing I haven’t left someone frustrated.

But even more importantly, I get: “No, that didn’t help. Here’s what I meant…” And now I have a second chance to understand my customer and solve their problem.

This helps avoid what I really fear, something going unfixed and the loss of their business, because the customer didn’t want to “annoy” me a second time, when that couldn’t be further from the truth.

For those of us fortunate enough to now have customers, don’t squander these opportunities to create meaningful conversations. Don’t be so quick getting your customers out of your inbox. Or you’ll be back where we started - plenty of time to answer customer support questions, because there are no customers around to ask them.

P.S. I’d love to meet you on Twitter: here.

Or I can email you my next blog post.


Now read this

Design Inspiration from Svbtle - The trouble with being efficient

Being good developers and designers, we typically define reusable features like a navigation bar or a footer and include them in multiple pages of our design. In PHP we might use “includes”. In a web application framework like Ruby on... Continue →