What Should Go Into a Business Content Knowledge Base?

Most of what a business produces in a week is not something a draft can safely use. A business content knowledge base holds the part that is: answers that worked on calls, the questions customers really ask, objections and the replies the team trusts, proof the client agreed to, product facts with a date, the customer’s own words, the positions the founder argues, and the style rules every draft follows. This guide is about the admission decision for each of those nine kinds of material, what stays out on purpose, and what to collect first so a small base starts working before it is complete.

What a business content knowledge base holds, and what it leaves out

A business content knowledge base holds the material a model or a writer should draw on when writing for the company, and only the parts of that material someone has checked. It is narrower than everything the business knows, and much narrower than everything it has written down. The test for any item is not whether it is true or interesting, but whether a draft would be better and safer for having it.

That narrowness is the point. Language models are weak at two things a business cares about: the 2020 paper that introduced retrieval-augmented generation for knowledge-intensive NLP tasks named explaining where an answer came from and keeping stored knowledge current as open problems. A knowledge base answers both, but only if each item in it has a source and a date. A shared drive of decks, call recordings and old proposals has neither, which is why it behaves like a memory rather than a reference.

This post does not repeat the structure of the base. The files, the fields on each entry and the test that proves the base sounds like the company are in how to build a knowledge base for AI content, and the path a sentence takes from a sales call to a published post is in how business knowledge becomes automated content; both sit with the rest of our business knowledge guides. The question here comes earlier. When a piece of material lands on your desk, does it go in, and in what form?

The admission test: four questions every item must pass

Every item earns a place in the knowledge base by passing four questions: would a draft use it, does a named person vouch for it, is it still true, and may it be published in some form. An item that fails one is not deleted; it waits in the sources folder until it passes, or until it plainly never will.

The first question removes most of the volume. A draft needs an explanation, an example, a figure, a phrase or a rule. It does not need the meeting’s small talk, the scheduling emails or the internal back-and-forth about which option to pick. If you cannot imagine the sentence a draft would write from the item, the item is context for people, not knowledge for content.

The second question gives the item an owner. Google’s guidance on creating helpful, reliable, people-first content asks whether content clearly demonstrates first-hand expertise and a depth of knowledge, and the only way a draft shows that is by drawing on something a person in the business actually knows. An item nobody will put their name to is a rumour with good formatting.

The third question is about dates. Prices, features, staff, deadlines and anything a regulator or a vendor can change go stale, and they go stale silently. The fourth is about permission: a client’s name, a contract term or a figure from an internal report can be true and owned and still not be the company’s to publish. Keeping the source attached is what makes both checks possible later, and the tools now expect it. Anthropic’s documentation on citations in Claude describes answers that return the exact passages supporting each claim, which only helps if those passages are ones you meant a draft to cite.

The nine kinds of material, and what makes each one an entry

The nine kinds of material a business content knowledge base usually draws on are call answers, FAQs, objections, case studies, product documentation, customer language, positions, evidence and style rules, and each has a usable core surrounded by noise. The table shows where the line falls for each kind. The skill is not collecting more of any kind; it is cutting each source down to the part a draft would actually quote.

Calls are the richest source and the noisiest. A long discovery call might hold one explanation worth keeping, usually from the moment the buyer said it finally made sense. Getting the words is easy; Zapier’s guide on how to transcribe Zoom meetings shows a cloud recording’s audio transcript downloading as a file. Choosing the part is the work. Y Combinator’s Startup School recap of Eric Migicovsky’s talk on talking to users tells founders to ask about “specifics that have already occurred” and to take detailed notes, and the same rule picks the keepers: a real buyer’s real question, answered the way the team answers it now.

FAQs and objections look alike and behave differently. An FAQ entry is a question many customers ask and an answer that is stable, which is the shape schema.org gives a FAQPage: a page presenting frequently asked questions. An objection is a doubt that arrives at a particular moment in buying, and the reply matters more than the exact wording of the doubt. Admit both only once they have come up more than once, because a single customer’s question is a note, not an entry.

