Internal vs external knowledge base

An internal knowledge base and an external knowledge base can describe the same customer problem while serving different readers. The customer wants a safe answer and a next step. The agent may need verification rules, system actions, approval limits and a record of who owns an exception. Treating those as one unrestricted article risks exposing sensitive procedures; maintaining two unrelated answers risks contradiction.

The better model is a shared policy source with audience-specific articles. A named owner approves the underlying rule. The public page explains the reader's options and limits. The staff page explains how to apply the rule and escalate exceptional cases. The tools can be the same or separate, provided permission and maintenance are reliable.

What the customer needs to see

Public help should answer questions a customer can act on without privileged data: how to reset access through the approved flow, where to find an invoice, how a return is requested or how to troubleshoot a common error. It should say who qualifies, what the usual outcome is and when a person must help. Keep the contact route visible. Do not make the reader guess whether a policy is binding or merely a general explanation.

An external article may refer to a signed-in action, but the article itself can remain public. “View your ticket status in the portal after signing in” is useful to a visitor who has not yet logged in. The status, transcript and personal account data belong behind authentication. This is the difference between a knowledge base and a customer portal.

Avoid publishing agent-only details such as fraud signals, refund authorisation thresholds, internal escalation phone numbers, account recovery bypasses or screenshots containing real customer data. Even if an article is not indexed by search engines, an accessible URL is not an access control. Private material needs actual permissions and a review of who can grant them.

What staff need beyond the public answer

An internal runbook should start from the contact reason and define the authorised process. It may include approved identity checks, which system holds the record, steps agents can take, approvals needed for exceptions, a customer response pattern, ticket fields and escalation. It should clearly mark actions a front-line agent must not take. A good runbook reduces variation without encouraging staff to treat every case as identical.

Staff also need to know what to share externally. Link the customer-safe article near the top, with a note on which sections are approved for quotation. If the public article is wrong, agents should be able to flag it immediately rather than creating a private workaround macro that becomes the de facto truth. Our template collection includes separate public and internal patterns.

Do not store passwords, API keys or raw personal data in a runbook just because it is “internal”. Access can be broad, copies can be exported and staff roles can change. Link to the authorised secure system instead. Internal visibility is a necessary boundary, not a licence to ignore data minimisation.

Choose an access model deliberately

Possible audiences include anonymous visitors, signed-in customers, a named organisation's contacts, all agents and specialist agent groups. The platform must enforce the chosen boundary at article, folder or segment level. Freshdesk describes folder visibility options for all users, agents and logged-in users. Zendesk's user segments can control viewing and management of help-centre content. These are product capabilities, not evidence that your own configuration is safe.

Set permissions using roles rather than individual exceptions wherever possible. Preview a page while signed in as an admin, then test in a private browser and with a representative customer account. Search results, links in ticket replies, attached images and translated versions should respect the same boundary. Re-test after moving a folder or importing content; a changed parent category can alter visibility in some systems.

Record who may publish, edit and approve. In a tiny organisation, one person may be both writer and publisher, but sensitive material benefits from a second check. A wide-open drafting permission can be as risky as public read access if an unreviewed change goes live immediately.

Keep the two versions consistent

Give the shared rule one owner and one authoritative reference: approved policy, product specification, contract or operating decision. The public and internal pages can then cite that source and each other where appropriate. When the rule changes, make the update a small release: revise both drafts, test the public wording, publish in the right order and tell agents what changed.

Use a change-trigger list. A new product plan, revised return window, changed security flow or new legal requirement should prompt review. “Last checked” labels are not a substitute for a real check. For high-risk topics, capture who approved the change and the substantive review month. The outdated-content audit makes this repeatable.

Conflicting pages are especially damaging when a customer quotes the public answer to an agent who follows a different internal rule. When that happens, correct the source and both versions rather than instructing agents to explain away the discrepancy. Track these conflicts as content incidents, not just individual support mistakes.

When one or two tools make sense

One help-desk platform can simplify article suggestions, permissions and feedback from tickets. Freshdesk, Zoho Desk and Zendesk provide routes to customer-facing and staff-oriented knowledge; HubSpot can connect public self-service with CRM records at a higher plan level. Compare the edition that provides the required access and governance, not only the cheapest ticketing entry. Our software comparison lays out these plan boundaries.

Separate tools may be sensible when developer documentation, regulated internal procedures or public marketing content have different owners and release cycles. If so, define how a policy change reaches every copy. The central question is not whether everything lives in one database; it is whether each audience sees an accurate, current answer and whether a team can prove the boundary works.

Sources

• Freshdesk knowledge-base folder and article visibility
• Zendesk help-centre user segments
• HubSpot Service Hub pricing and knowledge-base plan

Product access features should be verified on the selected edition and configuration. Audience and governance recommendations are editorial guidance.