KCS, automated: How to capture knowledge as cases close

With three decades of practitioner evidence behind KCS, the methodology is sound; however, almost nobody in enterprise technical support runs it the way it was designed.

The reason is not that support leaders disagree with it. It is that KCS asks the busiest people in the building to write documentation at the exact moment they are closing a case and picking up the next one. On a queue that never empties, capture is the step that quietly stops happening.

That constraint is what automated knowledge capture changes. Not the methodology, which still holds. The part of it that depended on a rep having a spare twenty minutes.

What is KCS (knowledge-centered service)?

KCS, or knowledge-centered service, is a methodology in which support teams capture, structure, reuse, and improve knowledge as part of solving cases, rather than as a documentation project that runs alongside the work. It is developed and maintained by the Consortium for Service Innovation, a non-profit member organization, and KCS is a registered service mark of that Consortium.

Two naming notes, since both variants get searched. Knowledge-centered support was the original expansion and is still widely used; the Consortium now uses knowledge-centered service. They refer to the same methodology. It is also unrelated to any specific vendor's product, despite "KCS software" being a common search.

The methodology is built on what the Consortium calls a double loop.

The Solve Loop is where most teams believe the value is. In practice it is also where most teams break.

Why does KCS stall in enterprise technical support?

Because the Solve Loop assumes the person with the knowledge also has the time.

Enterprise technical support is close to the hardest environment for that assumption to survive. Teams support portfolios of complex, highly configurable products across multiple versions and deployment models. Resolving a single case can mean piecing together context from prior cases, engineering discussions, internal documentation, and the experience of whoever solved something similar before. The investigation is the expensive part, and it is exactly the part that never gets written down.

Then the pace changed. Products now ship faster than documentation can keep up, on support headcount that is not growing at the same rate. As I say,

"The product delivery cycle in the age of AI has greatly increased the pace in which these organizations can go and ship product. The knock on effect is that these organizations and their product offerings are changing more quickly, and they are generally operating at a very efficient, effective capacity from their support organization."

The result is a documented methodology that everyone agrees with and a knowledge base that falls further behind every release. Content Health, in the Evolve Loop, degrades not because nobody cares but because the Solve Loop upstream of it never produced enough content to keep healthy.

This matters beyond the knowledge base itself. Gartner's 2024 survey of 5,728 customers found that only 14% of customer service issues are fully resolved in self-service, and that the most common reason for failure was that in 43% of cases, customers could not find content relevant to their issue. That is a coverage problem before it is an AI problem. Every AI capability a support organization builds sits on top of the knowledge its people did or did not write down, which is the argument for treating AI knowledge management as the foundation layer rather than one initiative among several.

Can you automate the KCS loop?

Parts of it, and the parts that matter most are the parts that were failing anyway.

The useful way to think about this is not automation versus humans. It is a reassignment of who does which step. The judgment stays human. The drafting, categorizing, clustering, and routing do not need to be.

Read that table as a claim about sequencing. Automation does not make the methodology unnecessary. It removes the step where the methodology was losing, so the rest of the loop can actually run.

How Mosaic helps: Mosaic Knowledge samples resolved cases, groups them into recurring topics, compares each topic against existing knowledge, and drafts review-ready articles from the real resolutions behind them. Every article is tagged to a product collection and routed to the subject matter expert who owns that product line, so review scales across a large portfolio rather than bottlenecking on one team.

What happens when SMEs stop being authors?

They become the constraint you actually want to have.

In most enterprise support organizations, the people who can validate a technical article are not technical writers. They are subject matter experts who own a product line and who also carry a case queue. Asking them to author is asking them to choose between two jobs. Asking them to review is asking them to do the part only they can do. As I always say,

"Think about your knowledge team or SMEs more as orchestrators or conductors of knowledge versus the people that are actually playing the instruments themselves."

That reframe has a practical edge to it that comes up in every rollout. Reviewers ask how much they are expected to edit, as though a light edit means the article is low quality or their contribution does not count.

It is the wrong question. The reviewer's job is not word count. It is the decision underneath: does this topic warrant an article, is it accurate, does it belong in the customer-facing knowledge base or the internal one, and which product line owns it. An article approved in four minutes because the draft was already close is a good outcome, not a failure to add value.

There is a leadership dependency here that no tool removes. Reviewers still hold a case queue, and if review is not explicitly made part of the job, it loses to the queue exactly the way authoring did. The Consortium puts Leadership and Communication in the Evolve Loop for this reason, and automating capture does not exempt anyone from it.

