This article originally appeared on Carokopp.com.

‍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 a bit selfish.

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

Why we don’t scale support at Buffer

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 5th 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.

There are 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!

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

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’vechosen 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! :)