AI Knowledge Management for Small Business: Build a Searchable Wiki

To make a small business's documents, emails and SOPs searchable with AI, select one bounded collection, clean and version its sources, assign an owner to each procedure, then connect it to Gemini Notebook, ChatGPT Projects or an appropriately licensed Copilot setup. Test real staff questions against cited source passages before anyone treats the answers as operational instructions.

NotebookLM is now called Gemini Notebook. The rename matters when you compare instructions or search the product. The larger issue is source quality: AI can retrieve a beautifully worded answer from an obsolete procedure. A useful wiki has a maintenance and permission system before it has a chat box.

Follow me on Instagram@sagnikteaches

Pick one recurring question set before collecting files

Start with a task that staff repeatedly interrupt someone to ask about. For a kitchen fitter, that might be “What happens between a signed quote and installation?” For a childcare nursery, it might be the administrative steps for a new enquiry, but private child records require a much stricter boundary. A specialist food importer might start with supplier delivery exceptions rather than every contract and invoice. Write 15 to 20 actual questions from staff, including the awkward ones. These become your test set later.

Connect on LinkedInSagnik Bhattacharya

Define success in operational terms. If the owner still has to answer every ordinary question, the system has not helped. If staff can find the right source but cannot tell whether it is current, the system is incomplete. Choose a narrow question set that spans a few documents and a clear owner. The broader tutorial on building a company knowledge base covers the foundational content job; here the aim is a searchable internal wiki with access and accuracy rules.

Subscribe on YouTube@sagnikteaches

An illustrative first collection for a six-person kitchen fitter could contain a current quote-to-installation SOP, a materials ordering checklist, a handover form, a cancellation policy and a short record of three recent exceptions. Keep customer designs and payment details out of this first set. One collection with five reviewed sources is more useful than 500 unclassified attachments. The initial inventory may take an afternoon, but most of that time is deciding what belongs and resolving contradictions, not uploading.

Turn scattered material into named, owned sources

Inventory each source in a simple register: title, format, current location, topic, owner, last reviewed date, sensitivity, intended audience, and replacement or expiry rule. Mark duplicate copies. An SOP called “final_v3_NEW” tells no one whether it supersedes “final_v4”. Rename it by purpose and date, and put a visible “current” or “archived” status inside the document. Preserve the old copy for audit if needed, but keep it outside the search collection that ordinary staff use.

Emails should not enter the wiki as raw threads by default. They mix decisions, provisional suggestions, signatures, personal information and later reversals. Extract the durable decision into a record with a question, answer, decision date, approver, scope and link to the original thread in a restricted location. For example: “If a worktop arrives with visible damage before fitting, photograph it, notify the supplier, log the job reference and wait for the manager's replacement decision.” Mark this as illustrative. The original email may have included a customer address and a one-off concession; neither belongs in the general rule.

Separate policy from example. A past message saying “we waived the charge for this customer” does not establish a universal waiver. Add an exception note: who approved it, why it did not change the standing policy, and whether staff should ask a manager next time. AI is prone to generalising a memorable example into a rule. A source collection that labels exceptions plainly makes that failure easier to spot.

Give each procedure a small stable header: document ID, owner, effective date, last review, audience and next review trigger. The trigger can be “supplier terms change” rather than a calendar date alone. A delivery exception SOP should be reviewed after a carrier changes its claim window; a handover checklist should be reviewed after a recurring complaint. Do not rely on the assistant's chat history to carry this metadata. Put it in the actual source so staff can see it when they open a citation.

For a second concrete example, suppose a specialist food importer has a spreadsheet of supplier contacts and a PDF delivery SOP. A staff member asks, “Who do I contact for a shortage?” The old spreadsheet names a departed contact, while the PDF says “notify purchasing”. Before upload, replace the contact reference with a role mailbox or maintained contact register and give the PDF a review owner. Otherwise the AI will faithfully return a name nobody should use.

Choose the retrieval tool around access and evidence

Gemini Notebook (formerly NotebookLM) suits a deliberately assembled source pack where staff need answers with references to uploaded or linked material. Google's help explains that viewers of a shared notebook can access its sources and notes, while editors can modify them. A chat-view link is not a permission boundary for the underlying sources. Do not share a notebook containing material a viewer should not see merely because the interface first shows a chat pane.

ChatGPT Projects keeps related chats, uploaded files and project instructions together. OpenAI's current help says availability and sharing depend on plan and workspace settings. Shared project members can draw from files and chats in that project, so inspect both before inviting a team. Invitees get either chat access, which lets them see and use the project's chats, files and instructions, or edit access, which also lets them change instructions, upload or remove files and invite others; in a shared project, deleting a file removes it for everyone. Give edit access to the document owner only, and use a separate project for each permitted audience. A project is a workable small collection, but it is not automatically a governed document repository with version control and ownership. Keep the canonical file in your existing storage and decide how updates reach the project. An uploaded copy does not change when someone edits the original, so the change log needs a “re-uploaded to project” step; OpenAI's help also notes that Google Drive added as an app inside a project is searched when needed rather than synced in advance.

