OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow knowledge practice

ServiceNow knowledge and self-service optimization with useful next steps

ServiceNow knowledge and self-service optimization is useful when a person finds accurate guidance, completes a safe next step or reaches the right support route without starting again. OBLYTECH helps organisations connect real questions to clear articles, workflow context, ownership, feedback and escalation.

Discuss ServiceNow knowledge and self-service optimization

Define usefulness as a user outcome

Separate three outcomes: a reader solved the issue, understood that the article did not apply and reached the right support path, or an agent used the article during resolution. All three can make knowledge useful, but they require different evidence and review. The goal is a clearer next action, not merely fewer submitted records.

Write around the question before the article title

Review incident descriptions, request wording, agent notes and search terms that people actually use. Group questions by task, symptom, decision, audience and risk. Write the shortest useful answer that explains the action, prerequisites, expected result and escalation point. Keep troubleshooting steps ordered and explicit about when to stop.

Connect knowledge to incident and request workflows

Place relevant guidance where the question occurs: during search, incident intake, agent work, request fulfilment or closure. The recommendation should match the record context. Make escalation clear by stating what information the person should include and which symptoms should not be handled through self-service.

Give every article an owner and review path

An article needs an accountable subject owner, review trigger, replacement or retirement decision and way to capture feedback. Review it when the supported workflow, access, system behaviour, policy or assignment route changes. A comment should lead to a disposition such as correction, clarification, retirement or a new article.

Improve the service from feedback and escalation

Review searches with no useful result, repeated incidents, article feedback, escalations after article views, agent use and questions that remain unresolved. Interpret each signal with context. A high view count may mean the article helps or that people cannot find a clearer answer. Use the evidence to change content, routing, questions or ownership.

For the operating baseline, see ServiceNow ITSM and Service Operations. For conversational self-service, review ServiceNow Now Assist, Virtual Agent and Self-Service.

Discuss ServiceNow knowledge and self-service optimization

Bring one recurring question, article, search failure or escalation path that is not doing enough work. OBLYTECH can help connect the question to guidance, workflow context, ownership and review.

Start the conversation

What a knowledge base is measured against when it is working

Knowledge teams often inherit a single success measure: fewer tickets. It is an easy number to produce and an easy one to misread. A drop in submitted requests can mean that people found a correct answer, or it can mean that they gave up, or that a chatbot is hiding the queue from them. The more useful question is what the reader was able to do after reading. Did they fix the problem, recognize that the article did not apply and reach the right support route, or give an agent a faster starting point? Each outcome is valuable, and each leaves a different trace in the data.

Defining usefulness this way changes what the team builds. An article designed to reduce tickets tends to be short and reassuring. An article designed to move a reader to the next correct action tends to be longer at the points where mistakes happen, and clearer about the moment when the reader should stop trying and ask for help. The second kind takes more effort to write and produces fewer dramatic numbers, but it is the kind that holds up when the product changes.

Reader outcomeEvidence that shows itChange it usually calls for
Problem solved from the articleNo follow-on search or case within a short periodKeep the article; check it still matches the current steps
Article did not apply, route foundEscalation opened after a view, with a reason recordedAdd the condition that excluded the reader, and link the route
Agent used the article to resolve fasterArticle linked on the case with a resolution noteKeep the structure; surface the article earlier in intake
Reader gave upSearch with no clicks, followed by a long gap or a repeat searchRewrite the title and opening to match the question

Starting from the words people use rather than the article titles

Articles are usually titled by the team that wrote them, using the names of features, forms and internal processes. Employees and customers describe what they see on their screen or what they are trying to achieve. A search for a message that says the record is locked will not find an article titled access control adjustments, even when the article contains the answer. The mismatch is a common reason a well-written article goes unread.

Grouping that language by task, symptom and decision gives a list of questions that the knowledge base should answer directly. The titles and opening sentences should then be written in the reader’s words, with the internal term included once for anyone who later searches for it.

  • Use the symptom the reader sees as the first line of the title, and place the internal name in the body.
  • Open with the condition that tells the reader whether the article applies to them.
  • Keep the first troubleshooting step within the first screen of text, so that a reader who only skims still acts correctly.
  • State the point at which the reader should stop and contact support, using the symptoms that should not be handled through self-service.

