How to Build a Knowledge Base That Employees and Customers Can Trust

A business knowledge base is trustworthy only when the information is approved, easy to find and corrected when circumstances change. Small service firms often start with shared documents, saved email replies and instructions held in experienced employees' memories. As the company grows, people may search three folders before finding a policy, send an obsolete attachment to a customer or answer the same question differently. Buying software does not automatically resolve those issues. First establish who owns each important answer, which version is current, who may read it and how a correction reaches the people who rely on it.

A knowledge base can serve employees, customers or both, but the audiences are not interchangeable. Public guidance may explain how to request an appointment or what information a customer should provide. Internal material may contain escalation procedures, staff contacts, negotiated rates or sensitive operational details. This guide examines how to design both kinds of knowledge, how to evaluate publishing tools including Notion and Confluence, and why access and source control matter more than the size of the article library. Product references describe documented capabilities rather than a measured claim that one platform is more accurate or productive.

Start with the questions that interrupt real work

Collect recurring questions from customer enquiries, new staff and internal handovers. A property-related service business might hear questions about viewing requests, required documents, reporting repairs, service boundaries or the approval of a changed appointment. Group these by what the reader needs to achieve. Internal departments and document authors are not useful navigation categories for people who do not know the organisation. A page titled How to change a confirmed appointment is more immediately helpful than a reference number that only its creator understands.

For each question, identify the authoritative answer and the person entitled to approve it. Some questions reveal that no consistent policy exists. In those cases, drafting a confident article would disguise a management problem. Escalate the question and resolve the policy first. Record the effective date where the answer changes over time, especially for prices, terms, eligibility and customer commitments. A historic answer can remain important to an old transaction without being valid guidance for new work.

Begin with a manageable collection rather than trying to document every possible exception. A concise set of maintained pages can be more dependable than hundreds of forgotten drafts. Test whether employees can use the information without contacting its author. Measure repeated enquiries, time spent searching and cases where wrong information required correction. These observations provide a baseline for evaluating the library without inventing numerical productivity improvements.

Define editorial ownership and approval

An article about invoicing may require review by the finance owner, while a maintenance procedure belongs with operations and a sensitive customer policy may need legal or data-protection input. The platform should make that responsibility apparent. Staff can suggest edits, but publishing a change that affects customer commitments should use an approved review route. Distinguish draft, under review, published and retired content. A shared folder where anyone can edit a final instruction without visibility is not an adequate approval process for consequential material.

Assign an owner and review trigger to each important category. A fixed review date may work for stable procedures; an update to a supplier contract or regulation may need immediate reassessment. Where a document changes, preserve history as appropriate but prevent old guidance from appearing indistinguishable from current policy. Include a version identifier or effective date where it helps readers recognise the right instruction. Do not let multiple versions accumulate in parallel public pages simply because nobody wants to delete a file.

Approval need not become bureaucratic. A small team can use a lightweight workflow with one named reviewer and a clear record of what changed. Complexity is justified only when the consequences of errors warrant it. The essential outcome is that everyone knows where the authorised answer comes from and whom to contact when it appears incorrect.

Organise pages around reader needs and source evidence

Readers benefit from short descriptive titles, clear headings, prerequisites, numbered instructions when appropriate and a visible next action. Avoid burying a simple answer beneath promotional language or technical jargon. An internal guide should identify which staff role performs a task, how a successful result is verified and where exceptions go. A public guide should explain what customers can do without promising that every request is automatically accepted. For a booking, request received and appointment confirmed may be separate states.

Search also depends on terminology. Different customers may ask to rearrange, move or change an appointment. Include natural alternative wording while keeping one authoritative page rather than publishing several almost identical articles. Link related procedures in a way that preserves context. Review broken links whenever the organisation retires a form or changes a service. If a user cannot find the answer, allow them to report the search term and information gap without requiring them to understand the knowledge system's internal structure.

Keep the factual source visible where a claim depends on a policy, regulation, vendor feature or contract. A generated summary of a document is not a replacement for the source itself. Employees should be able to inspect the governing record before making a consequential statement. This is especially important where an answer applies only to certain jurisdictions, dates, contracts or customers.

Separate public publishing from restricted workspace information

Sharing settings deserve an actual test, not just a configuration screenshot. Notion's official documentation explains public website publishing of pages, including sharing choices that can expose linked material. Atlassian documents Confluence space permissions and their role in controlling access. The tools serve overlapping but differently configured needs, and neither company's documentation proves that any particular tenant has been set up safely. Test an intended public article in an unauthenticated browser and confirm that only approved content and attachments are accessible.