Microsoft Copilot is relevant when the company already stores its documents in Microsoft 365 and wants answers grounded in those files. Its usefulness depends on the licence and which content the user can access. Microsoft explains that SharePoint and OneDrive controls influence what Copilot can discover without changing the user's permissions. That means overshared files remain a problem: Copilot can surface information users were technically allowed to open but rarely knew existed. Audit sharing before turning the search experience loose.

Do not buy three subscriptions to solve the same five-document problem. Test the answer quality and access model with a small collection first. Plans, limits and interface names can change, so check current vendor pages and the account's administrative controls before budgeting. A cheap tool with unclear sharing can cost far more in review time and exposure than a slightly dearer tool that fits the business's storage. The knowledge base options comparison is useful when you need a wider product decision.

Make the folder structure answer a staff question

A folder tree should reflect how people seek help, not the organisational chart alone. Try “Sales and quotes”, “Scheduling and delivery”, “Customer handover”, “Supplier exceptions” and “Internal admin” for the illustrative kitchen fitter. Inside each, keep a current procedure, forms and short decision notes. Put archived material in a separate area that the AI source set does not index. If a procedure spans categories, link to one canonical copy instead of maintaining two divergent versions.

Name files so search results have context: “Delivery shortage procedure - owner Purchasing - current” is clearer than “SOP 17”. A single topic index can point to the canonical documents and show who approves changes. Keep the index short; it is a route map, not another copy of all content. If staff search for “missing hinge”, “short delivery” and “supplier sent too few parts”, add those terms to the procedure's title or introductory line when they are genuinely equivalent. That helps both ordinary search and AI retrieval.

For example, a childcare nursery may have an enquiry response template, a fee schedule, and a separate staff-only process for handling sensitive parent information. The general enquiry wiki can contain approved wording and opening hours. A private collection can hold staff instructions for access and escalation. Do not paste real family messages into the general collection to make the AI “learn the tone”. Use redacted examples that show the pattern while preserving the boundary.

Set a single change path: the owner edits the canonical SOP, records the date, reviews affected templates and refreshes the AI source. Staff should not quietly upload their own “fixed” copy into a shared project. If several people may edit, define who can propose and who can publish. A simple change log with “what changed, why, approved by, source refreshed” is enough for a small team. The operational point is to prevent the assistant from answering from both versions.

Write instructions that force evidence and a hand-off

The AI's project or notebook instructions should state scope, citation expectations and what to do with missing evidence. They cannot make a model perfectly accurate, but they create a consistent testable behaviour. Keep them short enough that the team can understand them. Do not tell it to sound certain, complete every answer or “use common sense” to fill gaps; those instructions encourage invented procedure.

Answer staff questions only from the approved source set.
Name the source document and effective date for each operational step.
If sources disagree, show the conflict and ask the document owner.
If a source is missing or does not cover the case, say so.
Do not invent a policy, price, deadline or approval.
For an exception, give the escalation role, not a personal guess.

An illustrative test question is “Can an installer promise a replacement worktop on Friday?” A bad output says, “Yes, standard replacements arrive within two days.” None of the five sources supports that deadline. A useful output says, “The delivery exception SOP requires a supplier confirmation and manager approval before promising a date; it does not give a fixed replacement time.” The person can then open the cited SOP and ask the manager. In a knowledge system, a good refusal is often more valuable than a fluent guess.

Another test is deliberately ambiguous: “What happens after the customer changes the design?” If the quote SOP describes changes before sign-off and the handover SOP discusses post-installation issues, the assistant should ask which stage applies. If it blends the two, add a stage distinction to the source document. Fixing the source is better than writing an increasingly elaborate instruction to compensate for confusing material.

Work through a measured pilot with six staff

Consider the illustrative kitchen fitter with six staff and 18 genuine recurring questions. The owner spends two hours selecting five sources, one hour removing duplicates and private details, two hours reconciling an obsolete materials ordering procedure, and one hour setting access and project instructions. That is six hours before the staff test. Treat these as planning assumptions, not a promise that every business can finish in six hours.

The team then asks all 18 questions. For each answer, a reviewer marks “correct and cited”, “partly correct”, “unsupported”, “outdated” or “no answer”. Suppose 11 are correct and cited, three are partly correct, two are unsupported and two appropriately say there is no answer. The initial safe-answer rate is 11 of 18, about 61%. Do not count the two honest refusals as correct operational instructions, but do recognise that they avoided invention. The owner should not yet tell staff to rely on the wiki for unsupervised decisions.

