Your knowledge base is a support metric, not a documentation project

Almost every organisation has a knowledge base. Most were built during a push, are now partly out of date, and are used mainly by the team that wrote them.

The instinct is that this is a content problem: write more, write better. It is usually not. It is a timing and placement problem.

Written for the wrong reader

Most knowledge base articles are written by someone who understands the product, describing how a feature works.

The person reading is not trying to understand a feature. They have hit a specific wall, they are mildly annoyed, and they are searching with the words they would use, not the words you named things with. They want to know whether this can be fixed in the next ninety seconds.

"Configuring approval workflows" is documentation. "Why can't my manager approve this?" is a knowledge base article. The content underneath may be identical. The title determines whether it is ever found.

Written at the wrong moment

The best time to write an article is immediately after resolving a ticket, by the person who resolved it, while the diagnosis is still in their head.

The worst time is during a documentation sprint three months later, when someone is working from a list of topics and writing the general case rather than the specific problem.

The practical rule that works: if a ticket takes more than a few minutes to diagnose and could recur, the resolution note is the article. Do not wait for it to happen a second time — by then the reasoning has faded and you are reconstructing it.

This only works if creating the article from the ticket is nearly free. If it means opening a different system, logging in, choosing a category and formatting content, it will not happen. The support tool and the knowledge base need to be the same tool.

Measuring the wrong thing

Article count is not a metric. Page views are barely one.

Three that mean something:

Deflection on specific topics. Did ticket volume for this issue fall after the article was published? This is the only direct measure of whether it worked.

Searches with no useful result. Your customers are telling you exactly what to write next, in their own words. Most organisations never look at this list, and it is the single most valuable input to a content plan.

Article age against product change. An article written before a release that changed the thing it describes is worse than no article. It costs you trust and generates a ticket anyway.

The internal use case is bigger than the external one

Everyone justifies a knowledge base by customer self-service. In practice the larger win is often internal: a new support hire resolving a ticket without interrupting a senior engineer, or an implementation consultant finding the answer to a configuration question at 9pm.

That reframes what to write. The highest-value articles are frequently the ones you would never publish externally — the awkward workaround, the known limitation and how to explain it, the thing that breaks when a customer does X.

Where PlaNath fits

PlaNath includes a knowledge base alongside support tickets, defects, projects and the customer record, in the same system. That matters for two specific reasons: writing an article from a resolved ticket is a short step rather than a context switch, and search covers the material rather than a separate silo.

A knowledge base is not a documentation project you finish. It is a support function you operate, and it belongs next to the queue it is supposed to shorten.