Maintain clear boundaries between customer-facing instructions and internal guidance. A contractor may need one approved procedure but not the entire operations library. Grant narrow access and review it when a project ends. A public FAQ should never contain individual customer records merely because an employee found a convenient example. Inherited permissions and linked attachments can create accidental disclosure even when the main page looks harmless. Test access using ordinary staff and external visitor roles, not only a workspace administrator.

For teams with many interrelated pages, a structured permission model may justify additional administration. For a simple public help page collection, a carefully configured publishing service may suffice. The correct choice depends on content lifecycle, confidentiality, staff skills and the actual plan. A feature list alone cannot establish that a particular knowledge system is suitable.

Design content for accessibility and changing interfaces

A knowledge article should remain understandable on a small phone screen and with assistive technology. Use logical headings, descriptive links, concise paragraphs and text alternatives for useful illustrations. Tables should have meaningful column headers and remain accessible when the screen is narrow. Avoid instructions based solely on button colour or an unexplained screenshot. A person new to the process should be able to understand what information is required and how to confirm that a task succeeded.

Screenshots can help when a procedure involves a complex interface, but they become obsolete when the application changes. Use them only where they genuinely clarify a step, provide accurate alt text and assign responsibility for updates. A current written explanation of the purpose and expected outcome often survives an interface revision better than a sequence of images with no context. Check links and examples after major product changes.

A customer unable to complete an online process should have an appropriate alternative route. A knowledge base is part of service delivery, not a barrier that allows the business to stop answering questions. The same principle applies internally: an employee who finds conflicting articles should know how to raise the issue and receive a verified answer rather than being blamed for using the wrong document.

Use AI search only with approved sources and permissions

AI-assisted retrieval can help staff ask natural-language questions across a large library. But a fluent answer can combine conflicting versions, omit a qualification or present a tentative draft as approved policy. Before enabling such features, resolve duplicated source material and access rules. Check whether the model provides a link to the relevant document and whether employees can distinguish source text from generated interpretation. If the approved evidence does not support a claim, the assistant should acknowledge uncertainty and refer the question to a responsible person.

The ICO guidance on AI and data protection is relevant where source documents, queries and generated responses contain personal information. Permissions must carry through to the retrieval experience. A customer-facing assistant should not answer from confidential internal records simply because the material is indexed. Test requests phrased indirectly to check that protected content remains inaccessible. Review how prompts and conversation logs are processed and retained under the supplier's actual terms.

Begin with low-consequence, well-supported questions. Test an outdated article, a missing answer and a document the user is not entitled to see. Review the complete results with staff who understand the subject. If the model repeatedly fails, repair the knowledge sources or narrow the task rather than adding longer instructions that disguise inconsistent information.

Test Notion and Confluence against the same publishing journey

Start by drafting one internal procedure and one public customer answer. Ask a normal contributor to propose a correction, obtain approval and publish the intended version. Then test retrieval from a staff account and from a visitor without an account. Check what happens when an article is archived and whether the old public link still exposes outdated guidance. Export pages, attachments and any meaningful metadata. These tests expose more than a feature comparison chart can show.

Assess the licence and administrative configuration actually available. A product feature may depend on a plan or permissions, so a demonstration in a fully licensed environment does not guarantee it exists for the proposed account. Record the maintenance effort: who manages guests, reviews pages, approves changes and troubleshoots access? A simpler tool with consistent editorial discipline may offer better value than a complex platform nobody maintains. Conversely, a team with substantial restricted operational documentation may need structured access and review controls.

Consider portability. Exported text may not retain every attachment, permission or relationship. Test a representative migration before the organisation becomes dependent on the product. Keep significant business rules documented independently so a future platform change does not erase how the work is supposed to happen.

Measure whether the library genuinely improves service

Page views can show usage but not whether the reader reached the right result. Monitor failed searches, repeated customer questions, staff corrections and occasions when an obsolete instruction caused work to be repeated. Compare results over time with consistent definitions. A change in navigation or the number of published pages can alter usage numbers without changing service quality. Review a sample of resolved cases and ask whether the knowledge article helped staff or customers complete the intended task.

Set realistic review cycles and address the causes of recurring errors. When a customer cannot understand a booking instruction, the answer may require both a clearer article and a change to the booking form. When employees ask the same policy question, a hidden or contradictory approval process may be responsible. The knowledge base should help reveal these problems rather than becoming a collection of responses designed to make them seem solved.

A dependable knowledge system is never finished in one writing session. It is maintained through clear source ownership, audience permissions, accessible publishing and timely corrections. Choose the tool that supports those responsibilities within the team's capacity. The purpose is to help people trust the answer and know where to go when it does not fit their situation.

Original sources: Notion, public pages and web publishing; Atlassian, Confluence space permissions; ICO, AI and data protection guidance. Vendor references are product descriptions, not a controlled accuracy benchmark.