Knowledge-Centered Service Works. Getting Analysts to Do It Doesn't.

There is a field in your ticketing system called something like "Resolution Notes." Open twenty closed tickets from last month and read what is in it. Roughly half will say some version of "resolved" or "user confirmed working." A few will say "see attached." One will contain a genuinely useful four-line explanation of what was actually wrong, written by an analyst who has not learned yet that nobody will ever read it.

That field is where Knowledge-Centered Service lives or dies, and in most service desks it has already died there.

I want to be careful at the outset, because this is a topic where criticism gets mistaken for dismissal. KCS is good. The methodology is sound, the research behind it holds up, and the core insight — that knowledge should be captured as a byproduct of solving the problem rather than as a separate documentation project — is correct in a way that most process frameworks are not. I am not arguing against it.

I am arguing that almost every organization that adopts it gets the same result, and that the reason is not a failure of understanding.

The two-minute problem

At the moment an analyst finishes a call, they are holding a complete, fresh, correct understanding of a problem and its fix. This is the ideal moment to write it down and everybody knows it. That is the whole premise.

It is also the moment when the queue is showing nine waiting, the average speed of answer is on a wallboard above their head, and the difference between closing this ticket now and closing it in three minutes is visible to their supervisor.

Writing a usable article takes longer than three minutes, because the useful version is not the resolution notes. It is the resolution notes plus what the user was actually trying to do, plus the symptom in the user's words rather than the diagnosis in the analyst's, plus what you check first to know whether this is that problem or the other one that looks like it. That is a genuine piece of writing. It takes ten minutes to do properly and it is competing with a metric that is measured in seconds.

Nobody in this picture is behaving badly. The analyst is optimizing for what is measured. The supervisor is managing to the numbers they are handed. The numbers are the ones the organization chose. KCS asks all of them to spend a scarce resource on a benefit that lands somewhere else, later, for someone else.

Framed that way, the adoption failure is not mysterious at all. It is the predictable result of asking people to pay a cost that shows up on their scorecard for a benefit that shows up on someone else's.

What actually changes behaviour

I have seen three things work and two things not work, and the two that do not work are the two that get tried first.

Training does not work. Everyone gets certified, the certificates go in a folder, and article creation rises for about five weeks. Exhortation does not work either, including the version where a director explains the strategic importance at an all-hands. People already agree with the strategic importance. Agreement was never the constraint.

What works, in rough order of how much I have seen it move the needle:

Put article contribution in the metric that the supervisor manages to, and take something else out. Not added on top — most KCS rollouts add an expectation without removing one, which is a real cut to capacity dressed up as a cultural initiative. If writing is part of the job, then the handle time target moves. If it does not move, you have announced a priority rather than set one.

Make the article the resolution rather than a copy of it. The single largest structural cause of low contribution is that the analyst types the fix into the ticket and then has to retype it into a knowledge tool. That is not a motivation problem, it is a data entry problem, and it has a technical answer. If closing the ticket with the fix in the right field is the act of publishing, contribution rates change without anyone being asked to care more.

Let the article be rough. KCS says this and organizations ignore it. The moment a draft has to pass review before anyone can see it, the analyst is writing for a reviewer instead of for the next analyst, and the effort roughly doubles. Publish it as unreviewed, mark it as unreviewed, and let the second person who hits the problem improve it. A slightly wrong article that exists beats a perfect one that was never written, and it also beats the current state, which is that the knowledge is in a ticket nobody will find.

The objection about quality is fair

Someone always raises the risk, and they are right to. Unreviewed articles can be wrong. In healthcare, a wrong article can propagate a workaround that should have been escalated, and the article gives it a shape and a permanence that a verbal answer never had.

That is a real cost and I would not wave it away. But notice what it is being compared against. The alternative is not a reviewed article. The alternative is no article and the same wrong workaround transmitted by word of mouth, where it is equally wrong, spreads at a similar rate, and cannot be found and corrected because it was never written anywhere.

Writing it down does not create the error. It makes the error addressable. The first time a bad article gets caught and fixed, the organization has done something it could not previously do at all.

What I would put review effort into is not gating publication but triaging by consequence. Most service desk knowledge is about printers, credentials, and peripherals, where a wrong article wastes ten minutes. A small fraction touches something clinical or something regulated, and that fraction deserves a named reviewer and a real workflow. Treating those two categories identically is how review queues grow to six weeks and the whole thing stops.

Measure whether it is reaching anyone

The metric most KCS programs report is articles created. It is the wrong one, and it is wrong in a way that gets worse over time, because an article count only goes up and a corpus that only goes up gets less useful.

The number I would want is how often a question got answered without a human, and specifically whether the questions being answered are the ones people actually ask. That requires capturing the question, not only the resolution — which most ticketing systems do not do, because a question that resolved itself never became a ticket. This is where a retrieval layer sitting in front of the corpus earns its place: it sees the questions, including the ones nobody logged, and it can tell you which articles are load-bearing and which have never been returned to anyone. Solution Compass surfaces both halves of that, and the second half is the one that lets you retire things without guessing.

Then go back to those closed tickets. The analyst who wrote the four-line explanation nobody read is the person whose behaviour you are trying to make normal. Find out whether anything in your current system would have told them it was worth doing.