Why We Don’t Scale Support at Buffer

5040056677_2cf26f2733I recently got an email that asked this question, and it comes up a lot in the support world.

“I see you have a static FAQ, but why have you chosen not to have a searchable knowledge base or robust community forum for support questions?”

I’d love to share why we chose not to scale support, and why we ask customers to email, tweet, or live-chat us each time instead. It’s very simple, and it’s all about how fast we can learn.

Simply, we don’t learn anything if customers find the answers themselves on a forum or knowledge base.

Why we don’t scale support

As an example, let’s say we get the same question 5 times. I’ll use a real-life Buffer example. “How do I change my credit card in your system?”

So, after the fifth time this question is asked, Company ABC might put it on a knowledge base. Then the next 50 people who have the question might find out themselves. They don’t have to wait for your customer service team to get back to them; they can find the answer at any hour. Right?

At Buffer, in this example, we haven’t put it on a searchable forum. So we are still answering the next 50 questions about this. That’s nearly one whole day for a Happiness Hero! That’s pretty darn expensive, especially when multiplied by every common question. This is often the exact math used to prove that knowledge forums are great.

But what happens next? And more importantly, what happens to the next 500 customers who have this question?

At Company ABC, the next 500 customers who have this question have to go find the answer in the forum.

Whereas, at Buffer, we answered the question 50 more times, reported this to our product manager, and then our product and engineering team fixed the confusion in the interface. Now, there’s a big, splashy link that says “change your payment details.”

image

 

The next 500 customers who visit the billing section don’t have that confusion at all. They don’t have the question in the first place. They never experience the feeling of having to search a forum for an answer. And the next 500 after that. And the next 500 after that.

We think that’s the best way to serve our customers. We try to give our customers very few chances to find an answer without letting us feel their pain first.

Here’s how it plays out, if you simplify it all a great deal. :)

image

I think this discussion often gets cut off after stage 3. At stage 3, no doubt the public forum is looking pretty good, and “not scaling support” looks pretty silly. We believe that, for us, the process truly extends through the 4th and 5th stage, which feels like the best service we can give.

3 requirements for this method

Now, while this is the best way for us, I definitely don’t assume this is the best way for all companies. There are a few important caveats to this. Here are 3 very key pieces that need to be in place, most of which revolve around resources.

Caveat 1) Enough executive support and budget to hire enough people to handle the first 55 questions in the first place.

If you’re a team of 2 people supporting several million customers who get in touch a lot, and you’re drowning in emails every day and night and haven’t taken a weekend day off in 3 months, then it might be more important for you to *not* get the next 50 emails than it is to get a comprehensive sense of where your customers are finding confusion.

We are incredibly lucky to have a huge (huge!) amount of support from our CEO and COO. They believe in the value of having a large team devoted to customer happiness, and they allot a large part of our budget to paying this team well. One third of the Buffer team is on the Happiness team. I recognize that this is an unusually generous percentage! With these resources, we devote a great deal of energy to our support experience. We constantly talk about improving our response times, as well as the words we choose, so that the first 55 customers have the best experience possible.

Caveat 2) Open feedback channels with the Product and Engineering teams

This is also key. If your engineering team doesn’t have the time or bandwidth to make changes based on customer confusion (or worse, if the product team isn’t interested in hearing about this feedback), then it doesn’t make as much sense to put your customers and your Happiness team through the second batch, the 50 emails from Stage 3. May as well put the answer on a forum and save both groups the trouble.

We have a weekly meeting with our Product Manager, and together we prioritize every issue we bring him. He then assigns them so the engineers can tackle fixes.

Caveat 3) The tools and time to keep track of all of these questions and areas of confusion.

We’re constantly adjusting the specifics on this one. The bottom line is, it takes a fair amount of organization, and, as a throwback to caveat #1, it takes man hours to maintain. In order to manage the initial 55 reports, we use use a variety of tools and a chunk of Happiness Hero time. Here are the two most important tools:

a) Trello: Every “issue” reported by a customer (through email, twitter, live chat, or any other touchpoint) gets a card on the “Bug Board.” Every instance of that issue after that is added as a comment. The cards with the most comments are prioritized higher.

Trello bug board

Adam keeps this organized by combining repeat cards, understanding each issue and making judgement calls about which ones are the highest priority based on frequency and also severity. This takes significant time, which he wouldn’t have if there was no slack in the team.

