ServiceNow Knowledge Management Best Practices

Knowledge management best practice is the set of habits that keep knowledge articles accurate, findable and used by the people who resolve incidents. This page covers when to write articles, who owns them, how to keep them current, how to link them to incidents and changes, and how to measure whether they help.

Practice 1: Create Knowledge Before You Need It

Start writing knowledge articles early in your platform lifecycle, not after months of operation. By the time your system is stable, you have resolved the same issue multiple times. Document the solution the first time you resolve it, not the hundredth. This prevents knowledge from being scattered across email and team members’ heads. Fresh knowledge is also more accurate because the resolution is recent and the author remembers details.

For Incident Management and Change Enablement, create knowledge for common issues and common change patterns as you encounter them. Link the knowledge to relevant incidents or changes. This establishes the habit and builds a knowledge base that grows with your operational experience.

Practice 2: Write for Your Audience, Not for Yourself

Knowledge articles should be understandable by the person who needs them. If an article is intended for support staff who are new to the role, explain concepts and avoid jargon. If it is intended for experienced technicians, you can assume more background knowledge. Before publishing, have someone from the target audience read the article and verify they understand it. Rewrite sections that confuse them.

Use clear headings, short paragraphs, and step-by-step instructions for procedures. Avoid walls of text. Use lists and tables where they clarify information. Include screenshots or examples where they help. The goal is that the reader understands without having to read between the lines or ask for clarification.

Practice 3: Keep Knowledge Current or Mark It Outdated

Outdated knowledge is worse than no knowledge. If an article describes a process that has changed, either update it or mark it as outdated so readers know not to follow it. Assign ownership of knowledge articles to individuals or teams. They are responsible for reviewing their articles periodically and updating them when processes change. Set a review cycle—at least annually—where owners verify their articles are still correct.

Version knowledge articles. When you update an article because a process changed, note the date and the change. Include a summary of what changed. This helps readers understand what is new and why their previous understanding might be incomplete.

Practice 4: Link Knowledge to Incidents and Changes

When you resolve an incident, link it to relevant knowledge articles. When a change is implemented, link it to knowledge about the new feature or change. These links help support staff find knowledge when they are working on incidents. They also help authors understand how popular their articles are. Track which articles are used frequently and which are never referenced. Popular articles are working well. Unused articles should be retired or merged into other articles.

Similarly, link related articles to each other. If article A describes a concept and article B describes the procedure based on that concept, link them. This helps readers find related information without searching.

Practice 5: Measure and Improve Knowledge Quality

Track metrics for your knowledge base. How many articles do you have? How many are accessed per month? How long do people spend reading? If an article is accessed frequently, it is valuable. If it is accessed rarely, consider whether it is still relevant. Ask support staff whether knowledge is helping them or whether they need different information. Use this feedback to improve your knowledge.

Also measure the impact on incident handling. When you first publish knowledge about a common problem, track whether incidents for that problem decrease. If they do, the knowledge is valuable. If they do not, ask why. Is the knowledge hard to find? Is it not being used? Does it not address the real problem?

Practice 6: Use Categories and Searches Effectively

Organize knowledge in a way that helps people find it. Use categories that match how people think about your services. If you have categories for each service or system, people can find knowledge about the systems they support. Use consistent naming for categories so people can predict where information is. Tags and keywords improve discoverability; use them consistently.

Make search easy and relevant. Ensure that when someone searches for a common term, they find the right article. Test your search with typical questions your support team receives and verify they find the answer.

Practice 7: Control Who Can Create Knowledge

Allow subject matter experts and experienced staff to create knowledge, but require review before articles are published. Anyone should be able to suggest improvements to existing articles. New articles should be reviewed by a knowledge manager or senior team member before going live. This prevents poor-quality or incorrect articles from being published.

Create templates and guidelines for knowledge authors. A consistent format makes knowledge easier to use. A template with prompts helps new authors know what to include. Guidelines on quality standards ensure articles meet your organization’s expectations.

Habits that depend on people more than on the tool

Many knowledge base practices fail for social reasons before they fail for technical ones. An agent who has been told to link articles but is measured only on handle time will skip the link. A reviewer who is never thanked for catching an error will stop catching them. The practices that hold over time are the ones that are built into daily work: the link is part of the closing step, the review is part of the author’s calendar, and the correction is recorded where the team can see it. When you design a practice, ask where it sits in someone’s existing day, and who notices when it is skipped.

A practice that can only be followed by one or two experts may not survive their holidays. Write each practice so that a capable colleague who did not design it can carry it out from the page alone.

Split or merge: a decision table

Situation	Often better	Why
Two articles describe the same fix for different products	Keep separate, cross-link	The steps differ, and merged steps confuse both readers
Two articles describe the same fault in different words	Merge, keep the better title	Duplicates split the feedback and dilute search
One article covers a fault and its long background	Split the background out	Agents need the fix, and the background is only for curious readers
An article is correct but used by almost nobody	Review the audience first	Low use can mean a wrong audience or a wrong title, not a wrong article

A weekly editorial rhythm that holds

A workable rhythm for a small team is one short weekly slot for each of three jobs. The first looks at new articles awaiting review and clears them against a written standard. The second looks at the feedback and search-gap report and picks two or three items to act on, rather than trying to fix everything. The third checks that the articles due for review this month have owners who have started. Keeping the slot short and recurring matters more than the length of any single session, because the backlog never clears in one long meeting and does not need to.

Checklist for a new knowledge author

• Search for an existing article on the same fault before starting, and note any near-matches in the draft.
• Write the title as the question or symptom a reader would type, not as the name of the system component.
• Put the fix or the first action in the first screen, with prerequisites above the steps.
• Name yourself as owner, and set the review date before submitting.
• Ask one person from the intended audience to follow the steps without help, and record what they got stuck on.

