Zendesk Internal Knowledge Base
One Guide instance can serve customers and a Zendesk internal knowledge base, as long as you're deliberate about who sees what. Get the permissions wrong once and it's a bad day.
Three ways to build a Zendesk internal knowledge base
They are not equally good, and the right answer depends on how much internal content you have.
Most teams should start with restricted sections and only move to a separate brand when the internal content outgrows being a guest in someone else's house.
How the permissions actually work
Guide gates article visibility through user segments. A segment is a rule describing a set of people, and every article carries one, either inherited from its section or set on the article itself.
Two segments exist out of the box in most accounts: signed-in users, and agents and admins. "Agents and admins" is the one that makes an article internal. Anything else, including a signed-in customer with an account, cannot see it, cannot search it, and gets no hint it exists.
Beyond that you can build custom segments from tags, organizations and group membership, which is how you get "support agents only, not the sales team" or "tier two only". That is covered properly in the user segments guide.
One warning worth repeating. Visibility is set at the section level and inherited, and an article moved between sections can change visibility with it. Audit after any reorganisation, not before.
What belongs in it
Internal knowledge isn't a dumping ground for everything too rough to publish. The useful test: would an agent open this while a customer is waiting?
Onboarding material and long policy documents can live here too, but they are read once. Optimise the layout for the mid-ticket lookups, not the onboarding.
Making agents actually use it
An internal knowledge base nobody opens is a filing cabinet.
The lever is the knowledge panel in the agent interface, which searches your Guide content from inside the ticket. If your internal articles live in the same Guide instance, they surface there, which is the entire argument for restricted sections over a separate tool. Agents will use what is in front of them and won't use what is two tabs away.
The second lever is ownership. Every internal article needs a named owner and a review date, because internal content decays faster than public content. Public articles get corrected by customers complaining. Internal ones just quietly go wrong, and an agent follows a two-year-old escalation path to a team that no longer exists.
The mistakes that cost you
Publishing an internal article to the wrong section. It happens, and the fix is a naming convention obvious enough that a tired person notices: prefix internal section names with "Internal" and give the internal category a different position in the tree.
Second, writing internal articles that read like customer articles. Internal content should be blunt. Bullet points, decisions, thresholds. No brand voice.
Third, treating it as a knowledge base when it is really a runbook. If a document is followed step by step under time pressure, format it as steps. Numbered, one action each, no preamble. An agent scanning during a live chat doesn't read your context paragraph.
Fourth, and this one is subtle: letting internal and public versions of the same policy diverge. If the refund window is in both places, one of them will be updated and the other will not, and an agent will confidently tell a customer something your own help centre contradicts. Keep the number in one place and reference it from the other.
Frequently asked questions
How do you keep internal articles away from customers?
With user segments. Zendesk internal articles restricted to a signed-in agent segment become a Zendesk agent knowledge base inside the same Guide instance. Zendesk restricted articles in a separate brand give you a Zendesk internal help center that customers never see at all.
Can Guide hold a Zendesk internal knowledge base?
Yes. Set the article or its section to a segment such as agents and admins, and it becomes invisible to everyone else, including in search.
Should internal docs use a separate brand?
Only once the volume justifies it. A separate brand is the safest against accidental exposure but adds a whole help centre to maintain, and multibrand depends on your plan.
Do light agents see internal articles?
Generally yes, if they fall inside the segment you have set. Verify with a real light agent account rather than assuming, since role behaviour varies by plan.
Can agents search internal articles from inside a ticket?
Yes, the knowledge panel in the agent interface searches your Guide content, which is the strongest argument for keeping internal docs in Zendesk rather than in a separate wiki.
What happens if I move an article to a different section?
It can inherit the new section's visibility. Check permissions after any restructure, because this is the most common way internal content becomes public.
Internal docs, cleaner queues
Good internal knowledge cuts rework. Ticket Merger cuts the other kind: the same request answered twice.
Start free trial14-day free trial. No credit card required.