Determining If a Topic Deserves a Knowledge Article

[DavidReynolds]

Does your team or company have rules for determining when to create a new knowledge article, when to update an existing one and when to ignore the topic?

I'd like to create guidelines I (I'm a team of one) can follow to know when a new article is required.

Do you create a new article when similar tickets are filed once every six months, or at least 2-3 times in say a 60-120 day period?

I scan support tickets every day, looking for issue trends and when I find them, using what I learn to update the current crop of articles. I'm also using Moveworks functions to do the same, though not as often. I spend most of my day in ServiceNow.

I'm also proactive in that I work with teams releasing major updates to existing software used by large groups. I do the same thing  when a new product is about to be released.

[MaryG]

Hi David,

I would caution against using ticket frequency alone to determine whether a knowledge article should be created.

A recurring issue is certainly a good indicator of knowledge demand, but frequency is only one consideration. I'd also evaluate business impact, resolution complexity, self-service potential, and whether the knowledge could be reused.

For a team of one, I'd recommend a simple decision framework:

• Create a new article when there's a validated, reusable solution that isn't adequately covered by existing knowledge.

• Update an existing article when the information is incomplete, outdated, difficult to find, or needs clarification.

• Monitor the topic when you suspect a recurring knowledge gap but haven't established a reliable solution or sufficient context.

• Take no action when the issue is unique, unlikely to recur, or already adequately documented.

Your practice of reviewing incidents daily and collaborating with teams before major releases is excellent. I'd continue both.

I'd also recommend looking beyond incident volume. Search terms that produce poor results, unsuccessful self-service interactions, and repeated escalations can identify knowledge gaps that ticket analysis alone might miss. Your Moveworks data could be particularly valuable here.

ServiceNow also offers Knowledge Demand Insights, which can help identify incidents with inadequate knowledge coverage, depending on your configuration and available capabilities.

One final consideration: The goal isn't to create more articles. It's to improve knowledge coverage and reuse. A smaller collection of accurate, findable, well-maintained articles is far more valuable than a large collection of overlapping content.

I wouldn't establish a rigid threshold such as three incidents in 60 days. I'd use frequency as a prioritization signal, not a prerequisite for creating knowledge.

[drosenst2]

I'd leverage the KCS methodology  for this one. The solve and evolve loop really help guide the decision making process for article creation, updating, and retirement.

I always implement it into my ServiceNow knowledge management programs. It's also verified methodology integrated directly into the ServiceNow platform.