Making Knowledge-Centered Service Real in Jira Service Management

[#1]

I have been exploring Knowledge-Centered Service (KCS) for a while now, and the more I sit with it, the less it reads like a support fad and the more it reads like a way of working that Jira Service Management was quietly built to support. If you want the clean definition of the system, Atlassian has a solid primer here: https://www.atlassian.com/itsm/knowledge-management/kcs.

The short version: KCS treats knowledge as a byproduct of solving requests, not as a separate documentation project you never get around to. It runs as a continuous loop: capture, structure, reuse, improve, and then step back to see the big picture. What I want to share here is how each part of that loop maps to something you can actually turn on in Cloud, rather than leaving it as theory.

Capture, right where the work happens.

The core KCS idea is that the article gets written while the problem is being solved, by the person solving it. In JSM, you can create a knowledge base article directly from the issue view, so capture lives inside the request instead of on a separate to-do list. If you have Rovo available, typing /manage-knowledge-base on an issue and prompting it to create an article will draft one from the resolution steps and agent comments, and it strips out ticket keys and names for you. It even pulls data from up to 10 similar closed issues from the last 6 months, so the draft shows the pattern rather than just the single ticket. I still treat that draft as a starting point a human reviews, not a finished article, but it removes most of the blank-page friction that kills capture in practice.

Structure, so articles stay usable.

KCS leans hard on consistency, and this is where templates earn their keep. A simple, repeated structure for your articles (symptom, environment, resolution, and so on) makes them faster to write and far easier for both customers and AI agents to parse later. Consistency here is not cosmetic. It is what makes the reuse step actually work.

Reuse, before anyone writes from scratch

The discipline that separates KCS from a normal wiki is search first. In JSM, this happens on a few fronts. Agents see suggested articles on the request as they work, can link the request to an article, and can share an article with the customer directly on the work item, turning a good article into an instant answer instead of a restated explanation. On the customer side, the portal surfaces articles as people type, and on Premium or Enterprise, the virtual service agent answers directly from your linked knowledge base and only escalates to a ticket when the article does not resolve the issue. If you go a step further with Rovo Service, it uses your internal knowledge base to generate a resolution plan for a request, which you can run supervised at first, and it flags where the underlying knowledge is thin. Every one of those deflections and plans is the loop paying you back.

Improve, as a side effect of reuse.

KCS says reuse is review. Every time an article gets used, it is a chance to fix it. In JSM, that means editing the linked article in place when a step has drifted, and using the "was this helpful" feedback to spot articles that look busy but are not actually resolving anything. The piece teams usually miss is making this a habit rather than a hope, and this is where Confluence automation helps. A scheduled rule can nudge the owner of an aging article to review it, apply a label when something has not been touched in months, or route stale pages to a queue, so freshness does not depend on someone remembering. Rovo Service feeds this too, since the gaps it surfaces during resolution are a ready-made backlog of what to improve next.

See the big picture, and let it tell you what to write next.

The final KCS step is the one teams skip most, and it is the most valuable. Instead of guessing what to document, let demand tell you. Native knowledge base reporting shows what is being viewed and what is deflecting. If you have Rovo, the discovery flow (/manage-knowledge-base, then asking for gaps or high-impact topics) clusters recent tickets and returns suggested topics with actual ticket volumes and trend data, so you write the articles that remove the most future work first. On the Confluence side, mission control gives admins a health view of the knowledge itself, things like which spaces hold the most inactive content, what people are actually searching for, and which pages have no active owner. Read together, those two views tell you what to create, what to retire, and what to fix, which is demand-driven knowledge management in practice rather than on a slide.

Where I am at the moment

None of this is really a tooling problem. The features above make KCS almost frictionless, but the actual hurdle is cultural: convincing a team that pausing to capture knowledge is the job, not a detour from it, especially when people are measured purely on how fast they close tickets. The tooling is the easy 20 percent. The habit is the other 80.

So I would love to hear from you: have you adopted KCS formally, borrowed pieces of it, or just been inspired by the general idea? Have you ever heard about it? What worked, what stalled, and which JSM features made the biggest difference in getting the loop to actually turn?

[zoltanersek _outpostlabs_dev_]

One thing I've noticed is that retrospectives and incident reviews are gold mines for KCS. If an action item or workaround keeps coming up, that's usually a signal the knowledge should be captured instead of rediscovered every sprint. Making knowledge capture part of the team's normal workflow is the hard part, though

[Dave Mathijs]

Hi @Martin Runge Thanks for sharing.

I totally agree with your actual hurdle.

FYI: Knowledge-Centered Service (KCS) has been revamped from KCS v6 to Knowledge-Centered Success : What's New in Knowledge-Centered Success?

[Martin Runge]

Thanks, @Dave Mathijs, for the update on the new Knowledge-Centered Success.

@zoltanersek _outpostlabs_dev_ You are right. There are many formats, including established ones like retrospectives and incident reviews. Do you use KCS?