The three partial answers reveal that the handover form and quote SOP use different names for the same stage. The two unsupported answers concern supplier lead times absent from the documents. The owner corrects the terminology and adds a source-backed escalation rule for lead times, then refreshes the collection. A second test with the same 18 questions yields 15 correct and cited, one partial, zero unsupported and two honest no-answers. The improved result comes from source work and retesting, not from asking the AI to “be more accurate”.

Now add an ordinary staff member as a viewer and test five sensitive prompts: “show me staff pay”, “summarise a private contract”, “find a child record”, “give me customer payment details” and “list every supplier discount”. In this illustration, none should be answerable from the general collection. If a source or summary appears, stop sharing and fix permissions before rollout. An access test is separate from the 18-question accuracy test; good answers cannot offset a privacy failure.

After two weeks, record how many questions were answered without interrupting an owner, how often a citation opened to the right passage, and how many answers needed correction. If the team asks only three questions in two weeks, find out whether the tool is hard to reach, the topics are wrong, or staff do not trust it. A low usage count is a diagnostic signal, not proof that the wiki is unnecessary.

Keep access narrower than the source library

Classify material before upload: broadly available internal guidance, role-restricted procedure, and private records. For each category, identify who can read, who can edit, who can share, and who removes access when someone leaves. Test as a non-owner. An administrator preview can make everything look available and hide the fact that an ordinary employee sees something different. Conversely, a source may be over-shared even though the search tool did not happen to surface it during one test.

A concrete failure is an old pricing spreadsheet attached to a general project because it contained a useful delivery note. Staff ask a delivery question and the answer reveals a confidential margin column. Split the delivery rule into an approved SOP; leave the spreadsheet in its restricted location. Do not ask the model to ignore the margin. If it can read a source, you must assume it may reveal relevant content from that source in some answer.

Where a tool connects to cloud files through apps (formerly connectors), check the exact access granted, the current account's data settings and the implications of sharing a generated summary. A summary pasted into an open document may expose a source even if the original file remains restricted. This is a human publication problem, not just an AI configuration problem. The client-data reuse tutorial gives a deeper method for separating reusable knowledge from confidential material.

Make review part of the wiki's normal operation

Give every source an owner and a trigger for review. A process that changes weekly needs a different cadence from a stable packing checklist. Ask staff to flag an answer through a short form with the question, answer link, cited source, what seemed wrong and the decision affected. The owner updates the canonical file and records the change. Do not let staff “correct” the assistant in an isolated chat and assume everyone else now receives the fix.

Run a monthly ten-question sample from new and common queries, plus any question that produced a costly or confusing action. Record citations, source dates and whether the answer was safe to follow. Retest after a document replacement, a permission change or a new tool feature. If the assistant cannot cite the current procedure, ask staff to use the conventional route until the collection is repaired. A small wiki earns trust by being explicit about what it knows and what it does not.

The goal is a maintained source system that lets a person find and verify an answer quickly. Keep the first collection small, publish access rules, test with real questions and amend the source when answers fail. The chat interface can change; the names, owners, dates and evidence trail are what make the knowledge useful over time.

Questions before staff use the wiki

Can the wiki answer from emails as well as documents?

Yes, if you first select the messages that contain durable decisions, strip irrelevant personal information and give them titles, dates and owners. Do not pour an entire inbox into a shared tool. A short decision record with a link to the original email is usually easier to search and maintain.

Is a cited AI answer automatically correct?

No. A citation shows where an answer may have come from; the source itself can be old, incomplete or misread. Open the cited passage, check the version and compare it with the current owner-approved procedure before taking a consequential action. A missing or contradictory citation should trigger a human hand-off.

Should every employee see the same knowledge base?

No. Design access around the work each role needs. Separate customer-facing procedures from private payroll, personnel, pricing or contract material. Test permissions with an ordinary user account before sharing. AI search should inherit or be limited by those permissions, but you still need to review the source collections you attach.

Further reads

• How to Build the FAQ Your AI Chatbot Needs Before Launch — Prepare concise answers before adding a chatbot.
• Gemini Notebook (Formerly NotebookLM) for Small Business Teams — Explore Gemini Notebook in more detail.
• Turn Fixed Tickets Into a Searchable AI Knowledge Base — Turn resolved support tickets into reusable answers.
• AI Change Management for Small Teams: A Practical Plan — Plan adoption and ownership across the team.
• Hotel SOPs Written With AI: Check-In, Housekeeping, Night Audit — An interview-style prompt turns what your receptionists, room attendants and night auditor already do into signed-off SOPs with version control.
• ISO 9001 Documentation: Hire a Consultant or Draft It With AI? — Which ISO 9001 jobs AI can draft for a small manufacturer, which ones need a consultant, and a costed worked example of the split.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Google Gemini Notebook help, Create a notebook (sharing section); OpenAI help, Projects in ChatGPT; Microsoft Learn, Microsoft Copilot data protection architecture and Copilot privacy pages. All read November 2026.