KCS Knowledge articles

[RogueFader]

Hi all.

Does anyone here have experience of KCS within your org who may be able to offer advice?

Currently, when a first line team resolves an incident and there is currently no knowledge article that supported them, they tick the 'Create Knowledge' box. This generates a draft article that requires review and approval before it can be published.

If the application or service involved is owned by another team, for example, Outlook being owned by a second line team—the ownership group for the article is set to that second line team. They are then responsible for reviewing and approving the article.

Looking at KCS, it seems articles can be updated and republished without needing formal ownership or approval. However, I’m curious how this works in practice within your organisations.

Specifically:

• When a first line team creates a knowledge article, do you assign the ownership group to the second line team that owns the service?
• Or do you keep the ownership with the first line team who created the article?

My concern is that assigning ownership to the second line team may delay publication, especially if the first line team needs to make updates but still requires approval.

Additionally, the 2nd line team may have no visibility of the article and information and any fix that is applied by someone following that article may be creating a bigger problem down the line.

Much appreciate hearing how others manage a balance of accuracy, ownership, and speed of publishing. Thank you in advance.

[Rafael Batistot]

Hi @RogueFader 

From KCS best practice and what I’ve seen work in other organisations:

• Keep ownership with the creating team (first line) so articles can be published quickly.
• Use internal visibility for newly created articles so they’re available immediately to support staff but not to customers until reviewed.
• Give service owner (second line) visibility on all articles related to their service — e.g., through dashboards, subscriptions, or notifications — so they can review and improve content without blocking publication.
• Allow anyone in scope to edit articles, with change history enabling rollback if needed.
• Establish lightweight review cycles (weekly/monthly) rather than formal approval before publishing.
• Reserve formal approvals only for major changes or articles intended for external/customer audiences.

This balances speed (no long waits for approval) with accuracy (owners can still correct and enhance content).

[RogueFader]

Hi

I think Dashboards could be the way, It's been hard enough to get them to look at the problem records they have been assigned, but I can look at adding newly published KCS articles to the dashboard so they have eyes on. Thank you

[PAWANK]

It is correct that KCS does not describe or insist on articles needing formal ownership and mandatory approval by 1st line or 2nd line or by a Service Owning team. Reason: KCS believes that knowledge evolves and it is never permanent. It evolves with every reuse experience and feedback. Also, KCS implements a licensing and role model for knowledge workers. Knowledge Workers gain proficiency and earn licenses (Contributor, Publisher) that allow them to create, edit, and publish articles. Once licensed, they have the authority to update articles without waiting for formal approval by a Product or Service Owner. Even if some workers who are not yet licensed publishers can edit unpublished versions, however the updated version is reviewed or certified by licensed publishers.

Having said, if assigning ownership group to the article is essential in your environment - particularly to a Service Group (article belonged to) you may like to take the following approach:

First, you will have to develop knowledge & skills required for your first line to the level of KCS "Candidate". Create draft article that needs review & approval.

When a first line team creates a draft knowledge article based on resolved NEW <Issue> incident, regardless of the ownership, send a notification to the concerned Service Owning team. You may have Service captured for this article and if yes should have reference field e.g. Service Owner. Your SN Solution Consultant should be able to enhance the workflow. 

The service owner should have competency of KCS Contributor & Publisher. They finish/complete the article framed by your first line, making sure the article stick to the guidelines, and publish. There must be some timeline for them to publish e.g. within 2 hours of having submitted to them. 

This will manage a balance of accuracy and faster Time-to-Publish.

As said earlier, if ownership group is important for your KM RACI, then let the Service Team keep the ownership, however, since your first line will be reusing the article they should be responsible for reuse, updates and recommend updates based on the feedback.

Having said, we must have some level of genuine KCS licensing model working.

[Gianluca Roncat]

If the first line provides a solution, it can usually be derived from information received from the second line or from the experience of previous similar incidents that are then reported to the second line to highlight problems with the product/service. In both cases, it is assumed that there has already been an exchange of information (first-second or vice versa), so we prefer to assign ownership to the first line to speed up the process.