Case studies and evidence are the two kinds most often admitted too early. A case study is a story: who it was for, what was done, in what order, and what changed. Evidence is narrower, a figure, a quote or a document that backs one specific claim. Both need the client’s permission level before they enter, and evidence also needs a source a person can open. A result someone remembers but nobody measured stays in the sources folder, however good it sounds in a meeting.

Product documentation enters as statements, not as manuals. A long setup guide becomes a handful of facts a draft can state, each with the date it was last true. Customer language is the opposite of documentation, because it is the buyer’s words for the problem and those are rarely the company’s. Nielsen Norman Group’s article on the match between the system and the real world puts the principle plainly: speak the users’ language, and never assume your reading of a word matches theirs. Threads where buyers describe a problem unprompted are a good place to hear it, and our Reddit content guides cover how a business takes part there honestly.

Positions and style rules are the two kinds a business has to write rather than collect. A position is a view the business argues, attached to the person who argues it, and the subjects worth having a view on come from your knowledge pillars. Style rules work best as a list of words and what to do with each, the way Google’s developer documentation style guide keeps a word list of terms to use, avoid or replace. A rule like “say client, never customer” can be checked; a rule like “sound warm” cannot, so it belongs in the approved examples instead. The same rules hold wherever the company speaks in its own name, and our LinkedIn company page guides show them applied to a company page.

What not to put in a knowledge base, and the damage each item does

Six kinds of material should stay out of a content knowledge base: raw transcripts, unapproved drafts, internal debates, confidential client detail, stale facts and aspirational claims. Each is tempting because it is already written down, and each does a specific kind of damage once a model treats it as something the business stands behind.

Raw transcripts bury the useful line. The study titled Lost in the Middle: How Language Models Use Long Contexts found that models used information best when it sat at the beginning or the end of a long input, and noticeably worse when it sat in the middle. A transcript is almost all middle. Keep the recording and the transcript as sources, and admit only the answer you extracted from them.

Unapproved drafts teach the model your mistakes. A draft rejected for sounding wrong will be imitated as faithfully as one that was approved, because nothing in its text says which was which. Internal debates are worse: a thread arguing both sides of a decision hands a model both sides as things the business believes. Admit the decision once it is made, with its owner, and leave the argument where it happened.

Confidential client detail stays out even when a draft could use it. Anthropic’s guidance on reducing prompt leak states the general rule bluntly: if Claude doesn’t need it to perform the task, don’t include it. A content base is read by every workflow that drafts, so anything inside it can surface in any post. Client names, contract terms and anything said under an agreement go in only at a permission level that keeps them out of public drafts, or not at all.

Stale facts and aspirational claims both describe a business that does not exist. A retired feature, an old process or a colleague who has left is true of the past and wrong today. An aspirational claim is true of the future the company hopes for: a service it plans to offer or a result it expects. Admit the fact while it is current and give it a date, and admit the plan once it is real enough to sell.

A knowledge base checklist: what to collect first

Collect style rules, customer language and the answers from recent calls first, because those three improve most drafts and they are the cheapest to gather. Everything else can follow in the order the drafts ask for it. A knowledge base checklist that starts with all nine kinds at once usually stalls at case studies, which need permissions, while the rules and the words that would have improved every draft wait behind them.

Style rules come first because every draft uses them, whatever its subject. A short list of words to use and avoid, a few sentences on how the company sounds and a handful of approved examples will improve the first draft more than any amount of product detail. Customer language comes second, because it changes what the drafts are about as well as how they read.

Call answers come third, because they hold the explanations that already work. A week of recent calls usually covers the questions the market is asking now, which is what content should be about. After those three, add the other kinds in the order the drafts expose gaps: product facts when a draft guesses a feature, evidence when a draft makes a claim it cannot back, positions when the drafts start to sound like everyone else in the sector, and case studies when the permissions arrive.

