ServiceNow Knowledge Management: Roles, Responsibilities and RACI

Roles in Knowledge Management Operations

Knowledge Management in ServiceNow is often treated as a single responsibility (“who manages knowledge?”) when it is actually multiple roles with distinct responsibilities. These roles include: Knowledge Contributors (technical staff who create articles about their area), Knowledge Reviewers (senior staff who ensure quality and accuracy), Knowledge Maintainers (staff who update articles as processes change), Knowledge Consumers (staff and customers who search and use articles), and Knowledge Managers (leadership who track KM metrics and strategy).

Each role requires different training, permissions, and accountability. A contributor needs to know how to write clearly and use the article template; they do not need to approve articles. A reviewer needs technical depth to validate accuracy; they do not need to write. A manager needs to understand KM strategy and ROI; they track metrics and set goals. Clarifying these distinct roles prevents confusion about who owns KM and prevents burnout from asking one person to do everything.

Decision Rights and Escalation

Clear decision rights prevent KM gridlock. Who decides which topics to document? (Team lead, KM manager, customer feedback?) Who decides whether an article is ready for publication? (Single reviewer, multiple reviewers, peer review?) Who decides to deprecate or archive old articles? (Author, reviewer, KM manager?) These decisions should be assigned to specific roles.

Escalation paths clarify what happens when decisions are not made. If a reviewer does not approve an article within SLA, does it auto-approve, escalate to a manager, or remain pending? If an article is flagged as inaccurate, who decides what to do (update it, deprecate it, or discuss it)? Clear escalation prevents articles from languishing in review status.

A RACI Table for Knowledge Work

A RACI matrix (Responsible, Accountable, Consulted, Informed) clarifies who does what in KM processes. Here is an example:

In this RACI, the Knowledge Reviewer is responsible and accountable for approving accuracy; the KM Manager is accountable for publication and metrics tracking. The Contributor updates articles based on feedback (R) with the Manager accountable for ensuring updates happen. This clarity prevents duplicate work and ensures accountability.

Escalation Paths and Ownership Gaps

Identify ownership gaps by examining the RACI. An activity with no “A” (accountable) means no one is explicitly responsible for outcome; it will likely fall through the cracks. An activity with too many “Rs” (responsible) means multiple people might do it, creating inefficiency. Adjust the RACI until each activity has clear ownership.

Escalation paths connect decision-making. If a Contributor and Reviewer disagree on whether an article is ready for publication, who breaks the tie? The KM Manager should be the escalation point. If an article is flagged as inaccurate but the Contributor disagrees, escalate to the Subject Matter Expert. Define these paths explicitly so they are not discovered during conflict.

Metrics and Performance Tracking

Knowledge Management should be measured. Track: number of articles created per month (indicator of productivity), article usage (how many people read each article), time to publication (how long from writing to approved publication), and knowledge reuse (do articles actually reduce support tickets?). These metrics guide investment and show value.

Different roles track different metrics. Contributors might track articles written. Reviewers might track average review time. Managers track overall KM coverage and business impact. Making metrics transparent drives accountability and focuses effort on high-impact work.

Common Challenges and How Roles Address Them

Challenge 1: Knowledge is created but not maintained. Articles become stale and inaccurate. Assign a Maintainer role explicitly. Processes change; articles must reflect current processes. Add a review schedule (e.g., every article reviewed annually) to catch drift.

Challenge 2: Too much knowledge, hard to find what you need. Assign a KM Manager to enforce tagging, categorisation, and search optimisation. Organization matters as much as volume; 100 well-organised articles beat 1000 poorly organised ones.

Challenge 3: Support staff do not use knowledge, preferring to resolve manually. Involve Support teams in knowledge design; ask them what information they need to resolve faster. If knowledge articles exist but are hard to search or incomplete, support staff rightly ignore them. Build knowledge they will actually use.

Starting from the article’s life, then assigning people to each step

A RACI chart is only as useful as the list of activities it sits on. Many teams draw the chart from job titles and then discover that the titles do not map onto the work. A better sequence is to walk one article through its whole life, from the first moment someone decides it is needed to the day it is retired, and write down each action as it happens. The actions that come out of that walk are the rows, and the parts of an article that each action touches make useful column labels. The people who perform them, decide on them and must be told about them are the columns. Done this way, the chart reflects how the knowledge actually moves, including the awkward steps such as the author who leaves the company halfway through a draft.

For a single article the walk often produces a list of several actions. Typical ones include capturing the need, drafting, checking technical accuracy, checking clarity and readability, approving the article for publication, publishing it to the right audience, responding to reader feedback, revising after a process change, and retiring it. Each action needs exactly one accountable role. Where two roles both feel accountable, the action can stall at the first disagreement.

Where role charts for knowledge often break down

The first failure is the author who also approves. It feels efficient in a small team, but the reviewer’s job is to catch what the author missed, and an author cannot do that reliably about their own text. The second failure is the chart that gives everyone a responsible role and nobody an accountable one. Responsibility can be shared across a team; accountability should sit with one person per action, otherwise the first complaint about an out-of-date article gets passed around until someone gives up. The third failure is the missing retirement step. Teams often spend effort on creating articles and little on removing them, so the knowledge base grows while its accuracy falls. A chart that has no row for retirement is incomplete, however tidy it looks. Teams that want the wider picture can read the governance notes before they settle who holds which step.

Designing the review lane for one article at a time, using the lifecycle stages as the frame

Once the roles are named, it helps to describe the lane an article travels through, step by step, so that every person knows when the article is theirs. The sequence below is a sensible default for a team that has a few dedicated reviewers. Adjust it where a regulated topic needs an extra approver.

1. The author drafts the article from a closed case or a documented procedure and marks the category and the intended audience.
2. The subject matter expert checks the technical steps against the current configuration, not against memory of how the system used to behave.
3. The reviewer checks clarity, structure and the presence of warnings, then either approves or returns the draft with specific changes listed.
4. The article is published to the agreed audience, and the category owner is notified so the new article appears in their review list.
5. Readers’ feedback goes to the article owner, who decides whether to revise, split or retire.
6. When a process changes, the category owner reopens every article that cites the changed step and assigns each one to an owner for revision.

When a reviewer is the wrong person to approve

A reviewer should approve content in an area where they can judge accuracy. Consider a situation where a generalist reviewer is asked to approve an article about a complex integration that they have never configured. They will tend to approve what reads clearly, which is not the same as what is correct. In that case the approval should move to the subject matter expert, and the generalist can still check readability. This split also protects the reviewer, who should not be made to carry responsibility for technical detail they cannot inspect.

Is it acceptable for one person to hold two roles in a small team?

Yes, but only if they do not hold the two roles for the same article. A single person can own a category and also contribute articles to it, provided another person reviews those articles. Make the exception visible in the chart so that the next person to join the team does not assume the rule is absent.

Should the service owner be accountable for article quality?

The service owner should be accountable for whether the knowledge supports the service, which is a different question from whether each sentence is right. Article quality belongs to the category owner and the reviewers, and the service owner sets the standard they are held to and reviews the results.

What happens to articles when their author leaves the organization?

The article needs a new owner at once, and the chart should say who that is by default. Without a default, articles drift to whoever notices them first, and some are never claimed. A quick pass through the articles held by a departing author is worth adding to the offboarding checklist.

Do we need a full RACI if we only have a handful of contributors?

A full chart is probably more than a small team needs, and a short quality review routine may do more for accuracy than a long one. Writing down just the accountable person for publication, the accountable person for retirement and the reviewer for technical content can prevent many of the problems a larger chart would solve.