Knowledge-Centred Service (KCS) explained, and what changes when AI reads it

Knowledge-Centred Service is a methodology with certification tracks, a vocabulary, and a reputation among practitioners for being heavy. Some of that reputation is earned — by rollouts that produced a compliance exercise and a thousand articles nobody reads. The idea underneath it is small enough to state in a sentence: knowledge is created as a by-product of solving problems, not as a project that happens afterwards.

Everything else in KCS follows from taking that sentence seriously, and it is worth taking seriously because the alternative — a documentation backlog — has a hundred per cent failure rate in busy teams.

The moment of maximum knowledge is while the problem is being solved. You have the error message in front of you, you know which three things you tried that did not work, you remember the detail that made this instance different. An hour later that detail is gone. A week later the whole thing has compressed into "the printer thing, we fixed it."

So the article is written inside the ticket, by the person resolving it, before it closes — not exported to a documentation queue for a future self who will be exactly as busy. In practice that means a small structured note on the way to closure: the problem in the requester’s own words as the title, the environment and preconditions that made it apply, what actually fixed it, and how you knew it worked. Four fields, two minutes, while the context is still loaded.

The reuse half is the same habit in reverse. If an article exists, you link it to the ticket rather than retyping the answer; if it exists but is wrong or incomplete, you fix it in place, then link it. KCS calls this searching early and searching often. The practical effect is that the knowledge base is exercised on every ticket instead of being visited during audits.

It is tempting to read the documentation backlog as a discipline problem, which leads to reminders, quarterly documentation days, and a spreadsheet of owed articles. None of it works, because the cause is structural rather than moral.

Documentation-later loses three fights it cannot win. It loses the priority fight, because a written article helps a hypothetical future ticket while the queue in front of you is real and visible and someone is waiting. It loses the context fight, because the writing gets easier the closer you are to the work and by the time the calendar reaches it the details are gone. And it loses the availability fight, because the person best placed to write it is the person who resolves the most tickets, which is the person with the least free time.

Anything that requires a separate documentation phase is therefore the first thing cut in a busy week, every time, in every team. The fix is not to defend the phase harder. The fix is to delete it — if capture is not part of resolving, it will not happen at all.

Four shifts do most of the work. Knowledge becomes part of the definition of done for a ticket rather than a separate task, so it is never competing with the queue. Improving an existing article counts as much as writing a new one, which is what stops the corpus growing into fifty overlapping versions of the same answer. Rough drafts are allowed to exist, because a searchable rough answer beats a polished imaginary one and the next reader can improve it. And what gets written is decided by demand — you write what someone actually asked, in the order they asked it.

The measurement is where KCS programmes most often go wrong. Count articles created and you will get articles created: content farms of low-value pages, written to hit a number, that make retrieval worse for everyone. Count reuse instead — how often an article gets linked to a resolution, how often it gets improved, how often it stops a ticket from being filed. Reuse is only countable if linking an article to a ticket is a single action, which makes that piece of tooling a prerequisite rather than a nice-to-have.

One organisational point that is easy to miss: if the knowledge base lives in a wiki nobody on the support team can edit without a review board, none of this works. The person resolving the ticket must be able to publish. Review can happen after, on the articles that turn out to matter.

KCS was designed when the reader was a colleague. Colleagues are forgiving readers: they fill in missing preconditions from context, notice when a screenshot looks five years old, and know that the article about the old VPN is about the old VPN. A retrieval system does none of that. It reads a chunk, has no idea what year it is, and answers with the same confidence whether the article is current or abandoned.

Three KCS habits get more important as a result. Self-containment becomes mandatory: an article that begins mid-context or assumes the reader knows which team owns what will produce answers with exactly those gaps. Draft status has to be machine-visible, because "rough but useful" is a fine signal for a human colleague and a dangerous one for a system that will present it as authoritative — either mark confidence in a way retrieval respects, or do not publish. And archiving stops being housekeeping and becomes correctness work, since a stale article no longer sits quietly at the bottom of a search page; it competes for retrieval on phrasing alone and can win.

Two get easier. The flag-it-fix-it loop gains a signal source that never existed before: every time the AI answers badly or hands off to a human, that is a specific, timestamped, clustered piece of evidence about which article is missing or wrong — feedback humans never bothered to give. And the by-product principle gets literal, because when resolved tickets are themselves retrievable, writing a good resolution in the ticket is writing to the knowledge base. The article and the ticket note stop being two artifacts.

This is the shape FlowTux is built around: triage grounded in the linked codebase and resolved ticket history together, so a resolution written once becomes retrievable context for the next occurrence rather than dying in a thread; semantic deduplication so a recurring question is visibly recurring; per-category suggest, approve, or autonomous modes so a category can run on its own only once its knowledge is good enough; and an allow-listed autonomous path where every step is written to the ticket timeline as an audit trail — which is also the record that tells you which answers were not good enough. The knowledge base stops being a project and becomes exhaust from running the queue.