Shaping an article that is safe to follow

Troubleshooting articles carry a risk that policy articles do not. A reader who follows a step in the wrong situation can make a problem worse, sometimes by deleting a configuration or by repeating an action that has side effects. A safe article therefore states prerequisites, the expected result of each step, and what to do if the result is different. An article that lists steps without expected results invites the reader to continue after something has already gone wrong.

Ordering matters as well. Steps that are reversible should come before steps that are not, and any step that requires a permission the reader may not have should say so before the step rather than in the middle of it. Where a step needs a second person, such as an approver or a system administrator, the article should name that person’s role and explain how to ask.

Placing knowledge where the question arises

An article that sits only in the library is found by the readers who already know to look for it. Many people who need guidance are inside a task, such as filling an intake form, reading an incident update or waiting for a request to be fulfilled. Placing relevant guidance at those points changes the result. The recommendation should depend on the record context, so that the article shown during incident intake is different from the one shown after a request has been assigned.

The same principle applies to escalation. When a reader leaves self-service, the record should carry the search terms and the articles that were viewed. The agent who picks up the case can then begin from what the reader already tried, and the design team can see whether the article failed, the search failed or the reader should never have been routed to self-service at all. Those three causes are different, and each needs a different fix.

Feedback and disposition: what happens after a comment arrives

Feedback is only useful when each comment leads to a decision. A comment that says the article is unclear should be assigned to the subject owner, who decides whether the fix is a correction, a clarification, a split into two articles, a retirement or a new article that replaces the old one. Leaving comments in a queue that nobody reviews teaches readers that feedback is ignored, and they stop giving it.

Decisions should be recorded with the reason. The record of a retirement, for example, should say whether the process ended, the content was duplicated elsewhere or the article was simply wrong. That history prevents the same article from being recreated later by someone who does not know it was removed for a reason.

SignalRead it with this contextLikely next action
High view count, low resolutionReaders are finding the article but not finishing the taskReview steps, expected results and the stop point
Searches with no useful resultThe question uses words the library does not containAdd a clearly titled article or a synonym
Escalation after a viewThe article may not cover the reader’s conditionAdd the condition or a route to a different path
Agent-written explanation repeatedThe same answer is being written by hand each timeTurn the explanation into an article

Keeping the search honest over time

Knowledge search changes as the platform, the policies and the vocabulary change. A search that worked well last year may return old articles for new terms. A monthly look at the top searches that found nothing, and at the articles that were viewed then abandoned, is usually enough to keep the library current. The review does not need a dashboard to be useful. It needs an owner, a short list and a rule for what to do with each item.

Is a falling ticket count a reliable sign that self-service works?

Not on its own. It should be read with resolution evidence, escalations after article views and the number of readers who searched and gave up. A falling count with rising repeat searches usually means readers have stopped trying.

How many articles should cover one problem?

As few as possible. One article per distinct task is usually better than several articles that overlap, because overlapping articles drift apart when the process changes and readers cannot tell which one is current.

Should agents be allowed to edit articles directly?

Direct edits by many people make ownership unclear, and an article with no clear owner is unlikely to be corrected when it becomes wrong.

What belongs on the stop point of a troubleshooting article?

The symptoms that indicate a wider fault, any action that could affect other users, and the information the reader should collect before contacting support. A stop point that tells the reader what to bring to the next person saves a round of questions.

Next step for knowledge and self-service work

If readers are searching, reading and then raising the same question with an agent, the next useful step is a review of that question from search to resolution. A recent set of failed searches, the articles that were viewed before escalation and two or three agent explanations that were written more than once are the evidence to gather. That evidence is enough to decide whether the problem is content, routing or ownership. The knowledge base management page covers building, maintaining and optimizing a ServiceNow knowledge base. Where a case is opened after self-service fails, the customer service case routing page covers moving a customer question to the group that can make the next decision, and the contact center case escalation page covers giving agents a clear next step when an issue needs another team. The case template explainer describes a case template as a predefined structure of fields, status and assignment.

ServiceNow guides on this topic

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

Related guides

More in this section