The minimum base is smaller than most people expect. It needs enough that a draft on the subjects you publish most can be written without guessing, which is a narrower goal and one a small team can reach in a few weeks of ordinary work. How to file what you collect so that it keeps paying off is set out in how to organize your business knowledge so it compounds.

How the drafts show which kind of material is missing

The drafts show which kind of material is missing, because each gap produces its own recognisable mistake. A draft that guesses a product detail is missing a fact. One that sounds like a competitor is missing positions, and one that uses the company’s internal labels is missing customer language. Reading drafts for these mistakes is faster than auditing the base, and it points straight at the next thing to collect.

The other kinds leave marks too. A claim with no number behind it, or with a number nobody can trace, means the evidence is thin. A draft that answers a question nobody asks means the FAQs were written by the company rather than collected from customers. A draft that meets an obvious doubt with silence is missing objections, and one whose tone drifts from post to post is missing style rules or examples. Each mistake has one fix, and the fix is always a kind of material, never a longer prompt.

This is not the full test of a finished base, which is set out in the cold-draft test for a knowledge base. Reading for missing kinds is the everyday version: a minute on each draft that comes back, asking which sentence was guessed and which kind of material would have stopped the guess. Whether the system as a whole is working is a separate question, covered in how to measure whether your content system works.

What a tool can sort for you, and what only the owner can admit

A tool can collect material, split it into candidate entries and flag what looks stale or sensitive, but only the owner can admit an item, because admission is a judgement about what the business stands behind. That is the same line we draw in what to automate in your content, applied one step earlier. The machine does the sorting, and a person signs each entry in.

The automated part is real and it saves hours. A workflow can start whenever a file lands in a shared folder: n8n’s Google Drive Trigger node checks for matching events, such as a newly created file, and runs once for each one it finds. The same tool’s Extract From File node pulls the text out of a PDF, a spreadsheet or a plain text file. From there Claude Code or another model can propose candidates, each tagged with its source and the kind it seems to be.

The judgement stays with people. Whether a reply to an objection is the one the team trusts, whether a client has agreed to be named, whether a position is the founder’s settled view or a passing remark: none of that is in the text, so no model can read it off the page. The owner of each kind confirms the entry, its kind and its permission before it is admitted, and a rejected candidate goes back to the sources folder rather than the bin. A tool that admitted its own candidates would fill the base with plausible material, which is exactly the failure the base exists to prevent.

A payroll software firm’s week of material, sorted in or out

Picture a small payroll software company sorting one ordinary week of material: a few recorded sales calls, a batch of support tickets, a proposal the team lost, a product update and the founder’s notes for a talk. This is an illustration, not a client, and the details are typical rather than measured.

From the calls, two items got in. One was the account manager’s explanation of how the software handles a pay change in the middle of a month, which a buyer had said finally made sense; it went in as a call answer with the account manager as its owner. The other was the question that prompted it, kept in the buyer’s words because other prospects had asked a version of it too. The rest of each transcript, the introductions, the screen-sharing trouble and a long digression about another vendor, stayed out.

The support tickets produced customer language rather than answers. Customers called the year-end process “the January panic” and the payroll calendar “the dates page”, and both phrases went into the base with a note on what the company calls the same thing. The lost proposal produced one objection, that switching provider partway through a tax year felt risky, along with the reply the sales lead now gives. The proposal’s pricing table and the prospect’s name stayed out.

The product update produced two facts, each with a review date because the feature was new, and one line the team rejected: a sentence saying a new report was “coming soon”, which was a plan rather than a fact. The founder’s talk notes held one position worth keeping, that small firms should automate their payroll checks before they automate anything their employees see, and the founder confirmed it as their view. A second note, half an argument about compliance, stayed in the sources folder until it is finished.

