Process Docs vs Knowledge Base: What Goes Where

Ask three questions about any page:

1. Is it used mid-task? If a person has it open while doing the work and ticks through it, it's a process document. If they read it once to understand something, it's reference.
2. Does it have a start and an end? A process has a trigger and a finish line. A knowledge base article answers a question and stops.
3. Would a mistake here cause damage immediately? Steps in a refund, a payroll run or a customer onboarding deserve version control and a named owner. A description of company history doesn't.

Take refunds as an example. The step-by-step for issuing a refund in your payment system is a process. The policy explaining when refunds are allowed, and why, is reference. The process links to the policy; the policy doesn't repeat the steps. Keeping them apart means changing a policy doesn't force you to rewrite every procedure that mentions it.

Three layers cover most small and mid-sized companies:

• Policies and principles: short pages stating rules and the reasons behind them (expense policy, security expectations, how decisions are made). Owned by a leader, reviewed once a year.
• Processes: numbered procedures with a trigger, steps, decision rules and a definition of done. Each has one owner and a review date, and is organized by function (finance, delivery, people).
• Reference: searchable answers, glossaries, org charts, customer notes, tool guides. Owned by whoever knows the topic and reviewed when it's reported wrong.

Organize by how people look for things, not by how your org chart is drawn. A new hire looking for "how do I get reimbursed" shouldn't need to know that finance sits under operations. For a concrete way to lay out folders, see the company wiki structure guide.

Because new people rely on documents in different ways. A newcomer running a task for the first time needs a procedure they can follow exactly. A tenured colleague needs the reference to check a detail. When both are mixed, the newcomer wades through background they didn't need, and the veteran can't find the one answer.

Turnover makes this a real cost. The Bureau of Labor Statistics reports median tenure with a current employer of 46.8 months for all wage and salary workers in 2024¹, which means a typical role changes hands several times over a company's life. Every handoff tests whether the process is written down or held in someone's head.

The practical result: put anything that must be done the same way each time into a process document with an owner, and let everything else live as reference that can be a little messier.

Choose based on the job, not the brand. A knowledge base tool is built for writing, linking and searching pages, and it's the right home for policies and reference. Process documentation often benefits from features a wiki lacks: assigning steps, acknowledging that someone read a procedure, tracking training and reminding owners to review.

A workable split for many small teams is to keep reference and policies in a general wiki such as Notion, and keep the procedures that need training and sign-off in a playbook tool such as Trainual. Smaller teams can start with one tool and use templates and naming conventions to keep the layers separate. For help choosing, Notion vs Slite vs Confluence and Process Street vs SweetProcess vs Trainual compare the options.

Whatever you use, link across layers instead of copying text. Copies drift, and the drifted copy is the one somebody follows.

Don't rewrite everything. Run a sorting pass instead:

1. Export or list every page with its last-edited date and author.
2. Tag each page as policy, process, reference or archive. Archive anything untouched for two years unless someone objects.
3. For each process page, confirm the steps with the person who does the work, then add an owner and a review date.
4. Merge duplicates and replace copied text with links.
5. Add a three-click rule: any common question should be answerable within three clicks from the wiki's home page. If it isn't, fix the navigation, not the page.

Plan for a couple of weeks of part-time effort, and announce the new structure so people stop creating pages in the old way. Also review how an internal search tool or assistant would read your pages; clear titles and single-purpose pages help both people and software. The internal knowledge base agentification guide covers that angle.