Signs a practice is not holding

A practice that has stopped working often shows up as a process that continues on paper. Reviews are logged as complete on the day they were due but the articles are unchanged. Links to articles are present on incidents but the articles are not opened. Corrections are made in the article but not recorded in any place where a manager would see them. When you spot a pattern like this, do not add a new control. Ask the person who does the work what stops them from doing it properly, and fix that obstacle first.

Practices worth dropping

Some widely recommended habits cost more than they return for many teams. Rating every article every quarter, whatever its use, produces a large amount of low-value review. Requiring a full sign-off chain for a one-line correction discourages people from making the correction at all. And building a dashboard before the team has agreed what a good article looks like gives people a number to chase without a standard to aim at. Drop those, or defer them until the basics are working.

Questions about keeping good habits going

Is there a right length for an article?

The right length is whatever lets a reader finish the task the article names, and no more. A procedure that needs twenty steps may be right at that length, but a background explanation included in the same article makes the procedure harder to find. Measure length by how quickly a new reader finds the step they need, not by a word count.

Who decides when two articles overlap?

The owner of the category, after a short review with the owners of both articles. If the owners disagree, the decision goes to the knowledge lead, who records the reason. Leaving overlaps unresolved is a common way duplicates grow.

What do we do with a correct article that nobody reads?

Check its title and its audience before anything else. A correct article that does not appear in search for its own subject has a findability problem. An article that appears in search and still gets no clicks may simply cover a fault that has stopped happening, and retiring it is a reasonable outcome.

Do we need a style guide before the first article?

A short one is useful, covering the title pattern, the required summary, how steps are numbered and where screenshots go. A long style guide that nobody reads does less good than a one-page template that every author opens.

Next step

Search quality, the other half of this problem, is discussed in the findability note for employee articles. The roles behind these routines are described in the knowledge roles guide.

ServiceNow knowledge base structure: knowledge bases, categories and access

Structure a ServiceNow knowledge base by audience first, then by topic. Each knowledge base should hold articles for one audience under one owner, categories should group articles by the question a reader asks, and access should follow the reader rather than the author’s team. Splitting by department usually hides answers from the people who need them.

A knowledge base is the container that carries ownership, publishing rules and who may read or contribute. A category is only a label inside it, used for browsing and filtering. Teams often create a new knowledge base to fix a browsing problem, then find that a category would have done and that they now maintain two places.

Audience	Typical contents	Decision to make
Employees using self-service	How-to answers and policy summaries	Which topics are safe to show everyone
Service desk agents	Fault resolutions and call scripts	Whether employees may also read them
Specialist support teams	Diagnostics and workarounds	Who reviews before publishing
Customers or partners, where relevant	Product guidance	Which articles are public and which need sign-in

Name categories after the symptom or task a reader would search for, and keep the tree shallow enough that no article sits many clicks down. Deep trees tend to copy the organisation chart, and readers do not know the organisation chart.

Give each knowledge base a named owner and each article an author and a valid-to date, so that expiry sends an article back for review instead of leaving it live. The knowledge management governance model explains who should hold those roles, and the knowledge article explainer covers the fields an article carries. If your structure already exists and is not working, the knowledge and self-service optimization service reviews it against how people actually search.

How many knowledge bases does a company need?

Usually as many as it has audiences with different access rules, and no more. Many mid-sized organisations do well with a handful. Add another only when a group needs different read or publish permissions, not to hold a different subject.

Should categories mirror the organisation chart?

No. Teams reorganise, and readers search by symptom or task. Categories named after the questions people ask survive a restructure, while categories named after departments need rebuilding each time and send readers to the wrong place.

What is the difference between a knowledge base and a category?

A knowledge base is a container with its own owner, publishing workflow and access rules. A category is a label inside it that helps readers browse and filter. Use a knowledge base to control who can do what, and a category to help people find things.

How to Structure a ServiceNow Knowledge Base: Reader First, Then Access, Then Categories

Structure a ServiceNow knowledge base by making three decisions in order: who reads the articles, who may see or change them, and how readers name their problems. Many teams reverse this. They build one knowledge base per department, fill the categories with internal vocabulary, and later find that an agent in another group needs the same fix under a different name.

Start with the reader. Pick the two or three groups who search most, such as service desk agents, field technicians and portal users, and write down what each group types when something breaks. Those phrases become titles and category names. A project name or a team’s own label rarely matches how a caller describes a fault.

Next, decide whether you need more than one knowledge base. A second one is justified when access or publishing rules genuinely differ, such as restricted security procedures, or material published to end users while internal notes stay hidden. Otherwise one knowledge base with clear categories is easier to search and keep current.

Then build categories from the reader’s problem. Keep the top level short enough to choose a branch in seconds, and in most implementations two levels of depth are enough. Give each category a named owner who can state in one sentence what belongs there. That sentence is also the test for new articles.

• Map the readers and the phrases they type before naming anything
• Create a second knowledge base only where access or publishing rules differ
• Group categories by the problem the reader is solving
• Give each category one owner and a one-sentence scope

The failure to watch for is a structure that looks tidy on the admin screen but returns nothing when an agent searches. Test it with phrases from closed incidents before building it out, and confirm the settings on your own instance and release, since labels vary between versions.

If an existing structure has grown this way, the ServiceNow knowledge management consulting page is one route into a restructuring review. For the ownership side, the knowledge management governance model deals with who approves new categories and who retires old ones. Readers who arrive through the portal need the design covered in knowledge and self-service optimisation.