A well-structured and accessible knowledge base is a critical asset for any organization utilizing ServiceNow. It can give users self-service options, help reduce support ticket volume, and support collaboration across teams. Oblytech’s Knowledge Base Management services help you build, maintain, and optimize your ServiceNow knowledge base, so users can find the information they need when they need it.
A service desk manager considering knowledge base work is rarely short of articles. The more common problem is that a large share of the existing articles are out of date, duplicated or written for a different version of the process, and the team no longer trusts the search results enough to send users there. Before any investment goes into writing, the first question is whether the current content helps or hinders. An article that a user finds and follows correctly is an asset. An article that sends the user down a wrong path produces a second ticket, and it trains the user to skip the knowledge base next time. The audit that answers this question does not need to be exhaustive. It needs to show which articles are being opened, which searches return nothing useful, and which articles are followed by a ticket on the same topic within a short period.
Those three signals are usually enough to make the case for either pruning or building. A high volume of unused articles points to a retirement exercise. A high volume of searches with no result points to missing content. A high rate of tickets raised shortly after an article is read points to content that is accurate in parts but not sufficient to finish the task.
Prioritizing content by intuition produces a library that reflects whoever was most vocal in the last meeting. A better order starts from the demand the service desk already records. The table below shows how common candidates compare when the purpose is reducing avoidable contact rather than covering every topic.
| Candidate topic | Evidence to check | Why it ranks | Typical action |
|---|---|---|---|
| A question asked repeatedly on the same channel | Frequency in the service desk log and the wording used by requesters | Each answer given by hand is a cost that a good article can remove | Write a short article that answers the question in the requester’s words |
| A search that returns no relevant result | Search terms with no clicked result over a set period | Shows content the users expected to find and could not | Create the article, then check the title matches the search wording |
| A procedure that has changed in the platform | Articles that predate the last change to the related form or workflow | Wrong steps can be more damaging than missing steps | Revise or retire before adding anything new |
| A topic with several overlapping articles | Two or more articles with similar titles and close search results | Duplicates can split traffic and disagree over time | Merge into one authoritative article and redirect the others |
The order that emerges from this kind of review is rarely the order anyone planned at the start. That is a sign the method is working. The ranking should be revisited after each batch, because a successful article removes a topic from the top of the list and exposes the next one.
The person reading a knowledge article is usually trying to finish something, and often has a deadline or a frustration attached to the task. That reader benefits from a structure that puts the answer where the eye lands first. A title that states the problem in the words a requester would use, followed by a sentence that confirms the article applies, is more useful than a title that names an internal feature. Prerequisites should come next, so that a user who lacks access or a required field learns that before reaching step three. Steps should be short and in the order the user performs them. Each article should end with what to do if the steps fail, including the point at which the user should raise a request and what information to include, so that the request arrives complete.
Writing for this reader is different from writing documentation for administrators, and the two should not be mixed. Administrative detail, such as how a rule is configured, belongs in internal records. The user-facing article should describe what the user sees and what the user can do.
Articles often decay for a simple reason. They are written by someone who then moves to other work, and nobody is responsible for noticing when the underlying process changes. The fix is an owner recorded against each article, a review date set according to how often the process changes, and a retirement rule that applies when an owner does not respond. Retirement should be a normal, visible action. A library that keeps every article forever becomes harder to search, and the search results it produces are the first thing users judge it by.
Ownership also has to be shared with subject experts who know the process. Service desk analysts see the questions. The people who run the process know the exceptions. An article written from the service desk view alone often misses the case that causes the most trouble, and an article written from the process view alone often uses language no requester would recognize.
Ticket deflection is a measure that is often promised and less often demonstrated. A user who reads an article and then does not raise a ticket may have solved the problem, or may have given up, or may have raised the request through another route. A useful approach is to compare the volume of tickets on a topic before and after an article is published, while checking whether the article was viewed by people who went on to raise a ticket anyway. Where the numbers are small, look at the qualitative signals instead: whether the tickets that still arrive mention the article, and whether the agents who handle them can point users to it.
Feedback on each article is worth collecting, but a simple helpful or not helpful prompt is only a starting point. The comments that follow a negative vote usually identify the missing step, and those comments are the most reliable source of the next revision.
A knowledge base is a support tool, not a repair for a poor process or a weak product. If a request form is confusing because it asks for information the requester cannot know, an article can explain the form but the better answer is to change the form. If the process requires approvals that take too long, an article can set expectations but cannot shorten the approval. If users cannot reach the content because they lack the right access, the content is invisible to exactly the people who need it. These cases should be raised as process or configuration issues, because writing around them only moves the cost to the reader.
A selective migration is usually better than either extreme. Move the articles that still match the current process and have recent use. Retire the rest, and write new articles only for topics that the audit shows are needed. Migrating everything preserves the problems along with the content.
Both should contribute, for different parts of the article. Agents are best placed to write the question and the wording a requester uses. Subject experts are best placed to confirm the steps and the exceptions. An article reviewed by only one of them usually has a visible gap.
Restricted content should sit behind the access controls the platform already applies, not in an open article with a warning attached. Where a procedure can be described publicly in general terms, write that version for requesters and keep the restricted detail in the internal record.
Assign ownership by topic, not by author, and check for an existing article before a new one is created. A short review step at creation catches most duplicates before they are published.
If the knowledge base is already in use but no one is confident in it, an audit of the three signals described above, followed by an agreed list of articles to keep, fix and retire, is the place to start. Discuss your knowledge base requirements and bring what those three signals show. For the platform definition of a knowledge article, the guide to knowledge articles is a useful reference, and the HR knowledge governance model guide describes assigning an owner to each knowledge article who is responsible for verifying its content, in an HR setting, and the same idea can be applied elsewhere.
Run one knowledge base per audience and ownership boundary, not one per department or one for everything. In most implementations that means a small number of bases, each with a named owner, a clear reader group and its own rules for who may publish.
The reason is practical. Access to articles is typically controlled at the knowledge base level, so the base is the unit where you decide who can read, who can contribute and who must approve. If staff-only procedures sit in the same base as requester guidance, you end up hiding things article by article, and one mistake exposes the wrong page.
Too many bases cause their own trouble. Search has to cross all of them, owners multiply, and nobody can say which one holds the answer. If you cannot name the owner and the reader group for a base in one sentence, it probably should not exist yet.
A common mistake is copying the organisation chart into the structure. Requesters do not know which department owns their problem, so they search by symptom. Categories should follow the tasks people try to finish, while bases follow audience and approval.
Another mistake is leaving the structure unreviewed after a merger of teams or a platform change. Check each base against the three signals the audit earlier on this page describes: what is opened, what is searched without result, and what is followed by a ticket. A base that scores poorly on all three is a candidate for merging or retirement.
Once the structure is settled, the portal and search settings decide how well it works for readers. The guide to knowledge and self-service optimization covers that side, and employee center self-service shows how articles reach staff. If you plan to let a chat assistant draw on the same articles, see virtual agent self-service, because it mostly draws on what the base contains.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.