Build an operational knowledge base your team can trust

Who this is for

This is for owner-operated companies whose rules live in chat, call notes, a founder’s memory, and three folders that disagree. New hires ask the same questions. Sellers quote last year’s terms. Reports argue because the definition was never written. If that is already the leak, /operational-knowledge-base is the short doorway. This playbook is how to build the foundation without starting at the chatbot.

It is not a public help center, a SEO blog, or an IT wiki of login screenshots. Those can exist. They are not the operating picture. Do not mix customer-facing FAQ copy with the internal rule for refunds and expect a model to know the difference.

Symptoms

If several of these are true in the same month, this is a live operational leak — not a tooling preference.

• Two people give two answers to “what is included,” and both can point at a document.
• Project history is a hunt across email, a drive, and a chat channel named after the client.
• The CRM, the proposal folder, and the delivery board tell three stories about the same account.
• AI tools were connected to the drive and now confidently cite a deck from two years ago.
• Only one person can onboard a new hire to “how we actually do this.”
• Report definitions live in a cell comment, if they live anywhere.
• Permissions are wide because tightening them would make the hunt worse.

What done looks like

Done is a working operating change, not a purchased seat or a dashboard nobody opens.

• A top-20 inventory exists: question, trusted source, owner, and last reviewed date.
• Conflicting sources are marked deprecated or deleted, not left “just in case.”
• Permissions match who should see customer, money, and personnel material.
• Any chat or search layer must show a citation to the source it used.
• Buy vs build was an explicit choice after the inventory, not a vendor-led one.
• The weekly report and the proposal template pull from the same definitions where they overlap.

Sources and owners before chatbots

Chat is an interface. The product is a source you would let a new hire trust on a Friday. If that source does not exist, the interface will only speed up folklore. Start with the questions the business already pays to answer: pricing floors, who owns an account, how a weekly number is defined, what the last signed scope said, how to request access, what happens when an invoice is late. Twenty is enough. If you cannot name twenty, you are not short on knowledge. You are short on attention to the work.

For each question, write the source you would want cited. A current rate card. A report definition. A signed proposal. A policy page with a date. “Ask Dana” is an honest current state, not a finished source. Leave it on the inventory as a gap. Gaps are the DIY list. A chatbot cannot close a gap. A person writing the page can.

The top-20 inventory

Run the inventory as interviews, not as a drive crawl. Ask sellers, coordinators, and the owner what they searched for last week and what they asked in Slack. The crawl will give you files. The interviews will give you questions. You want questions.

Then look at the files. Mark each as trusted, stale, or personal. Personal notes can stay personal. They should not be in the corpus. Stale files need a tombstone — a note at the top, or a move to an archive the chat layer cannot see. Half of the value is subtraction. A model that can see everything will average everything.

Overlap with other playbooks is a feature. The definition behind the weekly brief belongs in the inventory. So does the current proposal template from call notes to proposals. So do the onboarding asset lists. Knowledge work that ignores those artifacts becomes a fourth place to look.

Honest buy vs build

Buy when you already have a tool the team lives in — a wiki, a docs suite, a help-center product you already pay for — and the job is structure, owners, and permissions. Build when the sources are scattered across systems of record and you need a thin index with links back, not another copy of the truth. Do not build a second CRM in a wiki. Do not buy an “AI knowledge” product to avoid naming owners.

The honest test: if the vendor disappeared, could you still find the twenty sources? If the answer is no, you bought an interface and called it a base. Keep the sources in places you already know how to restore. The layer on top can be replaced.

Rank this against other asks in the operational ranking. Knowledge is often a dependency, not the first customer- facing change. A follow-up draft that cites the wrong rate card is a knowledge failure. A report that invents a definition is a knowledge failure. Sometimes the DIY is writing five pages, not installing a chat widget.

Permissions and citations

Wide-open drives feel convenient and make every later AI feature unsafe. Separate customer files, personnel notes, and money records from the general operating pages. The chat layer should inherit those boundaries. “The model needs access to everything to be useful” is how you leak a client’s contract into the wrong channel.