b) Help Scout tags: The majority of our support requests come in through email, and they’re not all exactly “bugs.” For example, in the example above, there was nothing functioning incorrectly per se, just something unclear in the interface. So, we “tag” every email with the area of the product, even the ones that don’t get reported to trello. You can check out our live report of current tags, if you want to take a peek. :)

Åsa manages this. She checks which tags were the busiest each week, and then looks through those emails and pulls out some specific areas of confusion. The example above is a perfect representation of this. We had several huge weeks of “billing” tags, and she reported that many people were asking how to change their cards. Voilà.

(More about this process in our April Happiness Report! :))

So, there you have it. The reason we have chosen not to scale our support team, and the incredible luxuries that have allowed this choice to work. Of course, this is the way we’ve chosen to move forward, but like every choice, it comes with its own consequences. Choosing to have a team of 8 people introduces communication challenges that the team of 2 didn’t have. It would be amazing to hear from you guys about any piece of this. I’ll happily share anything I know and would love to hear how your teams handle this decision! :)

This post originally appeared on my personal website, carokopp.com. Feel free to browse the archives for even more insight into customer service and support.

Image Credit: GollyGforce

  • saravanamv

    I quite like to read all your posts, but probably I will not agree with this one. There are certainly some pros, you get a chance to speak to the customer, and in addition to the issue they are reporting you’ll also get a chance to get feedback on other areas as well.
    Also, assuming every single problem can be fixed by a better design in the product is not true. There are certain things which can only be documented and explained.

    • Bradley Ford

      I tend to agree.

      Yes there are definitely advantages to talking with the customer both from a learning and relationship point of view.
      But I think the exact learning you have described above could also be gained by monitoring hits and time on page for each of the knowledge base items.

    • http://primeloop.com/tk thomasknoll

      That is the excuse of a lazy product person. Anything and everything that could be solved with a knowledge base can be solved with a better product.

      • Paul Watson

        I’d rephrase that somewhat. There are issues (forgotten passwords, forgotten usernames, overloaded client browsers) which no product design can fix but that are equally unsolvable by a KB. You also get people who are in a rush and no matter how clear your forgotten password link is will still want to reach out to human support.

  • Cordelia Blythe

    Your article presupposes that a searchable knowledge base doesn’t provide feedback – it does. Any half decent scalable support system tells you: how many times each article was accessed, how the customer found that article (search vs browse, and specific terms searched), and how many articles they accessed during their visit.

    I’m also always shocked when I hear how few emails other support desks answer per person per day. I was part of a remote customer service/social media team for a Facebook game publisher and our target was 30 emails per hour – and that included the time our team spent writing new form answers. Form answers not only ensure that all customers get accurate and well written information but also ensure the whole team is using the same tags on their answers. These tags were then used to generate reports of how many times an issue had happened.

    We were in the process of upgrading the forum to allow to something more suited to support that would give the tracking most scalable help desks offer and working with our help desk software provider to increase the facebook page integration (their beta run was limited to two pages). Unfortunately the company decided to end all North American operations, including the remote team.

    I’m probably biased but the remote work-from-home model of customer service has some big advantages. You can get a lot more coverage from staff that can check in multiple times per day and provide just the support that’s needed when it’s needed than from staff working set hours in an office. Remote workers also tend to clock out if they wander off to the watercooler as they have usually have productivity targets to meet rather than hours to fill. ;)

    To sum up: Scaling your customer service doesn’t mean losing the numbers, or even losing the human touch. It does mean that a certain subset of customers who prefer to self-serve get their answers faster and with less frustration. There are some great tools out there, and for smaller companies that can’t afford the shiny tools a small team should be able to get a good sense of what the common issues are even if they lose out on those who use the self-serve options.

  • http://workado.com/ Justin McGill

    Hah – I actually had to email support to figure it out myself how to update the payment details so glad that got updated :)

  • http://www.jitbit.com/ Alex Y.

    Well, you DO scale support – by adding the “change payment details” link. :)

  • Donal O’Conghaile

    Great post, I 100% agree! Support is essential to understand your user’s experience. We learn SO much every day just from emailing & tweeting with them one on one.

  • Mike Gozzo

    Carolyn, it was great seeing you at Userconf and this post really highlights the way you guys are kicking serious butt when it comes to customer experience.

    I’m working on a startup that embraces the approach you’ve described here and promotes personal interactions between users of an app and the makers of an app. Still early days but you can check us out at http://supportkit.io