ServiceNow Knowledge Management Health Check

A knowledge management health check works out why a knowledge base has stopped being used, and it does that by reading the search log in a fixed order before interviewing anyone. This page covers article inventory and coverage, quality and currency, usage and search effectiveness, categorisation and navigation, the contribution workflow, linking knowledge to incidents and requests, performance metrics, duplicates and stale content and the cost of removing them, and when a health check will not solve the problem.

Knowledge Article Inventory and Coverage Analysis

We audit knowledge base: what articles exist, when were they last updated, what topics are covered, what gaps exist. We measure: coverage (what percentage of common problems have documentation), article distribution (some topics have dozens of articles, others have none), age of articles (are they recent or outdated). Common findings: knowledge base has thousands of articles but only hundreds are used, many articles are duplicates (same topic with different wording), articles cover obsolete versions of software. We identify coverage gaps: common problems without documentation, common questions that require expert response instead of self-service. We assess: is knowledge base comprehensive or sparse relative to support volume.

Article Quality and Currency Assessment

Not all articles are created equal. We audit quality: are articles accurate (can someone follow steps and get expected result), are articles clear (written at appropriate technical level), are articles current (reflecting current process or software version). We sample test: follow article steps, confirm they work and produce expected result. Common findings: articles have errors (steps are wrong or incomplete), articles are outdated (reflect old software version), articles assume knowledge readers don’t have. We measure: article accuracy (what percentage of sampled articles are correct), article understandability (do non-experts understand articles written for experts). We also audit currency: which articles need updating, are articles marked when processes change. We assess: is knowledge base creating value by solving problems correctly, or creating frustration by providing incorrect or unclear guidance.

Knowledge Usage Analysis and Search Effectiveness

Knowledge is only valuable if people use it. We measure: knowledge usage rate (what percentage of support cases reference knowledge articles), article view trends (are popular articles stable or declining), search effectiveness (what percentage of searches find useful articles). Common findings: knowledge base is underutilized (support staff don’t search before calling expert), popular articles are concentrated in few topics (some knowledge exists, others don’t), search results are poor (searching for issue returns articles that don’t match). We also assess: accessibility (how easy is it to find articles), relevance (do articles returned by search match what user is looking for). We interview support staff: why don’t you use knowledge base, what would make it more useful. We assess: is knowledge base easy to use and find answers, or frustrating and abandoned.

Categorization and Navigation Optimization

Knowledge must be organized so users can find it. We assess: knowledge structure (what categories exist, are they logical), navigation (can users browse to relevant articles easily), taxonomy (are category names clear and consistent). Common findings: categories are poorly organized (articles are hard to locate), taxonomy is inconsistent (same topic categorized differently in different places), navigation is confusing (users don’t know where to start). We test navigation: users with problem search for articles, measure time to find relevant articles, measure success rate. Common issues: search query doesn’t match article keywords, categories have similar names, no clear structure guiding users. We assess: can users find articles when they need them, or is navigation a barrier to usage.

Contribution Workflow and Knowledge Creation Process

Knowledge must be created and maintained. We assess: who creates articles, how easy is contribution process, what motivates contribution. Common findings: contribution is burdensome (article creation requires skills users don’t have), contribution isn’t encouraged (knowledge management owns process but support staff feel disconnected), no incentive to contribute (creating documentation isn’t valued in performance reviews). We evaluate contribution process: does form ask for too much metadata, is approval workflow quick or does it delay publication, are contributors acknowledged. We assess: is knowledge management enabling staff to contribute easily, or creating barriers.

Knowledge Linking to Incidents and Service Requests

When support staff resolve issues, they can link knowledge articles so future requests reference that knowledge. We assess: are knowledge links being created during incident resolution, is linking quick and easy, do linked articles appear when new similar issues come in. Common findings: knowledge linking is optional and rarely done, linking requires separate workflow step, linked articles aren’t used to suggest solutions for new issues. We measure: link rate (what percentage of resolved incidents link to knowledge), search effectiveness (can system find relevant knowledge for new incidents). We assess: is knowledge being created from problem resolution experience or is that knowledge lost when support staff move on.

Knowledge Performance Metrics and Continuous Improvement

