ServiceNow Knowledge Management: Guides and Services

What Knowledge Management Covers

Knowledge Management captures solutions and procedures that can be reused across the organisation. Articles describe how to handle common issues, implement procedures, or use platform features. By capturing knowledge once, the organisation avoids solving the same problem repeatedly and accelerates resolution for recurring issues.

Knowledge integration connects articles to incident workflows so support staff receive article recommendations while investigating. Articles are also used in self-service portals so customers can find solutions without contacting support. Over time, knowledge articles become the institutional memory of the organisation, documenting decisions, configurations, and lessons learned from incidents and projects.

Article Structure and Content Types

Knowledge articles should follow a consistent structure: a clear title describing the issue, a description of symptoms or when the article applies, step-by-step instructions or explanation, and any warnings or caveats. Articles should be written for the expected audience: technical articles for IT staff contain configuration details and command syntax, while non-technical articles for end users use plain language and screenshots.

Common article types include procedures (step-by-step instructions to accomplish a task), solutions (resolution to a known problem with troubleshooting steps), and explanations (background or context helpful for understanding a topic). Solution articles should include symptoms so people searching for help can find them. Procedure articles should include prerequisites so readers know whether they can follow the steps.

Knowledge Creation and Maintenance

Knowledge articles can be created from incident records. When an incident is resolved, support staff can create a knowledge article capturing the solution. This workflow ensures knowledge is created when expertise is fresh and captures real solutions to real problems. Articles created this way are tagged with the incident type so related incidents can find the article.

Articles need regular review to ensure they are still accurate and relevant. Obsolete articles should be retired so users don’t follow outdated procedures. Articles that reference old versions of software or policies should be updated. A knowledge review schedule ensures articles remain reliable. Some organisations track article usage and prioritise review of the most-used articles because errors there have the highest impact.

Search and Article Discovery

Users discover articles through search and browsing. Search should be optimised so users find relevant articles using natural language terms. Search can include filtering by category, product, or severity so results are focused and users don’t wade through irrelevant articles. Search algorithm improvements often drive adoption: if search doesn’t find articles users need, they won’t trust the knowledge base.

Categorisation helps users browse articles by topic. A well-organised knowledge base with clear categories helps users find solutions when they don’t know the exact keyword to search for. Category structure should match how users think about problems, not how the support organisation thinks about them.

Knowledge Integration With Incident Management

When an incident handler is working on a ticket, knowledge search can be triggered automatically or manually. Relevant articles are recommended based on keywords in the incident description or category of the incident. Articles can be linked to incidents so customers can self-serve while waiting for support or verify support recommendations by reading the article themselves. This builds confidence that the support recommendation is sound.

Self-Service Knowledge Portal

End users can access a self-service knowledge portal to find solutions without creating support tickets. Portal articles are written for non-technical users and include screenshots, links to related articles, and feedback mechanisms so users can report if an article was helpful or needs updating. Portal access reduces support volume by allowing users to self-serve for common questions.

Portal analytics show which articles are most commonly viewed, which articles have high feedback ratings indicating user satisfaction, and which searches produce no results, indicating knowledge gaps that need new articles. Popular searches that don’t find articles identify priorities for new content creation.

Knowledge Analytics and Improvement

Analytics track how much support load is reduced by knowledge reuse. If an article about password reset is used in 100 incidents, that represents 100 support interactions that were faster or prevented entirely because the user self-served. Analytics also show which articles are viewed most frequently, indicating knowledge priorities, and which articles have highest satisfaction ratings, indicating effective content.

Oblytech’s Knowledge Management Services

We help organisations plan a knowledge strategy aligned to business priorities, design article structure and categorisation for discoverability, and establish workflows for article creation and maintenance. Implementation includes bulk migration of existing documentation, training for staff who will create and maintain articles, and configuration of knowledge search and self-service portals. Consulting also addresses how to promote knowledge adoption among support teams and measure its effectiveness in reducing support effort.

Decide who the knowledge base is for before deciding what goes in it

A knowledge base serves several readers at once, and each one needs a different kind of answer. A service desk agent on a live call needs the fastest route to a verified fix. An employee searching from a laptop needs plain steps that avoid internal jargon. A specialist engineer needs the configuration detail and the reasoning behind it. When these readers share one set of articles, the result is often articles that are too long for the agent, too technical for the employee and too thin for the specialist. Name the primary reader for each knowledge base or category first, and let that choice set the tone, length and level of detail of every article inside it.

This decision also determines the search experience. A category written for specialists needs search terms the specialists actually use, which may be product codes or error strings, while an employee category needs the words people type when something is broken. Mixing the two in one index tends to bury both.

Matching article types to readers and channels

A type that fits none of these rows often means the article is trying to do two jobs. Split it, and link the halves to each other.

Editorial workflow from draft to retirement

1. Create the draft from a resolved incident or a request, and keep the original ticket linked so the source can be checked.
2. Route the draft to someone outside the authoring team, with a note on audience and intended search terms.
3. Publish to the audience the article was written for, and no wider without a decision.
4. Record the review date and the owner at publication, so the review task exists from the first day.
5. When a review finds the article is wrong or unused, update it, merge it or retire it, and record which one was chosen and why.

Launch checklist for a first knowledge base

• Each knowledge base has a single primary audience written in the description.
• Article owners are named people or teams, and each has time allocated to review their articles.
• The first set of articles covers the incidents that generate the most repeat contacts, not the subjects that are easiest to write.
• Search has been tested with the terms people actually type, collected from the service desk over a recent period.
• Access to each knowledge base has been checked against the groups that exist today, not the groups from an earlier structure.

Signs the knowledge base is earning its place

A knowledge base earns its place when agents reach for it before they escalate, when repeat contacts about a documented fault fall, and when article feedback leads to edits rather than being ignored. Read those signals together. High article views on a page that users rate poorly point to a search or wording problem, while a page nobody opens may simply cover a subject that no longer generates contacts.

When knowledge management is the wrong first project

Knowledge management should wait when the processes it documents are still changing every month, because the articles can be wrong soon after they are published. It should also wait when there is no named owner for the subject, and when the incident categories are too inconsistent to link articles to anything. In those cases, fixing the process or the categories first produces a better knowledge base later. The knowledge governance guide covers the ownership questions that have to be answered before publication begins.

Questions readers ask before they commit

Should every resolved incident produce an article?

No. Produce one when the fix was non-obvious, when the same fault is likely to recur, or when the steps would help someone who cannot raise a ticket. A routine reset that every agent already knows does not need an article, and a long list of them dilutes the results that matter.

How should a region-specific fix be handled?

Write the article for the region and say so in the title or the first sentence. Merging regional differences into one article with conditional steps tends to confuse readers who only need one branch.

Is a knowledge base the same as an FAQ?

Not quite. An FAQ answers a list of common questions in one place. A knowledge base holds articles with owners, review dates, versions and links to the incidents and requests they support. The FAQ can be built from the knowledge base, but it does not replace it.

Can articles be translated and kept in step?

They can, but each translation needs its own owner and review, and the link between the source and the translated version has to be maintained. Without that link, a corrected source article can leave its translations quietly out of date.

Next step

The knowledge base management service describes the run phase after launch, and the governance model guide covers who approves changes.