OBLYTECH Logo
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Knowledge Quality: Review Accuracy and Usefulness

ServiceNow knowledge quality depends on whether an article performs its intended job for its intended audience. Review should cover accuracy, scope, access, findability, actionability, evidence, feedback, freshness, ownership, and the decision to update, retain, or retire.

For knowledge owners checking whether published ServiceNow guidance is accurate, useful, findable, and within scope..

ServiceNow knowledge qualityarticle qualityknowledge review

Guide map

Judging articles on accuracy and whether readers use them

Define quality for the article’s job

An article is good when its reader can finish a task with it, so judge it against that task instead of against a general style checklist.

Check accuracy, scope, and audience

Check each article against the current process and the people who will read it, since accurate content aimed at the wrong audience still fails.

Review findability, access, and actionability

Search for each article the way a support agent would under time pressure, and note whether the answer is visible in the first screen of results.

The practical framework

Review ServiceNow knowledge quality for accuracy, scope, audience, findability, access, evidence, feedback, ownership, freshness, and actionability.

Define quality for the article’s job

State whether the article answers a question, guides a procedure, supports an incident, explains a service, or directs a request. Quality criteria should match the job; a concise answer and a detailed procedure do not need identical structure.

The ServiceNow knowledge-management route is the relevant internal destination when quality rules need governance.

Check accuracy, scope, and audience

Review steps, prerequisites, exceptions, service boundary, terminology, owner, evidence, and audience. Confirm that the article does not claim more than the process or service supports.

The ServiceNow service-owner route provides an internal path when process meaning needs owner confirmation.

Review findability, access, and actionability

Check title, headings, search terms, links, access, next action, expected result, and escalation. An accurate article can still fail if users cannot find it or do not know what to do next.

The ServiceNow portal-search route is relevant when findability affects use.

Use feedback and freshness evidence

Review failed use, questions, reported errors, process changes, incidents, releases, and review dates. Distinguish feedback about wording from evidence that the underlying process changed.

The ServiceNow continuous-improvement route supports follow-up.

Assign correction, update, or retirement

Record the finding, consequence, owner, action, evidence, due date, and decision. Retire content when it cannot be made safe or current, and provide a current route where appropriate.

The ServiceNow change-management route gives an internal path when a service or process change affects content.

Common questions

Questions teams ask about knowledge quality

Is a well-written article necessarily useful?

No. It must also be accurate, within scope, findable, accessible, actionable, current, and owned by someone who can correct it.

What should a quality review record?

It should record the article job, audience, finding, evidence, consequence, owner, action, decision, review date, and any replacement or retirement path.

The research-grounded boundary

Treat ServiceNow knowledge quality as a governed operation. Define the trigger for review, the permitted action, the human checkpoint, the failure signal, and the record that closes the loop. For knowledge quality review, the practical safeguard is to make the dependency visible before the team treats the workflow as complete. Until that record exists, the review is not finished.

Start the review from the search log, not the article list

An article list tells you what exists. The search log tells you what people tried to find and whether they found it. A review that starts from the list tends to spend its time on articles nobody reads, because they are easy to open and easy to tidy. Pull the last period of search terms with no result or with a click and no resolution, group them, and let those groups set the review order.

Once the groups are set, the review question for each article changes. It is no longer “is this procedure good?” It becomes “does the procedure answer the search that failed, and if not, what does it need to say?” That question has a concrete answer, and it stops the review becoming a general editing exercise.

A review cycle in order

  1. Assign each article to a named owner who can change it and who knows the process it describes.
  2. Test the procedure from start to finish on the current platform, using the steps as written and noting any step that no longer matches the screen.
  3. Read the title and the first paragraph as a user would, and confirm the search terms in the log appear in language the user would recognize.
  4. Record one of three decisions: keep, update with a stated change, or retire with a pointer to the replacement.

What each finding should trigger

Findings differ in how urgent they are and who must act. The table sets out the usual response, so that a reviewer does not invent a new process for each article.

FindingWhat it usually meansResponse
A step no longer matches the screenThe process or the interface changedUpdate the steps and confirm with the process owner
Users search for the topic but the article is not returnedThe title or keywords use internal termsRetitle and add the search phrasing users actually use
Article is accurate but users still open a caseThe article lacks the decision point or the escalation routeAdd the branch the user is stuck on and the next action
Process was retired or replacedThe article describes something no longer offeredRetire it and point to the current route

Where knowledge reviews go wrong

A common mistake is editing for style. A review that tightens sentences but leaves a wrong approval path in place has improved the reading experience and left the risk untouched. Put accuracy and the next action ahead of wording, and treat style changes as a separate, lower-priority pass.

The second mistake is keeping articles alive out of caution. An outdated procedure that people still follow is more dangerous than no article, because it looks authoritative. When an article cannot be made current quickly, retire it, and say so in the replacement article so that the search history connects the two.

The third mistake is treating a single complaint as a verdict. One user who misread a step is a reason to check the step, not a reason to rewrite the article. Look for the same finding across several cases before changing the content.

Keeping the review honest over time

Record each decision with the finding, the owner and the date it was made. When the same article returns in a later review, the history shows whether earlier changes held. The guide to the knowledge article lifecycle looks at how an article moves from purpose and drafting through review, expiry and retirement, and the guide to employee knowledge articles that get used looks at titles that match the question and steps that match the service path.

Questions about running the review

Should the process owner or the knowledge team sign off changes?

The process owner confirms that the content is correct. The knowledge team confirms that it is written, titled and placed so that users can find and follow it. Both sign-offs are needed for a change to the procedure itself.

How should articles with almost no views be handled?

Check whether the topic is rare or whether nobody can find it. A rarely needed procedure may be correct and simply specialized. An article that nobody finds because of its title needs the title fixed, not retirement.

What if the process changed but the article is still accurate for the old version?

Mark the article with the condition under which it applies, and set a decision date for the retire-or-update choice. Leaving both versions live without a condition creates the confusion the review was meant to remove.

Who should review knowledge written by another team?

The owning team should review its own content, with the knowledge team checking structure and findability. Reviews done by a team that does not run the process can approve text they cannot test.

A practical next step

If your knowledge base has articles that people open and still raise cases about, check them against the search log and the findings above before rewriting content. The knowledge base management page describes building, maintaining and optimizing a knowledge base, and the knowledge and self-service optimization page looks at connecting real questions to clear articles.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog