ServiceNow Knowledge Management Consulting

Knowledge management consulting turns on three choices: which knowledge to capture first, who writes and who reviews it, and where subject-expert time comes from. This page covers the consulting approach from audit through programme design and module configuration, how knowledge connects to the support workflow, what the client provides, success metrics, retention during staff transitions, a procedure for testing the knowledge base against real demand, where programmes go wrong after launch, and when a consulting engagement is premature.

Consulting Approach

We begin with knowledge audit and assessment. We review existing knowledge repositories—shared drives, wiki sites, support documentation—to understand what exists and how well organized it is. We interview support staff to identify gaps: what problems keep recurring, what solutions are kept in people’s heads rather than documented, what questions customers ask repeatedly. We analyze support tickets to identify the most frequent and time-consuming issues.

Planning phase designs the Knowledge Management program. We define what knowledge to capture—incident solutions, FAQ, troubleshooting guides, best practices. We design organization and taxonomy so articles are easy to find. We plan governance: who authors and maintains knowledge, how often is it reviewed for accuracy, how are outdated articles retired. We design knowledge integration into support: how do agents surface solutions while helping customers, how does knowledge feed incident resolution.

Implementation configures ServiceNow Knowledge Management, builds initial knowledge base with high-value articles, establishes publishing and review processes, integrates knowledge with incident and request fulfillment, and measures adoption and impact. We train authors how to write effective articles and maintainers how to keep knowledge current.

How Knowledge Connects to Support Workflow

Knowledge should be tightly integrated into incident and request fulfillment, not a separate repository staff rarely access. We design how agents search knowledge while helping customers, how customers access knowledge via self-service portal, and how commonly used solutions are suggested automatically based on incident details. Integration makes knowledge part of normal work, not an overhead activity.

What the Client Provides

You provide access to existing documentation, support tickets so we can understand common issues, and interviews with subject matter experts and support staff. You also identify knowledge authors who will maintain the knowledge base going forward and executives who will sponsor the Knowledge Management program. Executive sponsorship is essential because building knowledge takes time initially before payoff is visible.

Success Metrics

Metrics include self-service resolution rate (customers solving problems without contacting support), support ticket resolution time (faster because staff have documented solutions), support staff productivity (faster resolution means more tickets handled per day), and knowledge usage (how often articles are accessed). The best metric is customer satisfaction with self-service and support—when customers find answers quickly and support staff resolve issues faster, satisfaction improves.

Knowledge Retention During Staff Transitions

Knowledge Management becomes critical when experienced staff leave. Their expertise should be captured in articles before they depart. This retention of knowledge prevents loss of critical expertise and enables other staff to perform tasks previously done by the departing person. Knowledge Management is also valuable for onboarding new staff—they can learn from documented knowledge faster than learning only from colleagues or trial-and-error.

Measuring Knowledge Management Impact

Success metrics include self-service resolution increasing, support staff resolution time decreasing, customer satisfaction improving, and staff turnover having less impact on support capability because knowledge is documented. The best metric is business outcome: cost reduction through faster resolution or reduced need for external support, or revenue protection through reduced support workload allowing focus on higher-value work.

Community and Knowledge Sharing

Encourage knowledge sharing culture where staff are incentivized to contribute and maintain knowledge. This might involve recognition programs, metrics that reward contributors, or dedicated time for knowledge creation and maintenance. Communities of practice can work together to ensure knowledge coverage in their domains. Internal wikis or collaboration platforms can supplement formal Knowledge Management as a place for less formal knowledge sharing alongside official documentation.

Feedback and Continuous Improvement

Knowledge is most valuable when it is used and trusted. Collect feedback from users: is knowledge accurate, is it useful, is it easy to find. Use feedback to improve articles and identify gaps in coverage. When users find errors, fix them quickly and visibly, demonstrating commitment to accuracy. User satisfaction with knowledge drives adoption; poor quality knowledge drives users away to external resources or colleagues.

