ServiceNow Problem Management Requirements Workshop Questions

Deciding how recurring incidents become problem records, who may raise and close them, and how their fixes pass into change is the work of a problem management workshop. This page gives the question bank for those decisions, grouped into five themes.

The question bank below is grouped into five themes: incident clustering and problem creation, lifecycle and roles, investigation and escalation, change and deployment, and measurement. For each theme the later sections show what each answer changes in the configuration, the warning signs to listen for during discussion, how to prepare and sequence the session, and what the workshop should hand over.

Themes and Question Groups

The first theme covers incident clustering and problem creation. How do you currently identify recurring problems? Do you wait for multiple incidents to occur, or do you proactively investigate systemic risks? Should ServiceNow automatically suggest incident groupings based on patterns, or should a human analyst manually group related incidents? These answers determine how problem records are created and who decides which incidents to group.

The second theme covers problem lifecycle and roles. What stages should a problem go through: created, investigating, pending change, resolved, closed? Who is authorised to create problems—only dedicated analysts, or any incident handler? Who has authority to close a problem? These answers define your workflow states and access controls.

The third theme covers investigation process and escalation. How much investigation must happen before a problem is moved to “pending change”? What decisions escalate a problem to senior engineers or management? How long can a problem remain open before escalation is mandatory? These answers shape workflow automation and escalation rules.

The fourth theme covers change and deployment. When a problem is solved, is a formal change request required, or can it be deployed directly? Who approves the deployment? Does the problem stay open until the fix is deployed, or can it be closed when the solution is designed? These answers connect Problem Management to Change Management and define the hand-off process.

The fifth theme covers performance measurement and reporting. How do you measure problem management effectiveness? Is it problem resolution time, number of incidents prevented by fixes, or cost avoided by solving root causes? What dashboards and reports does your team need? What data must be captured to support reporting? These answers define your Success metrics and data collection requirements.

What Each Answer Changes in the Design

If you decide problems should be created only when a set number of incidents occur within a set window, the system design must track incident patterns and trigger problem creation automatically or notify an analyst when the threshold is reached. If instead you allow proactive problem creation without incident clustering, the design is simpler but requires trained analysts to identify problems.

If change requests are mandatory for all problem solutions, Problem Management must link to Change Management and enforce that a change exists before a problem can be closed. If change is optional, the workflow is more flexible but risks deploying fixes without proper change governance.

If problem investigation time is unlimited but escalation triggers at “known issue” status, the design allows exploratory work without forcing a decision too early. If a decision deadline is enforced—for example, a problem must be escalated within two weeks if not resolved—the design encourages faster decision-making but may pressure incomplete analysis.

Warning Signs During Workshop Discussion

If your team cannot agree on what constitutes a “problem” versus an “incident,” you will face configuration ambiguity and user confusion after go-live. Spend time defining the boundary: a problem is a root cause investigation; an incident is an immediate disruption. This distinction is fundamental to Problem Management.

If your team resists connecting to Change Management—”we don’t need formal changes for problem fixes”—you may be creating a gap in governance. Even small fixes should have some level of approval and documentation. Clarify what “formal change” means: it need not be time-consuming, but some control is usually necessary.

If discussion reveals that incidents are handled in multiple disconnected systems, you have a larger integration problem to solve before Problem Management can be effective. Consolidate incident tracking into one system first.

Output of the Workshop

At the end of the workshop, your team has documented answers to all questions and agreed on the resulting configuration approach. The configuration team uses these answers to set up workflow states, routing rules, escalation criteria, and reports. The workshop also identifies gaps: areas where your organisation is not yet ready, or where ServiceNow’s out-of-the-box capabilities don’t match your needs and customisation will be required.

Preparing the workshop for usable answers

The answers from a problem management workshop only help a configuration team if the right people gave them. A common problem is that one senior person answers every question from memory and the team builds for that memory. Before the session, decide who must be in the room for each subject. Investigators should answer questions about investigation, incident managers should answer questions about recurrence, and someone who owns change approval should answer anything about fixes. Send the question list in advance with the reason each question is being asked, so people can check their own records instead of guessing.

The questions below are not the standard themes. They are the ones that tend to expose disagreement early, which is the point of asking them. Each row shows the decision the answer sets and the person who must agree to it.

Running the session in an order that surfaces conflict

1. Start with the boundary between an incident and a problem, and ask each attendee to write their own one-sentence definition before discussion. Divergent definitions are a strong early warning of configuration trouble.
2. Move to the questions that depend on that boundary, such as reopening and linking, before any questions about screens or reports.
3. Take each disagreement to a recorded decision with a named owner, even if the decision is to defer it. An unanswered question still needs a name against it.
4. Read back the answers that were agreed, and ask one attendee from each group to state the consequence in their own words.
5. Send the record to everyone who attended and to the people who were not present but own a related decision, with a date by which any objection must be raised.

Signs the workshop is not producing usable answers

Answers recorded as yes or no with no condition are often the first sign of trouble. A question such as whether problems should be linked to changes has a dozen sensible answers depending on the category of problem, and a bare yes can be built as an absolute rule. Ask the follow-up question every time: yes for which problems, and what happens when the answer is no. The second sign is an attendee who agrees to everything quickly. Agreement that comes without any objection often means the person has no authority over the area, which is worth finding out before the session ends.

A third sign is a list of questions that grows during the workshop without any answer being closed. Park any question that cannot be answered in the room, but give it an owner and a date, and do not let the parked list become the real output of the session.

Practical questions during the session

How many people should attend?

Enough that each subject has an owner present, and no more. A large room produces polite agreement and small decisions. Invite people for their authority and their evidence, not for their interest in the topic.

What if regional teams give different answers?

Record both answers and the reason for each. Then decide whether the difference is a real business variation, which the design must support, or a habit, which the design should replace. Do not resolve it by choosing whichever answer the most senior person gave.

Should reporting be covered before the process is designed?

No. Reports built before the process is agreed can measure the wrong steps. Cover the process first, then ask what needs to be measured, and treat the measures as a consequence of the process rather than a driver of it.

What should happen to the answers once the workshop ends?

They should be kept as the decision record for the configuration and reviewed when the configuration is changed. The guide to requirements workshop decisions covers keeping that record usable after the project team has moved on.

Related guides: Continuous Improvement.