The firm did not set time aside to build a knowledge base; it sorted material it already had, most of which stayed in the sources folder, and the base grew by a few entries. Done every week, that is how a base comes to cover what the market asks rather than what the company assumed it would ask. It also stays small: Anthropic’s help article on retrieval augmented generation for Claude projects describes RAG mode switching on only as project knowledge approaches the context window, and a sorted base stays short of that far longer than a folder of raw material does.

What admitting and pruning a knowledge base costs each month

The steady cost of a content knowledge base is attention rather than software: a short weekly sort, a monthly look at what has expired, and each owner’s time to confirm new entries. The first build costs more, mostly the founder’s time on positions and the delivery lead’s time on facts and permissions.

Pruning is the part people skip. Every dated entry will expire, every product change retires a fact, and positions shift as the business learns. Removing an entry is a decision just like admitting one, and it needs the same owner. A base that only ever grows ends up holding two answers to the same question, and a model given both will pick between them by accident.

There is a cost in what you leave out, too. The best client story may be under an agreement, the most persuasive figure may have no source, and the founder’s sharpest opinion may not be settled yet. Those wait until they pass, and the drafts are a little less vivid for it. Being trusted is worth more than being vivid.

A base sorted this way is what we treat as the knowledge layer of a Content OS, read by every workflow rather than rebuilt for each one. If you would rather have it sorted and built for you, a Custom Content OS is the setup that shares one knowledge base across every platform you publish on. And because FAQ answers written for the base tend to become the answers your site gives in search, they carry straight into preparing your content for AI search.

Frequently asked questions

How is a business content knowledge base different from a company wiki?

A wiki records what the company knows for its own people, while a content knowledge base holds only what the company is willing to say in public content, checked and dated. A wiki can hold drafts, debates, internal processes and half-finished thinking, because its readers can ask a colleague. A model drafting a post cannot ask anyone, so every item in a content base has to be safe to draw on as it stands.

Should every support ticket go into the knowledge base?

No. Support tickets are a source, and only the parts that recur become entries: the question in the customer’s words and the answer the team now gives. A ticket about one customer’s account problem is noise for content, and it may contain personal detail that should never reach a draft. Read tickets in batches and admit the patterns, not the tickets.

Can AI-generated summaries of calls go straight into the knowledge base?

Not without a person confirming them. A summary is a candidate, useful for finding the answer that landed, but a model can smooth a hesitant reply into a confident one or attribute a view to the wrong person. The owner checks the summary against the recording and admits the entry in their own words, with the recording kept as its source.

What is the smallest knowledge base worth starting with?

Style rules, a few approved examples, a page of customer language and the answers from a week of recent calls. That is enough to improve drafts on the subjects you publish most, and all of it can be gathered from material the business already has. Product facts, evidence, positions and case studies follow in the order the drafts show they are missing.

Do positions belong in the knowledge base if the founder later changes their mind?

Yes, as long as each position has the founder as its owner and a date to be looked at again. A business is allowed to change its view; what it should not do is publish an old view as if it were current. When the position changes, the old entry is retired rather than edited, so earlier content can still be traced to the view it came from.

Where should FAQs come from if customers rarely email questions?

From calls, demos, proposals and the questions prospects ask before they buy, which most businesses hear far more often than they read. Sales and delivery staff can keep a running list of questions in the customer’s own words. A question several people ask in different conversations is an FAQ; a question the company would like to be asked is marketing, and belongs somewhere else.

Where to start

Pick one week, gather everything the business produced in it, and put each item through the four questions: would a draft use it, does someone vouch for it, is it still true, and may it be published. Admit what passes, keep the rest as sources, and write down which of the nine kinds the week did not touch. That list is next week’s collecting.

Keep reading

• How to build a knowledge base for AI content — what to do with an item once it is admitted: the files, the fields on every entry, and the test that proves the base sounds like the company.
• How business knowledge becomes automated content — the path an admitted answer takes from a sales call to every piece that uses it.
• How to organize your business knowledge so it compounds — giving every piece one home, so the base keeps growing in a shape people can find their way around.