That balance is also where the wider market has landed. Gartner predicts that by 2027, half of the organizations that expected to significantly reduce their customer service workforce will abandon those plans, with 95% of customer service leaders planning to retain human agents to define AI's role. Automating capture and keeping approval human is the version of this that works.

Write shorter articles than KCS-era guidance suggests

One thing genuinely has changed since the methodology was written, and it changes what a good article looks like.

Knowledge bases were built for keyword search. That rewarded long, comprehensive articles that covered as much ground as possible so they would match more queries. Retrieval works differently now, and an AI knowledge base has to be structured for it.

Self-service and agent assist run on semantic search, and an answer is often assembled from snippets across several articles rather than served as one document.

So the unit of value moved. You are surfacing an answer, not an article.

For teams supporting multiple product lines, this has a counterintuitive consequence: writing the same procedure separately for each product line, and sometimes separately for different configurations within one product line, is correct rather than wasteful duplication. Each version is retrievable on its own and answers a question that the generic version answers only approximately.

How Mosaic helps: Because Mosaic Knowledge organizes every gap and article into collections by product line or issue type, or any support attribute, multi-product teams see coverage mapped to the products they actually own. Approved articles publish into existing platforms such as Salesforce Knowledge and Zendesk Guide, with no migration or platform change.

Where the return actually shows up

Not in the article count. In the two places knowledge gets consumed.

The first is self-service. Better coverage of the topics that generate real volume means more customers resolve without opening a case, and the improvement is attributable: you can see which articles were surfaced in answers, and which of those were generated rather than hand-written. That loop, where self-service exposes the gaps and captured knowledge closes them, is the Self-Service Knowledge flywheel the whole launch rests on.

The second is agent assist. Enterprise technical support will not reach the containment rates a consumer support operation reports, and pretending otherwise is how AI business cases lose credibility. What verified knowledge does for the cases that still reach a human is make the answer available immediately, and let the AI weight approved content over a scattered fragment in an old ticket.

The Consortium's own adoption data reports resolution-time improvements of 25% to 50% within the first three to nine months, with self-service success improving over a nine to eighteen month horizon. Those are the returns the methodology was always supposed to deliver. The obstacle was never the theory.

Start where capture already broke

If your team has tried KCS and watched it fade, the diagnosis is usually not culture and rarely tooling. It is that the methodology asked for documentation time you do not have, and no amount of programme relaunch creates that time.

Automating capture changes the ask. Your experts stop writing first drafts and start deciding what deserves to exist, which product line owns it, and whether it is accurate. That is a job they can actually do between cases, and it is what lets knowledge and self-service compound instead of each waiting on the other.

Book a demo, and we will show you what automated KCS looks like against your own resolved cases.

Frequently asked questions

How does Mosaic AI know what our knowledge base is missing?

Mosaic AI analyzes the cases your team resolves. Knowledge uses those insights to group recurring topics. When a topic keeps generating cases but no article covers it, or the article that exists did not prevent the case—that is a gap. Those two signals tell you exactly what to write next, ranked by how much volume it would remove.

What is the difference between KCS and traditional knowledge management?

Traditional knowledge management treats documentation as a separate project owned by a dedicated team. KCS treats knowledge as a by-product of solving cases, captured and improved by the people doing the work, in the workflow rather than after it.

What are the KCS Solve Loop and Evolve Loop?

The Solve Loop covers what happens while resolving an individual case: Capture, Structure, Reuse, and Improve. The Evolve Loop covers what keeps the knowledge base healthy over time: Content Health, Process Integration, Performance Assessment, and Leadership and Communication.

Can KCS be automated?

The capture, structuring, categorization, and routing steps can be automated. The judgment steps cannot and should not be. AI can draft an article from the real troubleshooting behind resolved cases, but a subject matter expert still decides whether the topic warrants an article, whether it is accurate, and whether it belongs in a customer-facing or internal knowledge base.

Does automating KCS replace subject matter experts?

No, it changes their role from authoring to reviewing. The bottleneck in most programmes is expert time, and review takes a fraction of the time authoring does. Gartner predicts that by 2027, half of the organizations expecting to significantly cut customer service headcount because of AI will abandon those plans.

How long does KCS take to show results?

The Consortium for Service Innovation reports resolution-time improvements of 25% to 50% in the first three to nine months of adoption, with self-service success improving across a nine to 18-month horizon. Programmes where capture stalls early do not reach those numbers, which is the problem automation addresses.

‍