Common ServiceNow Knowledge Management Mistakes and How to Avoid Them

This guide helps a knowledge manager decide which common ServiceNow knowledge mistakes are hurting their own knowledge base, and what to fix first. Each mistake is set out with its symptom, its root cause and the fix that addresses it, and the audit section shows how to test which ones apply.

Mistake: Publishing Articles That Quickly Become Stale

Symptom: Articles are created and published with high confidence, but within months they contain outdated information. Employees rely on old articles and receive incorrect instructions. Trust in the knowledge base erodes and employees stop searching.

Root cause: The organisation did not establish a clear ownership model for articles. When a policy changes, nobody is responsible for updating the related articles. Articles are created without documentation of who owns them or when they should be reviewed.

Fix: Assign each article to an owner (usually someone from the team that manages the topic). Document the review cycle (quarterly, annual) in the article metadata. Configure a calendar reminder so the owner knows when their articles are due for review. A stale article is worse than no article.

Mistake: Articles That Exist But Are Never Found

Symptom: Articles are published and appear to cover important topics, but employees never find them because search results are poor. Employees phrase their question differently than the article’s keywords, so the search does not return a match.

Root cause: Articles are written from an IT perspective using technical terms. An employee asking ‘Why is my email slow?’ will not find an article titled ‘Optimizing Outlook Performance’. Articles are not tagged or categorized for discoverability.

Fix: Write articles from the user perspective: titles and first paragraphs should answer the question an employee might ask, not just describe the technical detail. Tag articles with common synonyms: ‘slow email’ is tagged ‘performance’, ‘latency’, ‘delays’. Test search with actual users to find keyword mismatches. A/B test article titles to see which versions have higher click-through rates in search.

Mistake: Knowledge That Is Not Used in Incident Resolution

Symptom: A knowledge base exists with hundreds of articles, but support staff rarely link them to incidents or requests. Employees and support staff continue to call for help instead of searching knowledge first.

Root cause: Support staff were not trained on the knowledge base. Incidents are resolved quickly and staff do not take time to search for related knowledge. The knowledge base is not integrated into the incident workflow, so staff do not see recommendations.

Fix: Train support staff on navigating the knowledge base and on culture expectation: every incident should be resolved with at least one knowledge article, either as a solution or as context. Configure ServiceNow to suggest relevant knowledge articles when an incident is created. Measure incident resolution time with knowledge vs. without, and share results with staff to show the value.

Mistake: Access Control That Prevents Employees From Finding Answers

Symptom: Articles are marked ‘Internal Only’ and are not visible to employees who need them. Articles intended for a specific department are restricted to an old security group that no longer has active members. Employees cannot find help because knowledge is hidden from them.

Root cause: Knowledge was created for an internal IT team but should have been published to the employee audience. Access control rules were set once and never reviewed when groups or roles changed. Articles were restricted defensively to ‘limit access’ without clear justification.

Fix: Decide upfront whether each article is for employees, for IT staff, or for both. Review access control quarterly and update restrictions when groups or roles change. Remove unnecessary restrictions—articles should be visible to whoever has the need to know.

Mistake: Knowledge Without Metrics or Feedback

Symptom: Managers cannot tell whether the knowledge base is valuable. Articles are published but there is no data on how many people read them or whether they were helpful. When budget cuts occur, the knowledge investment is questioned and defunded.

Root cause: Knowledge was created without establishing success metrics. The article views and ratings the platform already records were not reviewed. The organisation has no process to measure which articles are used and which are gathering dust.

Fix: Configure article ratings and comments. Track article views and identify popular articles and gaps. Build a dashboard showing top articles, articles with low ratings, and trends over time. Share metrics with stakeholders monthly so the value of knowledge is visible.

Mistake: Generic Articles That Could Apply to Any Organisation

Symptom: Articles are published with generic content (‘Password Reset Process’, ‘Request a Device’) that provides no specific, actionable guidance for the organisation’s particular setup. Employees read the article, do not find their answer and call for help anyway.

Root cause: Articles were written to be ‘process neutral’ and to apply across teams. Specific details (team names, department codes, timelines) were left out to keep articles abstract.

