Create a Company Wiki Your Team and AIs Can Use

To create a company wiki, choose a shared home, organize it around recurring work questions, and publish a small set of pages with named owners and review dates. Test whether a teammate can find and use an answer before importing a large document collection.

The wiki holds reference material; a tool such as fenbs can hold the related project decisions, rules, and next steps that connected AI assistants need. Decide which record is authoritative for each kind of information so readers do not have to choose between competing answers.

What are the first steps to a useful company wiki?

1. Collect recurring questions from recent work. Ask new colleagues what blocked them, and ask experienced colleagues which explanations they keep repeating.
2. Choose a home your team can access and maintain. Check permissions, editing, search, change history, and the way you will preserve or export important material.
3. Create a small navigation structure based on the work people need to do. Use clear labels such as Starting here, Delivering a project, and Getting help.
4. Write the first answers with the people responsible for them. Include the answer, scope, source, owner, and last verification date on each page.
5. Ask a colleague to complete a real task using the wiki. Correct what they misunderstand, then add the wiki link to the team’s normal starting points.

For example, a small consulting firm might begin with requesting software access, preparing a proposal, and handing a project to delivery. These are hypothetical starter topics, not a universal company handbook. Choose the questions that interrupt your team now.

How should you structure the pages?

Make navigation reflect the reader’s goal. A page titled “Submit an expense” is easier to recognize than a folder titled “Miscellaneous operations.” Group related answers without forcing people to understand the company chart before they can ask for help.

Give each answer one main location and link to it from other sections. GitLab’s handbook guidance↗ (opens in a new tab) organizes material with an owner and recommends cross-links instead of repeated content. That principle is useful even if your wiki is much smaller than its handbook.

Keep the initial structure shallow. If people repeatedly search for a term different from your page title, use their wording in the title or opening sentence. A navigation system should help readers reach an answer, not display every possible category.

What should every page include?

Start with the direct answer or the first action. Then explain when it applies, what the reader needs, the steps, and how to check completion. Put exceptions and the contact for unresolved questions near the instructions they qualify.

• Purpose: the question this page answers and the audience it serves.
• Scope: when the instruction applies and any cases that need a different procedure.
• Current answer: the approved guidance, with practical steps and a short example when helpful.
• Evidence: links to the underlying policy, source document, or relevant decision.
• Maintenance: the owner, last verified date, review trigger, and route for proposing a correction.

For a proposal page, include a link to the approved template, the required reviewer, and the place to save the final version. Avoid copying the entire template onto the page if it already has a maintained home. Your wiki should guide the work without creating a second version of every asset.

How do you choose access and editing rights?

Check reading and editing separately. A colleague may need to read an instruction without being allowed to change the policy behind it. Make it easy to suggest a correction, and identify who approves a substantive change.

Verify the behavior in the product you select. For example, GitHub’s wiki documentation↗ (opens in a new tab) explains that a private repository’s wiki follows repository access and that public repository wikis are public. Do not assume a familiar-looking page is private merely because it contains internal material.

Keep secrets and private personnel or customer records in systems intended for them. A general access page can explain how to request an account without including credentials. When someone leaves or changes roles, include the wiki and any assistant connections in the access review.

How can AI assistants use the wiki responsibly?

Choose how the assistant will receive the relevant source: an approved connection, a page you intentionally provide, or a checked summary. A wiki does not automatically become visible to every AI app. Ask the assistant to identify the source and distinguish an approved instruction from an example or suggestion.

Keep long reference pages in the wiki and put the work-changing facts in the current project record. The shared AI brain guide explains that distinction, while AI memory for teams covers keeping the common context current between sessions.

If an instruction becomes a reusable assistant procedure, the guide to creating a Claude skill covers that separate step. A skill still needs an owner and a source; converting prose into instructions does not make stale guidance correct. In fenbs, Decisions and rules keep people’s approved instructions in the context connected assistants read.

How to support the company wiki with fenbs?

1. Create a free account and add one project whose instructions already appear in your wiki.
2. Save the relevant source references in the project context. Record only the approved rules that affect the work in Decisions and rules, with the person who decided them.
3. Add tasks for missing answers or corrections. Keep the proposed change and the check that will confirm it in each task’s plan.
4. Use the appropriate integration guide to connect an assistant. Ask it to read context before starting and save the current progress before stopping.

fenbs is useful for shared work context across assistants. It is not a full company wiki editor and does not automatically import your wiki. If publishing and organizing reference pages is the main requirement, start with the company wiki software guide.

How do you keep the wiki useful after launch?

Make correction part of using a page. When a colleague spots an obsolete step, have them flag the exact problem or suggest an edit. The owner checks the source and approval, updates the answer, and points any superseded page to the replacement.

Schedule a modest review of high-use pages and check instructions when their underlying tools or policies change. Try the original task again after a correction. You can explore more habits for maintaining shared guidance in the team brain library.