Today, I gave the wrong answer to a customer.

Today, I gave the wrong answer to a customer. 

Well, let’s back up. I give the wrong answer all the time; I am often confused, mistaken, or not sure where to start. This is the nature of supporting a web app and 2 mobile apps with integrations into many third party apps. (Frankly, it is also the nature of supporting really smart customers. Quite often, the questions that come into the help box at Buffer are rather advanced.) So, probably more often than I realize, I give the wrong answer, and then I try again. That’s not the problem I’m talking about. 

Today, I gave the wrong answer because I didn’t put my customer first.

Here’s what happened.

A Buffer customer, Jason, wrote in and asked a question to which I didn’t know the answer, so I weighed my options. It wasn’t investigative, so I could either a) take a guess or b) ask a developer. I bet you see where this is going. 

I chose A. I took a guess.

Luckily for me, Jason has a giving spirit, and so he took the time to provide feedback after receiving my reply. (We have a link in the footer of all Buffer support emails where customers choose a happy/sad/meh face and leave a comment. To add this to your support emails, check out Hively.) His feedback, reprinted with permission:

[You] replied without finding the answer. Someone in the dev team will know what I need.”

Sheepishly, I asked in the main HipChat room, promptly learning the answer. I replied to Jason with the answer, thanking him for his candor.

Now this is where it gets fun. After all, honest and constructive feedback is *so* rare. Almost all Hively “frownies” are anonymous with no comments, which are quite hard to learn from. I couldn’t get this out of my head. What had prompted him to be kind enough to take the time to help me improve? Why had he given us a second chance? What had we done to deserve this teachable moment, and how could I learn from it?

I stopped to consider what led up to this exchange. 

There were two identifiable factors at play. The first is that I felt a bit rushed that day. Buffer values customer service very highly, and there is a sweet spot of giving each person the personal, dedicated attention that creates a great experience while not leaving the others waiting for too long. This is the doctor’s office principle; I don’t want my doctor to make too much small talk and waste time with other patients while I’m waiting, but when I have her attention, I value her dedication to me! This is a delicate balance, one I am still striving to find with each new email. 

The second factor was my own insecurity. I ask a *lot* of questions in the main HipChat room, and my wonderful coworkers always dutifully take the time to answer me. Today was a particularly question-heavy day for me, and I started to worry that I had worn out my welcome.  I didn’t want to interrupt again. So I didn’t ask.

Why had I first failed to find that attention/time balance? And then why did I feel insecure about asking for help?

As Chief Happiness Officer at Buffer, my job is to answer these two questions. So here’s what we’re going to do about it. 

1) Hire. 

Sometimes, you just need more hands, and we’re quite near that point. The moment to start hiring is *before* we’re scrambling to get through the day. After all, “working more is never the answer.” In the last 7 days, 3 Happiness Heroes (with help from the rest of the team) have helped 780 customers, with an average of 214 replies per day as a group. I’m quite proud of my team for hitting these numbers, and more importantly, never rarely letting a customer feel like a number. And the time to get another set of hands is now. 

2) Find a better system for engineer involvement and help. 

There are so many ways to tackle this, and I’m looking forward to working with our developers to test some options and find the one that works best for them. Jeff at Wistia shares the “Customer champion” method. Buffer has tried the “all hands” approach, where each person on the team (including developers) answers 5 emails a day. We may explore a rotating “on call” developer so we have some dedicated time to ask these types of questions. And there are doubtlessly many other ways of approaching this. (Do you have any thoughts? Please let me know in the comments or at @CaroKopp!)  Interrupting everyone to “shout” questions doesn’t seem to be scaling! 

And last but not least, I want to say thank you to Jason, who took the time to write the first time, and then follow up. Instead of getting frustrated or giving up, he gave me another try. Here’s to you, Jason! We’re lucky to have you on board!

(And a special thanks to Sunil for knowing the answer I needed here. :))