Report a knowledge gap

[drosenst2]

What is your process for end users to report a knowledge gap? For instance, they run a search on Now Assist and there's no information or a supporting article for their search.

• Is that just a simple intake form?
• Do you do it pro-actively looking at search data?
• Helpful comments = No and then an option to request knowledge?
• An agentic reach out to searchers?

What does your process look like?

[SUBHENDUB]

I would prefer a combination of user feedback and proactive search analytics rather than relying only on an intake form.

User feedback: If a Now Assist response isn't helpful, users can select “No” and choose “Request a Knowledge Article.”

Automated intake: Create a knowledge gap request routed to the Knowledge Management team for review.

Proactive monitoring: Analyze failed searches and recurring queries to identify missing knowledge.

AI-driven approach: Use Now Assist to categorize requests, identify duplicates, and prioritize gaps. Agentic follow-ups can be considered for repeated unsuccessful searches.

The goal is to close the loop by notifying users when the missing article is published and tracking whether it resolves their issue.

[drosenst2]

Questions:

• Are these customizations: 1. If a Now Assist response isn't helpful, users can select “No” and choose “Request a Knowledge Article.” 2.  Use Now Assist to categorize requests, identify duplicates, and prioritize gaps. Agentic follow-ups can be considered for repeated unsuccessful searches.
• Should this be done through Knowledge Center: Analyze failed searches and recurring queries to identify missing knowledge.

[DavidReynolds]

Finding knowledge gaps is my biggest weakness since it is tough determining if a topic is a "one off" that rarely occurs, or is useful to the entire workforce.

In terms of finding knowledge gaps, I use a combination of approaches starting with the Feedback dashboard. Most of our users do not leave any feedback on articles. Those that do get an email from me asking them how I can improve that article. If they respond--there's less than a 50% response rate--I use that to update articles. 

The second step is following tickets, mainly those where user actions can self-resolve them. I look them over, see how they were resolved and if the issue is new, consider writing an article. I'm posting a question on that in a moment.

The third step is reviewing Moveworks interaction data, looking at feedback and topics. New topics with several responses in a three to six month span get an article. Most of these resolutions become updates to existing articles.

I also interact directly with techs. When one can't find an article on specific topic, I check the knowledge bases. If the topic exists but the search terms used didn't locate it, then I update the article. If an article does not exist, then I run the idea past several people and use their comments to shape an article.

[MaryG]

You're already taking a thoughtful approach by looking across feedback, tickets, Moveworks interactions, and technician input rather than relying on a single source.

One thing I'd challenge is the idea that a topic needs to occur frequently or benefit the entire workforce to justify a knowledge article. Frequency matters, but so do business impact, repeatability, complexity, and the opportunity for self-service. Something that happens only occasionally may still be worth documenting if it saves significant time or prevents a costly disruption.

I also think there's an important distinction between a knowledge gap and a findability gap. Sometimes the knowledge exists, but users can't find it. Other times they find the article, but it doesn't adequately answer their question. Those require different corrective actions.

You might also want to explore ServiceNow's Knowledge Demand Insights and Knowledge Center's Potential Gaps capabilities, depending on your licensing and configuration. These can help identify patterns in incidents and cases that may indicate missing knowledge, reducing some of the manual analysis you're doing today.

Ultimately, I'd recommend establishing a simple, consistent decision framework for evaluating potential gaps. Not every identified gap warrants a new article, and not every low-frequency issue should be dismissed.

The goal isn't necessarily more articles. It's making sure the right knowledge exists, is discoverable, and actually helps people resolve their issues.