ServiceNow Problem Management: Roles, Responsibilities and RACI

Problem investigations cross infrastructure, application, business and service desk teams, so the role model has to say who investigates, who decides, who is consulted and who is told. The sections below describe the Problem Manager, subject matter experts, the Change Manager and Incident Management, give a RACI for opening, investigating and approving a fix, set escalation paths, and cover how a team smaller than the model covers the roles.

Core Problem Management Roles

The Problem Manager owns the overall process and is typically the point of escalation when an investigation is stuck or a decision is delayed. The Problem Manager is accountable for ensuring investigations start promptly, progress toward resolution, and do not linger indefinitely. This role is often a senior service desk analyst or a dedicated role in larger environments. The Problem Manager chairs or sponsors the problem review meeting where findings are discussed and root causes are confirmed.

Subject Matter Experts (SMEs) provide technical expertise during investigations. An infrastructure SME might investigate why a database server crashed. An application SME might investigate why users see intermittent errors in a specific module. SMEs are responsible for gathering data, testing hypotheses, and documenting findings. They may not be accountable for the final decision (that might belong to the architecture team), but their expertise is essential to reaching a good decision.

The Change Manager or Change Advisory Board is responsible for reviewing proposed fixes and approving changes that implement them. Even small fixes carry risk of causing new problems, so changes implementing problem resolutions should follow change procedures. This prevents a fix for one problem from causing another.

Incident Management provides context: which incidents are related to a problem, how often it is occurring, what the business impact is, and what temporary workarounds exist. The Incident Manager is consulted during investigations and informed of problem conclusions so future incidents can reference the problem ticket.

Typical RACI Matrix for Problem Management

Below is a common responsibility assignment for major problem activities. Adjust it to match your organizational structure and incident patterns. Cells are marked R (Responsible: does the work), A (Accountable: makes the final decision), C (Consulted: provides expertise), I (Informed: receives updates).

Opening a Problem and Initiating Investigation

• Service Desk: Responsible for creating the problem ticket and initial diagnosis. Often the service desk analyst who sees the pattern of incidents recognizes a root cause is needed.
• Problem Manager: Accountable for approving the investigation scope and assigning investigators. Ensures the problem is worth investigating (frequency, impact, cost of investigation).
• Subject Matter Experts: Consulted to estimate investigation effort and feasibility. Responsible for designing the investigation approach.
• Incident Manager: Informed so related incidents can be linked and escalations can mention the investigation.

Conducting the Investigation

• Subject Matter Experts: Responsible for gathering data, testing hypotheses, performing root cause analysis, and documenting findings.
• Incident Manager: Consulted if incident data or patterns provide clues about what the root cause might be.
• Problem Manager: Accountable for ensuring progress, unblocking investigators if they are waiting for access or data, and escalating if the investigation stalls.
• Change Manager: Informed of the investigation status so that high-risk fixes can be pre-planned.

Reviewing Findings and Approving a Fix

• Subject Matter Experts: Responsible for presenting findings and proposing root causes at the review meeting.
• Problem Manager: Accountable for convening the review, validating root cause analysis, and approving the problem record. Responsible for deciding whether the root cause is confirmed or needs more investigation.
• Architecture or Infrastructure Lead: Consulted to validate that the proposed root cause is plausible given their understanding of systems.
• Change Manager: Responsible for reviewing the proposed fix and assessing change risk. Accountable for approving the change implementation.
• Incident Manager and Service Desk: Informed of the root cause and the planned fix so they can help users understand the issue.

Escalation Paths

Problem investigations sometimes reach impasses: conflicting opinions on root cause, proposed fixes that are too risky or too expensive, or teams unable to agree on priorities. Define escalation paths so these situations do not delay investigation indefinitely. If technical teams cannot agree on root cause, escalate to an architecture review board or infrastructure steering committee. If a fix is too expensive, escalate to business stakeholders who can decide whether the benefit justifies the cost. If responsibility for follow-up is unclear, escalate to service leadership to assign accountability.

Ownership Gaps to Watch For

Service ownership gaps often emerge during problem investigations. A recurring issue might occur at the boundary between two systems, and neither team feels responsible for investigating. A performance problem might require changes to code, infrastructure, and configuration, and no one coordinates across the teams. Define a standard approach: the Problem Manager assigns a lead investigator who coordinates across teams, even if they are not the technical expert. The lead investigator has authority to request data and time from other teams.

Covering roles in a team that is smaller than the model

Role models are often drawn for a team with one person for each seat. Many problem management teams have fewer people than the model, and the seats that go unfilled are the ones that matter most during an absence. The practical question is not what the ideal role set looks like but which roles can be combined safely, which must always be held by different people, and who covers each one when its holder is away. Answering that in advance prevents an investigation from freezing because the one person allowed to approve a fix is on leave.

A cover plan that works without the absent person

A cover plan earns its place only when a stranger to it can carry it out. Keep it short, keep it in the problem record configuration documents, and test it once a period by asking the deputy to do a real action without help.

1. Name a deputy for each role in the table, and confirm the deputy has the access the role needs before the absence starts, not during it.
2. List the decisions that cannot wait: convening a review for a live problem, approving a workaround, and approving a change that restores service.
3. For each decision, write down the minimum evidence the deputy needs and where it is stored.
4. Agree the threshold at which an absent role’s decision should be escalated instead of delegated, and name the escalation contact.
5. Check the plan when the absence ends, and record any decision the deputy made so the original owner can review it.

Where small teams fall into conflict

The conflict that causes most trouble in a small team is one person raising a problem, investigating it, and approving its closure. Nothing about it is malicious, and it often starts because the team is busy. The effect is that the closure can go unchecked, and an unverified fix is recorded as resolved. The practical fix is a rule that the person closing a problem is not the person who investigated it, with the exception written down and reviewed each period. Where that is impossible, a peer review by someone from another service is an acceptable substitute, provided it is recorded.

A second conflict arises when the incident coordinator becomes the de facto problem manager without being given the authority. They end up deciding which problems are worth investigating, which is a governance decision. Make that authority explicit or move the decision to the problem manager, even if the coordinator still does the sorting.

Questions teams ask about role design

Can an investigator also be the change implementer?

In a small team, often yes for low-risk changes. Keep the approval separate, and record that the same person designed and implemented the change. Higher-risk changes should not be implemented by the investigator who proposed them without a second pair of eyes.

Who should cover the service owner role when the owner is unavailable?

The next senior owner of the affected service, not the problem manager. Covering a service decision with the person who runs the process blurs the line between running the process and owning the outcome.

How many problems can one investigator hold at once?

There is no universal figure. Set a limit that the team lead can defend against the complexity of the work, and review it when investigations start to age. A limit that is never reviewed becomes a reason to ignore the age figures.

Does a RACI chart need to be reviewed when people change?

Yes, and the change should be recorded. Many RACI charts are accurate when signed and can drift quickly. The guide to assignment group governance describes how to keep the ownership fields aligned with the chart, which is where the drift often starts.

Assignments are cheap to set and expensive to unpick. Approval rights inside the platform are a separate matter, so read the access design notes for this area before fixing them.