A customer-facing base is measured against a number an internal one is not: how many people it stopped from writing in. Four things decide that, and none of them is the editor everybody demos. They are, in order of how often they are the actual problem: what the articles are about, whether the words match the customer's, whether anybody has checked them lately, and who is asked when nobody has.
It answers the questions people actually ask
Which means the article list comes from the support inbox, not from the product's feature list. The single most common failure is a base organised around how the product is built rather than around what goes wrong with it, which produces a complete-looking base with no article about the thing everybody writes in about.
It is findable in the words customers use
Customers do not know your internal nouns. If the product calls it a workspace and everybody else calls it an account, the article has to carry both words, in the title, or the search returns nothing and they write in.
It is current, and visibly so
A published date and a last-reviewed date do different jobs: the first tells a reader how old the article is, the second tells them somebody checked. Showing the review date is the cheapest trust signal a customer-facing base has, and almost nobody uses it.
It has an owner per article
Because customer-facing articles rot fastest: the product changes, the screenshot goes wrong, the pricing moves. The base that survives is the one where each article has somebody who will be asked twice a year whether it still matches the product.
What it is not for
It is not the place to put anything internal. The moment the same base serves both audiences somebody publishes an internal note, and the cost of that is much higher than the saving from having one system.
What the article itself looks like when it works
One question in the title, in the customer's words. The answer in the first two sentences, because most readers stop there. The steps, if there are steps, numbered and each with the screen it happens on. The exception or the edge case in its own short paragraph, since that is what the second reader came for. A last line that says what to do if it did not work, with a route to a person. And under the title, two dates: when it was published and when somebody last confirmed it, with the owner's name if the base can show it. Everything else, the related articles, the ratings widget, the tags, is the platform's furniture and does not deflect a single ticket.
Questions people ask about customer knowledge base
How many articles should a customer base have?
Start from the inbox: the twenty questions that account for most tickets. Twenty good articles deflect more than two hundred thin ones, and two hundred is a review load that will not be carried.
Should it be public or behind a login?
Public unless a specific article cannot be, because a public base is also your search presence. A login on the whole base means every question also has to pass an authentication step, which is exactly the friction that sends people to the contact form.
How do we know it is working?
Ticket volume on the topics you wrote about, before and after. If it does not move, the articles are answering questions nobody was asking, which is a content problem rather than a platform one.
Should the base show the owner’s name to customers?
A role is enough for the reader and a name is what matters internally. Showing the last-reviewed date publicly is the trust signal; the name attached to it is for the person who has to be asked, and it can stay inside the record.