Most helpdesks treat documentation as a task someone will do later, separately from actually resolving tickets, which means it competes with ticket volume for attention and reliably loses. The result is the same category of issue solved from scratch repeatedly by different agents, each one unaware that a colleague solved the identical problem last month.
Knowledge-centered service inverts this by making the knowledge article part of resolving the ticket rather than a separate step afterwards. An agent solving a new problem writes a short article as they go, at the moment they have the most context and the least effort required to capture it. Writing it later, from memory, after the pressure of the ticket has passed, produces worse documentation for more effort.
The habit that makes this stick is searching the knowledge base before starting on a new ticket, every time, rather than assuming nothing exists yet. An agent who searches first and finds nothing writes a new article with confidence it's actually needed. An agent who never searches writes duplicate articles that fragment the knowledge base into three slightly different answers to the same question.
Article quality matters more than article count. A knowledge base with three hundred stale entries, half of them describing a product version that no longer exists, trains agents to stop trusting search results and go back to solving everything from scratch. Reviewing and retiring old articles on a schedule is as important as writing new ones, and it's the part most KCS implementations skip.