Fix: Include specific, concrete details in articles: real team names, specific timelines, examples with real scenarios. If details vary by department or location, create separate articles per department rather than one generic article. An article that applies to ‘everyone’ often helps ‘no one’.

Prevention Checklist

• Every article has an owner with clear responsibility for keeping it current
• Articles are written from the user’s perspective, not IT’s terminology
• Articles are tagged and categorized so they are discoverable via search
• Support staff are trained on knowledge and expected to link articles to incidents
• Access control is reviewed quarterly and unnecessary restrictions are removed
• Metrics (views, ratings, helpfulness) are tracked and reviewed monthly
• Articles contain specific details and examples relevant to your organisation

Auditing a knowledge base that is already failing

Many teams who read a list of knowledge mistakes already have some of them. The more useful question is which ones are hurting the base now. An audit answers that without a large project. Pull the articles viewed in the last period, the searches that returned nothing, and the articles agents attached to incidents in the same window. Then read the top twenty articles by use and the twenty most-searched terms with no clicked result. Those two lists show where the knowledge base is working and where it is letting people down, and they often point to two or three mistakes rather than all of them. If the audit shows that articles are not being attached to incidents at all, the note on knowledge deflection and incident resolution covers when articles help an agent resolve an incident faster.

Keep the audit to a short written finding per article: still correct, needs an edit, needs a merge, or retire. Keep the knowledge management guides in mind when you decide where a merged article should live. Avoid rewriting during the audit. Rewriting before deciding is how a clean-up turns into a rewrite project that never ends.

Structural mistakes that hide the fix

Some articles are correct but unfindable because the fix sits too far down the page. A reader who opens an article about a printing fault and scrolls past three paragraphs of background will often give up and log a ticket. Move the symptom and the one-line fix to the top, and move the explanation below it. A second structural problem is the article that covers two faults in one piece, where each reader has to work out which half applies. Split those, and link them from a shared parent. A third is a procedure with no stated prerequisites, so the reader discovers halfway through that they lack the access needed to complete it.

Ownership gaps that appear when staff move

Ownership often fails at the point a person changes role, not at the point an article is written. The author leaves, the team is restructured, and the articles stay live with an owner who no longer has the context to check them. This is a mistake that often surfaces during an audit. Before the next staffing change, export the list of articles by owner, reassign each group of articles to a named successor, and check that the successor has the access to edit them. An article with an owner who has left should be treated as unreviewed, however recent its last edit. The article lifecycle guide covers the stages an article moves through, including ownership.

Symptom to mistake: a first-check table

Clean-up sequence for the first quarter

1. Freeze new article creation in the affected categories for the duration of the audit, so the baseline does not move under you.
2. Assign an owner to every article that lacks one, and retire articles whose owner cannot be identified after one request.
3. Fix access on the restricted articles that are used most, since these are the cases where the knowledge is already doing damage.
4. Merge duplicates, keeping the version with the higher use and the better rating, and redirect the other.
5. Rewrite only the articles that the audit placed in the edit category, and retest their search terms afterwards.
6. Record the audit date and the findings, so the next audit can show what changed.

Questions about recovering a neglected knowledge base

Should old articles that nobody reads be deleted?

Retire them rather than delete them where possible. A retired article drops out of search and keeps its history, which helps if an older system or an audit still refers to it. Deletion is harder to undo and gives no benefit that retirement does not already provide.

How do we stop duplicates from returning?

Make the author search the existing articles by the symptom and by the fix before creating one, and require a reviewer to confirm that no close match exists. Duplicates often appear when authors cannot find the original, so search quality is the real control.

Why do authors keep writing very long articles?

Long articles are often a sign that the author is documenting everything they knew about a subject rather than the one task a reader came for. Give the author a template with a short required summary and a limit on the number of steps per article, and move the background into a linked explanation.

Is it safe to retire articles during a staffing change?

Only after the articles have been reviewed by their successor or by a subject matter expert. Retiring during a handover can remove the only correct version of a procedure that is still in use, so the handover checklist should include the knowledge base as an item.

Next step

The knowledge quality review guide covers what each review should check.