May we suggest...


Why We Don’t Scale Support at Buffer

I 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.”



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. :)


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.

Å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, 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.

    • 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.

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

  • 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

  • Greetings & Salutations,

    First and foremost I’d like to say that I’ve been utilizing and supporting Buffer as a Premium User for multiple years. I’m a fan of the Buffer App, the Buffer Team, and have personally recommended/assisted/setup/managed Buffer premium accounts for ≈ 20 – 25 clients, colleagues, friends—most of whom have also remained longterm, satisfied Buffer customers, as well (I cannot attest to an exact tally, at present. However, I’m aware of no less than 14 existing +longterm Buffer premium account users, all of whom joined solely based upon my recommendation)

    I fully agree with the business/direct marketing philosophy, practice, and budgetary allotment with regard to providing exceptional, personal customer service to existing clientele. My experience is unambiguous proof that providing exceptional customer service has not only ensured my continued patronage, but what’s more is (Buffer’s ROI for) the same 33% of my membership fees that have been allocated to the company culture of customer service has produced a MANIFOLD increase in revenue—an ROI of ≈ 300% per each word-of-mouth new client referral—an increase in revenue that, almost certainly, could not be obtained through increased marketing, lowering costs, raising prices, etc.

    That said, 1) The supposition that “…why have you chosen not to have a searchable knowledge base…” equates “scaling support” is simply fallacious, nothing ambiguous about it! 2) That having “a searchable knowledge base” (just for example) could AUGMENT enhance, and improve the existing method; nurturing the personal, developer-client, human-to-human relationships, and fulfilling the feedback caveats are not mutually exclusive.

    I have contacted customer support at Buffer via Twitter and came away from the experience feeling less valued as a customer than before contacting them. (No being able to delete old, unused articles from the RSS Feed) It was a waste of my time. This article reminds me of that experience. If customers tell you they want a certain User Interface, but you’re saying: “No, we think this way is better for you. We only devalue your opinion when it’s what we think is best for you.”

    Does that make sense to you? (It’s really more rhetorical than anything else. I really love Buffer, and want to do all that I can to help it continue to improve and evolve! ? Thanks)

  • Sylvia

    Carolyn, thanks for the simple chart and explanation! I never thought about not scaling so you can stay sharp and retain a sense of urgency to personally take ownership of customers’ issues. It’s wonderful to hear that there’s executive support and team capacity to allow for these valuable interactions to take place and apply strategic pressure for solutions to develop – slightly jealous! :)

  • Alexis Lewalle

    Back in the beginning of 2015, my company at the time was using Zopim and Slack to cover its communication needs. Working with these two tools in addition to exchanging regularly with fellow entrepreneurs who were using Intercom, led to our aha moment: why not use Slack as an admin interface to chat directly with our site’s visitors and clients? All communication handled directly from within Slack! Eventually, we managed to turn this crazy idea into an actual company. February, 2015 Slaask was on the scene: an absurdly simple customer chat tool for Slack. It’s been working like a charm for us as well as for others. It’s both increasing our team efficiency and bringing us happier customers! :D Have a look for yourself :)

  • Antonio Licon

    I wonder if monitoring traffic metrics on your knowledge base could provide much of the value you are looking for here. Spikes in traffic to things like “How do I change my credit card in your system?” should show up in a report that is regularly read by Customer Success and or Product Management (depending on team structure).

    A well executed KB can provide those 500 visitors with nearly instant access to available solutions. A personal call, email, or chat exchange can make you feel valued, but as a customer I am much happier to find a quick answer.

80,000+ social media marketers trust Buffer

See all case studies