ServiceNow Knowledge Management Managed Support

Managed support for knowledge management answers one question above all: who keeps the knowledge base current after it goes live, and on what cycle. This page covers the engagement scope, the starting problems that bring teams to managed support, how the engagement runs from assessment to ongoing optimisation, typical deliverables and results, how knowledge connects to adjacent modules, a monthly maintenance cycle that holds, what the support provider should not own, and when managed knowledge support is premature.

The engagement covers several areas: knowledge base design and structure (how to organize content so users can find it), content creation and maintenance (writing articles that are clear and useful), user adoption (helping employees and customers find and use knowledge), search and discovery (tuning search so users find answers quickly), and ongoing optimization (measuring what is working and improving what is not).

Typical Starting Problems

Organizations typically come to Oblytech with one of these challenges: knowledge base does not exist or is scattered across wikis, wikis, and emails with no central location; knowledge base exists but is disorganized and users cannot find content even when it exists; knowledge base has outdated content that contradicts current policy; search does not work well and users give up trying to find answers; support tickets keep coming in for questions that should be answered by knowledge base; or knowledge base is the responsibility of one person and content falls behind when that person leaves.

A second set of challenges are operational: how do we write clear, useful knowledge articles? How do we get SME (subject matter expert) time to write content? How do we ensure content stays current? How do we measure whether knowledge is actually reducing support tickets? How do we set up a sustainable process so knowledge management does not break down?

How Oblytech’s Engagement Works

Initial phase: Oblytech assesses your current knowledge management situation. We interview support teams to understand what questions they are answering repeatedly. We review any existing knowledge content to understand structure, quality, and coverage gaps. We identify high-impact areas where knowledge would solve the most problems (for example, if a large share of support tickets are about password reset, a clear knowledge article on password reset has high impact).

Design phase: We design a knowledge base structure and organization that makes sense for your audience. If your audience is IT staff, articles focus on troubleshooting and technical procedures. If your audience includes non-technical end-users, content is simpler with more step-by-step instructions. We define content standards: how detailed should articles be, what format should they follow, how should they be written so users can scan quickly and find answers.

Content creation: We work with your subject matter experts to create high-priority articles. Depending on the engagement, we may write content ourselves with SME review, or we guide your team through the writing process. We focus on high-impact content first (articles that solve the most tickets) rather than trying to cover everything at once.

Launch and adoption: We help you launch the knowledge base and communicate it to users. We set up search tuning so that when users search for “forgot password” they find the password reset article. We monitor early usage and adjust based on what we learn. We identify which articles are being read (indicating they are useful) and which are never read (indicating they need improvement or removal).

Ongoing optimization: After launch, we help establish an ongoing process to maintain and improve the knowledge base. We review usage metrics monthly and identify improvement opportunities. We help SMEs update content when procedures change. We establish a process for users to give feedback on articles, helping identify what is confusing or outdated. Quarterly reviews ensure the knowledge base continues to deliver value.

Typical Deliverables

Deliverables usually include: knowledge base structure and governance plan (how knowledge will be organized and maintained); high-impact knowledge articles sized to the engagement; search configuration tuned for your environment; user communication plan and training materials; metrics dashboard showing knowledge usage and impact on support tickets; and a knowledge maintenance and improvement plan with a timeframe agreed with you so work continues after Oblytech steps back.

How It Connects to Adjacent Modules

Knowledge Management integrates with the service desk and ticketing system: when a user submits a support ticket, the system can recommend related knowledge articles and try to resolve the issue through self-service before creating a ticket. When support staff responds to a ticket, they can suggest relevant knowledge articles to the user, turning each support interaction into an opportunity to improve self-service. Knowledge can also be embedded in service catalogs and in employee onboarding workflows.

Typical Results

Organizations that invest in knowledge management typically see: reduction in support ticket volume (users finding answers without contacting support); reduction in support resolution time (staff finding answers in knowledge base faster than using email or memory); improved employee satisfaction (users prefer finding quick answers to waiting for support); and improved support staff satisfaction (less time on repetitive questions, more time on complex issues).

Time to value varies: early on, users usually start finding answers in the knowledge base. Once adoption is good, organizations typically see measurable reduction in ticket volume for the topics covered by knowledge. Full impact depends on how much content is created and how many users discover and use the knowledge base.

Who keeps a knowledge base current after it goes live

A knowledge base left without a maintenance routine loses its value in a predictable way. Articles fall behind the process they describe, new issues appear with no article at all, and the authors who wrote the first set drift to other work. Managed support for knowledge is the routine that prevents this, and it has to answer three questions in advance: who notices that content has gone stale, who fixes it, and who decides when to retire it. If any of those answers is someone who is not paid or measured for the task, the routine will stop within a few cycles.

The useful split is between work the support provider can run and work only the business can do. The provider can monitor search, triage incoming feedback, draft updates from resolved tickets, prepare review packs for subject experts and track the backlog. The business must confirm that a procedure has changed, approve policy wording and decide what is retired. Automating parts of the triage is covered in the knowledge management automation guide.

A monthly maintenance cycle that holds

A cycle that repeats beats an ambitious one. The steps below suit a small team that works through the same order each month. Retirement rules for stale content sit in the lifecycle guide for knowledge articles.

1. Pull the search terms with no useful result and the articles with the most negative feedback for the period.
2. Group the feedback by topic and mark each topic as a content gap, an accuracy problem or a findability problem.
3. Send accuracy problems to the subject expert with the specific step in question, not the whole article.
4. Draft new articles for content gaps from the resolved tickets that raised them, and queue them for the same expert review.
5. Publish the reviewed changes, archive any article the process owner has confirmed as obsolete, and record each change against the ticket that prompted it.

What the support provider should not own

A managed support team that writes every article quickly becomes the only team that understands the content, and subject experts stop engaging because they no longer see their name on it. The provider should draft and organize, while the expert confirms accuracy and the process owner confirms the procedure still applies. This keeps the knowledge owned inside the organization even when the day-to-day work is run externally. The broader managed model for the platform is covered in the managed support services overview.

How do we stop the knowledge base filling with near-copies of the same article?

Check for an existing article before drafting a new one, using the search terms from the requests. When a near-copy is found, update the existing article and add the new case as a section, rather than creating a parallel article with a different title. Governance of what teams publish is covered in the knowledge management governance guide.

What evidence should the monthly review show?

Show the topics where users searched and did not find an answer, the articles that were updated and why, and the articles retired. Those three lists tell the owner whether the base is growing in the right places and whether anything is being left to rot.

Who should be paid or measured for knowledge maintenance?

Whoever owns the process the article describes should carry the accountability, because they are the only person who can confirm the content is current. Add the review time to their objectives, not to a volunteer list.

What happens to the routine if the knowledge owner leaves?

The routine should survive the departure because it lives in the cycle, the queue and the review packs rather than in one person’s memory. Keep a written owner for each article type, so that a departure reassigns named items instead of orphaning the base.

When managed knowledge support is premature

If the base has no agreed structure, a maintenance routine will spend its time reorganising content. If no process owners can be identified, updates will be drafted and never confirmed. In those cases the work to do first is a structure and ownership decision, after which a managed routine can take over the upkeep. A health check before the routine starts is covered by the knowledge management health check service.

A maintenance cycle only works when the owners named in it are real people with time to give.