What is the difference between an internal knowledge base and a help center?
The difference is the audience, and almost nothing else. A help center is the set of articles customers can read. An internal knowledge base is the set employees can read. The questions they answer overlap heavily, because most of what an agent looks up is the real answer to something a customer asked.
That overlap is the whole argument. A refund window is the same refund window whether a customer reads it or an agent quotes it. When the two live in separate products, you write that answer twice, and from the moment you do, the two copies begin to disagree.
Both are knowledge bases in the ordinary sense of the word. If the term itself is what brought you here, the three things people mean by knowledge base covers the vocabulary before the buying decision.
Why teams end up running two
Teams end up with two because the two systems get bought by different people at different times. Support buys a help center because customers need somewhere to look. Operations, IT or HR adopt a wiki because employees need somewhere to look. Neither purchase is wrong on its own, and nobody ever decides to maintain the same answer in two places. It just becomes true.
The tell is which direction the gap runs. A team that bought a help center first goes looking for an internal knowledge base, because agents need the caveats and exceptions that never belonged on a public page. A team that started with a wiki goes looking for a help center, because a wiki was never built for a stranger arriving with one question. Both arrive at the same shopping list from opposite ends.
What does running two actually cost?
It costs you the accuracy of both. The public article ages because nobody who works with it daily is allowed to fix it, and the internal note stays accurate because it is where the real answer goes. Customers get the stale copy.
This shows up clearly in the self-service numbers. A Gartner survey of 5,728 customers, conducted in December 2023, found that only 14% of customer service issues fully resolve in self-service, and that even for issues customers describe as very simple the figure is 36%. The most common reason for failure, in 43% of cases, was that customers could not find content relevant to their issue. Not that the content was wrong. That it was not there.
The second number is the one that should decide this for you. A Gartner survey of 5,801 customers from January and February 2025 found that 60% of customer service agents fail to promote self-service at all. When agents do mention it, 25% are neutral and 12% are explicitly negative. Gartner also found that agent promotion is associated with a doubling of the customers who say they will use self-service next time.
Agents do not recommend a help center they do not use. If the articles customers read are in a product agents never open, agents have no opinion about whether those articles are any good, no way to fix one that is wrong, and no reason to send anybody there. The 12% who say something negative are not being difficult. They are reporting on a system they have watched go stale.
| The answer | Customer-facing version | Internal version |
|---|---|---|
| The refund window | “Within 30 days of purchase.” | “30 days, 60 on annual plans, check the plan field first.” The exception never reached the public article. |
| Resetting a password | The current steps, updated at launch. | The current steps plus the workaround for the case the new flow broke last quarter. |
| Plan limits and pricing | Updated when marketing ships a change. | Updated when a customer complains. The two disagree for weeks at a time. |
| A known bug or outage | Usually absent entirely. | Pinned in a chat thread, which nobody can search and which scrolls away by Friday. |
| Security and compliance answers | A trust page, written once, rarely revisited. | A spreadsheet the sales team maintains. Neither document knows the other exists. |
What one library with two audiences looks like
One library means every answer has a single home and a visibility setting, rather than a home determined by who is allowed to read it. Three buckets cover everything.
Public articles
The majority. How something works, what a plan includes, how to do a task, what a policy says. Agents read the same article they send, which is what gives them a reason to care whether it is accurate.
Public articles with an internal note
The interesting case, and the one a two-system setup handles worst. The customer-facing text says the refund window is 30 days. The internal note attached to it says which plans get 60, who can approve an exception, and what to do when the customer is already past it. One article, two layers, no second copy to keep in sync.
Internal-only articles
Anything that would cause harm if published: fraud thresholds, discount approval limits, escalation contacts, security procedures, the exact wording of a legal position. This list is genuinely short, which is precisely why it rarely justifies buying a second product.
The same structural rules apply to all three, because retrieval does not care which audience an article was written for. An assistant answering an agent and an assistant answering a customer are running the same search over the same passages, with different permissions.
How do you merge two knowledge bases into one?
Merge them by reconciling the answers that already exist in both places, then setting visibility per article. You are not migrating everything. You are finding the duplicates and deciding which version is true.
- List the answers that exist in both places
Take the twenty questions your team answers most. For each, find the public article and the internal note. Every pair that disagrees is the cost of running two systems, and the count is usually higher than anyone expects.
- Merge each pair into one article with one owner
The internal version normally has the accurate detail and the public version has the better wording. Keep both. Give the result a named owner and a review date.
- Set visibility per article, not per system
Public, public with an internal note attached, or internal-only. Visibility is a property of an answer. It is not a reason to buy a second product.
- Let agents edit the article they just used
An agent who can correct a wrong article in the moment is the only maintenance model that survives contact with a real queue. Anything that routes edits through a separate documentation project will stall.
- Send customers the article the agent read
When the reply links to the same article the agent relied on, the agent acquires a reason to care whether it is any good. That feedback loop is what moves self-service resolution.
Step four is the one Gartner independently arrived at. Among its recommendations for improving self-service resolution is to expand content creation to reps so that knowledge gets written as part of resolving the issue rather than as a separate project. That is only possible when the agent resolving the issue and the article the customer will read are in the same system.
Expect the merge to shrink things. Most teams find that a third of their internal notes were workarounds for a public article that was simply wrong, and that fixing the article deletes the note. The same pass tends to remove a routine lookup from every request, because the answer stops being somewhere else.
When two systems are the right answer
Two systems make sense when the internal content genuinely does not overlap with what customers ask. An engineering runbook library, a deployment playbook, an HR handbook covering employment terms: none of that has a customer-facing counterpart, and forcing it into a help center product helps nobody.
The test is how much the content overlaps. Count how many of your internal articles are the real answer to a question customers also ask. If that number is small, keep the wiki. If it is most of them, you are maintaining a second copy of your help center and calling it a different product. Teams that reach that conclusion while already paying per seat for both usually find the pricing comparison makes the decision for them.