Knowledge base (KB)

A knowledge base is the primary self-service channel for most support teams. It holds how-to guides, troubleshooting steps, policy explanations, and short FAQ answers, organized into categories and searchable, so a customer can find the answer without writing to you. Public knowledge bases are often called help centers. An internal knowledge base is the same idea pointed at your own team, holding the refund policy and the escalation runbook.

For a team of two to ten people, the knowledge base is the single most useful thing you own, and the reason is arithmetic rather than philosophy. Support volume in a small company is extremely concentrated: a handful of questions account for most of the inbox. Write down the answer once and it works for every customer who asks it, forever, without any of your time.

Worked example. Say you handle 200 conversations a month, and when you actually count them the top eight questions cover 90 of them. You write one good article for each of those eight. If a third of the people who would have written in find the article instead, that is 30 conversations a month gone. At six minutes to answer one properly, you have bought back three hours a month, permanently, for what is maybe a day of writing. The same eight articles also make every remaining reply faster, because you can link them instead of retyping the explanation.

The articles have to be written in the customer's words, not yours. People search for the thing that went wrong, not for the internal name of the feature it went wrong in, so an article titled "Configuring SMTP relay authentication" will never be found by the customer typing "my emails are not sending." The cheapest source of good titles is your own inbox: use the subject lines customers actually sent you.

The real cost of a knowledge base is not writing it, it is keeping it true. Every product change, price change, and policy change leaves stale articles behind, and a customer who follows instructions that no longer work trusts nothing else on the site either. A small library that is accurate beats a large one that is half wrong. Two habits keep it honest: fix the article as part of shipping the change, and every time you catch yourself explaining something in a reply that the help center should have covered, fix the help center before you close the thread.

Knowledge bases have also quietly become infrastructure for something other than customers. AI support tools, including the AI answering questions on your own site, draft from whatever you have written down. A thin help center produces vague AI answers and a thorough one produces specific ones, so the writing now pays twice.

AcornReply gives each workspace a knowledge base with two kinds of entry, short FAQs and longer articles, sorted into categories, with a public help center that has full-text search, its own sitemap, and the option of running on your own domain. The same entries are what the AI drafts from, so an article you write improves both the self-service answer and the reply your team sends. There is one thing worth being precise about: when you resolve a conversation, the answer is distilled into a private knowledge entry that only the AI can draw on, and a filter keeps entries of that kind out of every public page and out of the sitemap. A resolved conversation never reaches your public help center on its own. Anything customers can see was put there by a person in the knowledge settings, by import, or through the API.