Knowledge base

Most knowledge bases are organized the way the product is built: a section per module, an article per feature. That structure is the company's mental model, and the reader doesn't have it yet — which is why the search box gets used instead of the navigation, and why articles that answer the question sit unread three levels down.

Organize by what someone is trying to finish.

The operational shape

Trigger. A task customers do that has no written path, or a support pattern pointing at one.

Reads. Product truth. Voice, lightly.

Cadence. Per task when writing, and per release for everything already written. This is the only capability in the educate category with two cadences, and the second one is where knowledge bases usually fail.

Gate. Approve before publish, checked for accuracy rather than for tone.

What good looks like

One task per article. The article that covers setup, configuration, and troubleshooting is three articles that a reader has to skim to find their third of it. One task, start to finish, titled as the task.

The title is the thing the reader would type. "Connecting your CRM," not "CRM integration overview." The second title is a category; the first is a task, and only one of them matches what someone searches.

It says what happens next. The end of a task is where someone is most likely to be unsure they did it right. A closing line naming what they should now see is the cheapest support deflection available.

Prerequisites are at the top, not discovered halfway. An article that reveals in step 6 that you needed admin access is worse than no article, because the reader has now spent five steps learning that.

It's accurate before it's polished. A well-written article describing a button that's been renamed costs more than a plain one that's correct. This is the only educate capability where accuracy genuinely outranks voice.

When it goes stale

This is the one content type with mechanical, predictable decay — and that's an advantage, because mechanical decay can be automated.

The trigger is a product release. Anything that renames a screen, moves a setting, or changes a flow invalidates every article describing it. Two supporting triggers: support volume rising on a task that has an article, which means the article is wrong or unfindable, and a step count that no longer matches, which is the cheapest automated check available.

The structural fix is that every article names the screens and steps it describes, so a release that renames one has something to match against. Without that, the only decay detector is a customer.

What it feeds

• Support deflection — the measurable outcome this capability is judged on
• Onboarding emails and in-product copy — the same friction, addressed earlier in the journey
• FAQ pages — when a task turns out to be a question rather than a walkthrough

The relationship with in-product copy runs both ways: a task that needs a long article is often a task the interface should make shorter, and the knowledge base is where that evidence accumulates first.

Where ContentOS fits

As of September 2026 this capability is in build. The release-triggered review is the part that matters, and it is the part most knowledge bases do not have.