Products in this category look similar in a feature grid and behave nothing alike in use, because they descend from five different ancestors. Knowing which ancestor a product has tells you more about whether it will suit you than any comparison table, and it takes about a minute per product to work out.
The help center: built to publish
Descended from customer support tooling. Strong at a public article surface, article feedback and a widget that follows the customer, weaker at internal permissions and at anything resembling a document. Choose it when most of your articles face outward and your internal base is the smaller half.
The wiki: built to edit
Descended from collaborative editing. Strong at fast contribution, linking and page history, weak at ownership and review because everything is everybody's. Choose it in a culture where people genuinely write, and add the ownership discipline yourself, because the product will not impose it.
The document workspace: built to hold
Descended from file storage. Strong at structure, sharing and formats, weak at search that ranks answers and at telling a reader whether a page is current. Most companies already own one and mistake owning it for having a base, which is the most common reason a base gets built twice.
The service desk module: built to resolve
Descended from ticketing. Strong at surfacing an article to an agent inside the ticket and at tying articles to incident records, weak as a standalone reading surface. Choose it when the reader is nearly always an agent with a ticket open and rarely anybody else.
The search layer: built to find
Descended from enterprise search. It does not hold articles, it indexes whatever you already have. Genuinely useful late, when the content exists and is scattered, and a poor first purchase, because indexing nothing well is the same as nothing.
Questions people ask about knowledge management system types
Which shape suits a company of two hundred?
A help center with an internal half, in most cases, because it is the only shape that handles both audiences without a second system. The exception is a company where engineers are most of the writers, where a wiki will attract more contribution.
Can a document workspace be the base?
It can hold the text. What it will not give you is per-article ownership, an enforced review date and a search that ranks answers above near misses, and each of those has to be built by hand around it.
Do we need the search layer as well?
Not at first, and possibly never. It earns its place when the answers genuinely live in several systems that are not going to merge, which is a large-company problem rather than a two hundred person one.
What about an assistant that answers from our content?
That is a feature several of these shapes now carry rather than a shape of its own. It changes how the answer is delivered and not whether the answer is current, so judge it after you have judged the base underneath it.
How much does the shape constrain a later move?
Less than it feels. What constrains a move is the quality of the export, so test the export in the trial. Clean markup with titles and categories intact means a later move is a weekend of work.