Choosing which knowledge to capture first

A knowledge program is judged by the articles people actually open, and the first design decision determines whether those articles exist. Teams often begin by listing every subject their staff could write about, which produces a backlog of many topics and a launch that nobody finishes. A more useful starting point is the ticket history. Take the last full cycle of incidents and requests, sort them by topic and by the time each one took to close, and look for the topics where the same answer is given again and again. Those topics earn the first articles. Everything else waits until the first set is in use. Roles for authors and reviewers are set out in the knowledge management roles guide.

Not all knowledge carries the same risk when written badly. A wrong how-to for a password reset generates calls. A wrong procedure for restoring a service during an outage can extend it. Classify candidate content by the damage a wrong answer would cause, then give the highest-risk content the most review before publication. Decision rights for knowledge content are covered in the knowledge management governance model.

Who writes, who reviews, and where subject expert time comes from

The authoring model is where most programs stall. If every article must be written by a senior engineer, the engineer’s queue becomes the limit on the whole knowledge base. If every frontline agent can publish directly, the base fills with duplicates. Most workable models sit between these: frontline agents draft from resolved tickets, a small group of named reviewers checks accuracy, and subject experts are asked for review time in fixed blocks rather than open-ended help. Agree the review load in hours per month before launch, because expert time offered informally tends to vanish within the first cycle.

A procedure for testing the knowledge base against real demand

Before committing to a content plan, run a short test on the existing base. The steps below show whether the content you have answers what people ask, and they produce the first content list in the same pass. A structured quality review of existing content is described in a guide to knowledge quality review.

1. Pull the most recent closed tickets for the highest-volume categories and mark which ones had an answer that could have been self-served.
2. Search the knowledge base for each of those topics using the words the requester used, not the category name, and record whether a useful article appears on the first results page.
3. Read the top three results for each topic as a new employee would, and mark any step that depends on knowing something the article does not say.
4. Sort the gaps into three groups: no article exists, an article exists but is hard to find, and an article exists but is wrong or out of date.
5. Assign the first group to new authors, the second to the taxonomy and search work, and the third to the owners of the affected process.

Where programs tend to go wrong after launch

Launch usually goes well because the first articles are chosen to succeed. The trouble starts in the second cycle, when the authors who wrote the first set move to other work and nobody has been named to review the articles that are now a year old. Watch for articles with no owner, search queries that return no result for a common topic, and duplicate articles written under different titles by different teams. Each of these can be tracked from the knowledge base itself and needs a named person to act on it. The stages an article passes through after launch are described in the guide to the knowledge article lifecycle.

Should we migrate the old wiki pages into the knowledge base?

Migrate the pages that are used and that have an identifiable owner. Old pages nobody has viewed in a long time should be archived, not moved. Migrating everything carries the old structure, the broken links and the contradictory guidance into a system that users now trust more, which is the worst combination.

How do we get subject experts to write articles?

Ask them to review drafts rather than to write from scratch. A draft prepared from a resolved ticket takes an expert minutes to check, while a blank page takes hours and is put off. Credit the expert on the article and make the review time visible in their workload, since informal favours do not survive a busy quarter.

Do we need an approval step for every article?

Not for every article. Use a full review for high-risk content and a lighter peer check for routine how-to articles. A single approval path for everything slows routine publishing so much that authors route around it and publish unreviewed copies in other places.

Who should decide when an article is retired?

The process owner should decide retirement. The knowledge lead keeps the right to archive when that owner stays silent. Leaving retirement to chance is how outdated instructions stay live for years.

When a knowledge consulting engagement is premature

If nobody can say who owns the knowledge that exists, a content plan will be written and then wait for an owner. If the ticket data is too poor to show which topics recur, the first content list will be guesswork. The better opening move is naming owners and repairing the category data. A content program can follow once the ownership and the demand evidence are in place. The knowledge management health check tests what the existing base already does well.

Which content goes first is a decision best made against your own queues.