Companies that already have an internal base often assume the external one is the same articles with a different audience setting. Four things are genuinely different, and each of them shows up as a complaint within a month of publishing if it was not thought about first.
The reader has no context at all
Internally you can write get access from the platform team and be understood. Externally every noun has to be one the customer would use, every abbreviation has to be spelled out once, and every article has to work for somebody who arrived from a search engine rather than from your navigation. That is a rewrite, not a permission change.
It is the most public thing you publish that nobody reviews
Marketing pages get read by several people before they go live. Support articles get written by whoever knew the answer and published the same afternoon, and they will outrank the marketing pages for a great many searches. Deciding who reads an external article before it is published is the cheapest correction available here.
Accessibility stops being optional
A public help surface is a place where accessibility obligations are real and where the common failures are easy to avoid: images that carry the instruction with no alternative text, headings used for size, tables used for layout. Fixing this after two hundred articles exist is a project; a template that does it by default is not.
The answer is quoted back at you
What the article said becomes what you told the customer, and screenshots of it will appear in complaints. This makes version history and an honest date on the page valuable in a way that has nothing to do with search and everything to do with being able to say what was published when.
What stays the same
Ownership, review dates and one answer per page are exactly the same discipline as internally, and a company that has those working internally has done most of the work. What it has not done is the rewrite in the customer's vocabulary, which is the part that takes the time.
Questions people ask about external knowledge base
One system or two?
One system with a hard publish boundary is usually right. Two systems means two search boxes and staff learning only the one they use daily, which is how the external articles go stale first.
Should customers be able to comment?
Feedback on whether the article answered the question, yes, because it points at the pages to fix. Open comments, rarely, because they become an unstaffed support channel with a public audience.
Does the external base compete with our marketing site?
For search, yes, and that is usually fine. The help article matches what the person asked and the marketing page does not, and sending them to the honest answer is the better outcome in both directions.