Knowledge health needs measurement. We establish metrics: knowledge base size, article usage rate, article accuracy, search success rate, time to find articles, contribution rate (articles created per month). We track trends: is usage growing, are new articles being created, is accuracy improving. We also track: first-contact resolution (do articles enable users to solve problems without escalation), support ticket volume (does better knowledge reduce support load). Common findings: metrics aren’t tracked (no visibility into knowledge effectiveness), metrics show declining knowledge usage (articles getting older, contributions slowing). We assess: is knowledge base growing and being used, or stagnating.

Categorization Scheme Improvements and Refactoring

As knowledge base grows, organization that worked initially becomes inefficient. We evaluate: should categories be reorganized, should some articles be merged (reducing duplicates), should taxonomy be simplified. Large refactoring can improve searchability but requires careful planning (moving articles might break existing links). We also recommend: pruning outdated articles (removing or archiving), consolidating overlapping articles, adding related article links. Refactoring is often valuable after knowledge base reaches 500+ articles or when usage analysis shows navigation problems.

Working out why a knowledge base has stopped being used

A knowledge base that people have stopped using usually declines in one of three ways, and each needs a different fix. The content may be wrong, so people tried an article once, found it failed and never returned. The content may be right but unfindable, so the search returns nothing useful and people ask a colleague. Or the content may be trusted and sound but simply absent for the topics that now generate most of the calls. A health check should separate these causes before recommending anything, because adding articles to a base that people cannot search is wasted effort.

The fastest way to tell them apart is the search log, not the article list. A search that returns no results points to missing content. A search that returns results followed by an immediate return to a ticket points to poor relevance or unhelpful content. A low view count on an article that ranks first for its topic points to a title or summary that does not match how people describe the problem. The measures worth following over time are in the knowledge management KPI guide.

Reading the search log in a fixed order

Search logs are noisy, so the reading order matters. Work through the steps below in sequence and write down the finding at each one before moving on, so that the conclusion rests on evidence rather than on the most memorable search term.

1. Export the search terms with their result counts and click activity for the review window, and drop single-occurrence terms that are clearly typing errors.
2. Group the remaining terms by topic and rank the topics by the number of searches that ended without a click.
3. For the top topics, check whether an article exists and, if it does, whether its title contains the words the searchers used.
4. Sample the articles for those topics and follow the steps on a clean account, noting any step that needed information the article did not give.
5. Compare the ticket volume for each topic with the number of times its article was viewed, to see whether the article is reaching the people who raise the ticket.

Duplicates, stale content and the cost of removing them

Duplicate articles are more harmful than they look. Two articles on the same procedure, written at different times, will eventually disagree, and the reader cannot tell which one reflects the current procedure. The health check should identify duplicate clusters and recommend which article becomes the single source, with the others archived and redirected. Removal needs care, because links from incident notes and old emails may point to articles that will disappear, so archive first and confirm that no active process depends on the old address. Common knowledge management mistakes are covered in the guide to knowledge management mistakes.

How do we check whether articles are accurate without reading all of them?

Sample by traffic, not by age. Pick the articles with the most views in the review window and follow their steps on a test account. Accuracy problems in heavily used articles do the most damage, so a short sample of those tells you more than a full read of the archive. A structured approach to checking accuracy is in the knowledge quality review guide.

Should we delete articles that get few views?

Not on view counts alone. A low-view article may cover a rare but serious procedure. Check whether the topic appears in the ticket history and whether the article is linked from any incident. Archive articles that have no views, no ticket link and no owner, and keep the rest under review.

Why are people using chat threads or colleagues instead of the knowledge base?

Because the base has failed them before or because the fastest answer is always a person nearby. The search log shows the first half of that story. Interviews with three or four frontline staff usually reveal the second half, and the fix is often a better summary at the top of each article rather than new content. Findability gets its own treatment in the guide to employee knowledge articles that get used.

What do we do with two articles that cover the same problem differently?

Decide which one reflects the current process, merge any useful content from the other into it, and archive the rest with a clear pointer. Ask the owner of the process to confirm the choice, because the knowledge lead is rarely the right person to decide which procedure is current.

When a health check will not solve the problem

If the base has no owner, the review will produce a list of findings that nobody acts on, and the usage problem will return within a cycle. If the platform search itself is misconfigured, no amount of content work will fix findability until the search is corrected. In both cases the first step is ownership or search configuration, and the review follows. When the findings call for a sustained change program, the knowledge management optimization service is the next step.

A search log is easier to read with someone who has done it before.