Citations are non-negotiable. An answer without a link is an opinion. If the source cannot be linked, it is not in the base yet. This is also how you catch stale pages: when two answers cite two files, you have an owner problem, not a model problem.

Document dumps from document workflows should land in the right collection with an owner, or they should stay out. A proposal is a source of truth for that client. It is not a source of truth for pricing in general unless you say so.

A starter top-20, not a universal list

Your twenty will differ. The shape does not. Commercial: current rate card, what is included in a typical kickoff, who can discount, what the last signed exclusions were. Delivery: how we request access, where project history lives, what “done” means for the first milestone, who the client’s day-to-day is supposed to be. Revenue ops: how a qualified opportunity is defined, where the next-step field lives, what lost means. Finance: how we recognize a paid deposit, who chases a late invoice, what is not in the weekly cash number. People: how a new hire finds the working templates.

Write the questions in the language the team already uses. “Where is the latest SOW?” is better than “document management policy.” Then name the source you want cited. If the honest answer is a person, keep the person on the inventory and add a page that captures the rule they keep repeating. The page is the DIY. Interviewing them forever is not a base.

Stop at twenty until those twenty have owners. A two- hundred-file crawl feels like progress and produces a corpus no one will defend. Depth beats coverage. The weekly brief definition and the current proposal template are worth more than a decade of all-hands decks.

Owners need a cadence, not a title

An owner who never reviews the page is a label. Put a date on each source. Quarterly is enough for most operating rules. Rate cards and legal blocks may need faster attention when they change. The job is to open the page, confirm it is still true, and change the date. If that never happens, the chat layer will keep citing a polite lie.

Split ownership by risk. Money and legal pages should not be owned by “whoever edited last.” Customer files stay with the account owner. General how-we-work pages can sit with operations. When two owners would both claim a page, you have two sources. Merge them or split the questions until one name remains.

New files need a front door. A proposal that just got sent is a source for that client. It is not a source for company pricing unless an owner says so. Dumping every PDF into the corpus is how last year’s discount becomes this year’s default.

What not to ingest

Personal inboxes. Working notes that were never meant as policy. Drafts. Expired contracts left in the same folder as live ones. Personnel conversations. Anything you would not let a new hire quote to a customer. Subtraction is part of the build.

Also skip “the whole drive” as a first corpus. Retrieval over a junk pile makes fluent mistakes. Archive first. If a file cannot earn a place on the top-20 or as a linked child of one of those sources, it can wait.

If you already turned on a chat layer, turn the citations on and read them for a week. Wherever the answer points at a stale file, you have found an inventory row. That is useful. It is not a reason to keep the layer pointed at everything while you “see what happens.”

DIY vs hire

DIY the top-20 inventory, the owner list, the archive of stale files, and five pages that close the loudest gaps. That is a working base. Many companies can stop there for a while and get better answers from ordinary search.

Hire for the later index, the permissions model across several systems, or a retrieval layer with logging. That is implementation and it is quoted separately. The $997 assessment can put knowledge in the first two to four DIY items or on the roadmap. It will not stand up the chatbot inside that fee.

Controls before automation

Recommendations that touch customers, money, contracts, private data, or systems of record need human review, limited permissions, a log, and a fallback. Do not automate a broken path because the tool is ready.

• No chat layer until permissions match the human rules.
• Answers must cite a source. No citation, no publish.
• Customer, money, and personnel collections stay separated.
• Stale files are archived out of the corpus, not “left for context.”
• Owners review their sources on a written cadence, even if that cadence is quarterly.
• Do not scrape personal inboxes into the base.

Search is allowed to be enough

After the inventory and the first pages exist, ordinary search in the tool you already pay for may answer most of the twenty questions. That is a successful base. A chat window is optional. If people still ask in Slack, the missing piece is usually an owner or a link, not a model.

Add chat later if the sources are clean, permissions are real, and citations are on. Until then, a confident answer without a link is just a faster way to spread a stale rule.

In the fourteen asks

Knowledge is the answerable layer in the fourteen mid-market AI asks. It supports reporting and documents. It does not replace them. If you want the inventory ranked against the rest of the week, book the assessment.