ServiceNow Incident Management Requirements Workshop Questions

Routing and Assignment Fundamentals

Early in design, you need to decide how incidents will find the right team. Ask: Do assignment groups already exist in your organization, and do they map to your support structure? Will incidents always go to a group first, or will some incidents bypass groups and assign to specific people? If you use skills-based routing, who has what skills and how will those be maintained as staff changes occur? Will your routing rules be simple enough that staff understand them, or will they require ongoing explanation?

The answers to these questions determine your group structure and your workflow logic. An organization with stable teams and well-defined roles might use simple queue-based routing. One with matrix reporting or frequent reorganization might need more flexible skills-based routing, which is more complex to set up and maintain. Decision: Simple routing is easier to debug and explain to users. Complex routing gives you more flexibility but requires discipline to keep skill data current.

Categorization and Prioritization Strategy

Ask: How will incidents be categorized? Will category be driven by the affected asset, the service, or the symptoms the user reports? Who will do the categorization, the user or the support team? Will categorization automatically determine the priority, or will priority be set separately? What are the hard rules for what constitutes an urgent incident versus a routine request?

Many organizations struggle with categorization because they try to capture too much detail. Every possible service, system, and issue type become a category value. This makes the category list unwieldy and confuses users. A simpler approach uses broad categories that map to your support teams, with additional fields capturing detail. Warning sign: If your category list has more than twenty values, ask whether some could be combined.

Escalation and Major Incident Management

Ask: When does an incident become a major incident? Who makes that call and how do they know? What happens to a major incident that is different from a normal incident—is it moved to a different queue, is a manager notified immediately, is a bridge call opened? How many levels of escalation does your organization need, and who sits at each level? What is the definition of success for a major incident?

Organizations often define major incidents by impact—for example, fifty or more users. But they should also consider business criticality. An incident affecting a small number of executive users might deserve higher-priority response than one affecting many users of a non-critical system. Warning sign: If major incident procedures are rarely used, ask whether your criteria are too strict or whether staff do not know the procedures.

Communication and Notification

Ask: Who needs to know about an incident? When should they be notified—as soon as the incident is created, when it is assigned, or only when it is resolved? Should notifications come automatically or only when a user takes specific action? What information should each notification contain—just the ticket number and status, or full details? Should incident data appear in multiple places—email, a web portal, a mobile app, a chat channel?

Over-notification leads to information overload; under-notification leaves people guessing about status. A good design sends notifications at key points: when an incident is created or escalated, when a significant time threshold is reached, and when resolution is near. Different stakeholders may need different information: a user needs to know when their issue will be fixed, a manager needs to know about capacity and workload, a CIO needs to know about major incidents.

Survey and Feedback Collection

Ask: Will you collect feedback after incidents are resolved? Who will answer the survey and when—immediately after resolution or after a delay? What questions will you ask? Will you act on feedback or only collect it? How will you use feedback to improve your service? Should poor ratings automatically trigger follow-up actions?

Many surveys go unanswered because they arrive at the wrong time or ask the wrong questions. Some organizations survey only a sample of incidents to reduce volume. Others use brief surveys of two to three questions instead of long ones. Warning sign: If few surveys are completed, rethink your approach. Ask whether you are surveying at the right time or whether the survey is too long.

Compliance and Audit Requirements

Ask: What compliance frameworks or audit standards apply to your incident management? Do you need to prove that security incidents are investigated? That change-related incidents are tracked? That SLA breach time is minimal? What data must be preserved in each incident record for audit purposes? Who needs access to sensitive incidents?

Compliance requirements often drive access control decisions. Security teams may need to see all security incidents but not all incidents. Audit teams may need read-only access. A segregation of duties principle means that the person who approves a change should not be the one investigating incidents caused by that change. Plan these access controls at design time rather than patching them later.

Run the workshop around decisions, not questions

A requirements workshop produces value only when its answers become decisions the platform team can build against. A list of questions, however good, leaves the room full of opinions. Its purpose is to convert every question into a decision with a named decider, a deadline and a written record. Before the session, send the questions with a single line for each stating the decision it feeds. During the session, close each question with the words that will go into the decision log. If the room cannot agree the wording, the decision is not ready, and the item goes to the decider rather than being left as a shrug.

Prepare the room with the people who answer for outcomes

The people who answer the questions are not always the people who attend the meeting. Routing questions belong to the service desk lead. Major incident thresholds belong to the service owner. Notification rules belong to whoever answers for customers. Invite each decider, or agree in advance that a named deputy may decide on their behalf and will confirm the decision in writing afterwards. A workshop that relies on deputies who lack authority can produce decisions that get reopened at the first real incident. The responsibility chart for incident handling is the reference for who holds each decision.

Separate the answers that are decisions from the ones that are preferences

In many workshops, a few answers carry the whole design and the rest are preferences that can be revisited. A decision changes what the platform does, what reports say or who can see what. A preference changes only how someone likes to work. Record decisions in the log with their owner and their effective date. Record preferences in a parking list with a note on where they could later be tested. Keeping the two apart stops a sensible preference from quietly becoming a rule, and it stops a real decision from being treated as one more opinion.

Watch for answers that begin with it depends. That phrase is sometimes accurate, but in a workshop it often means the question was too broad. Break it into the two or three factors the answer depends on, and ask the decider to choose a default for each. Defaults can be changed later, provided the change is logged.

Turn the log into a build backlog

1. Go through the log aloud with the room and check each entry against the decider’s wording.
2. Assign every decision a build item, with the configuration object it touches, for example a group, a rule or a form.
3. Mark any decision that depends on legacy data, because those need a data check before they can be built.
4. Send the parking list to the process owner with a proposed date for a second look.
5. Circulate the log promptly after the meeting, with a request for corrections by a fixed date.

Questions to ask about the data you already hold

Many requirement decisions depend on data that the organization may not know it has. How are incidents categorized today, and how consistent is that across teams? How many open items exist in the current system, and what are they? Which fields are filled in every time and which are often left blank? The answers change the design more than most of the opinions in the room. A short data profile before the workshop, covering counts by group, category and state, often prevents the workshop from deciding categories that the old records cannot support. Where a question touches linked configuration records, the data quality rules for configuration records give a useful set of checks.

What a good workshop output looks like

A good output is short enough to read in one sitting and complete enough to build from. It names the decider for every item, states the default chosen, lists the open items with their dates, and identifies the decisions that need legacy data. It should also include a statement of what the workshop did not decide, so that nobody assumes silence means agreement. The output that fails is the one that runs to forty pages of notes with no owners.

Frequently asked questions about incident requirements workshops

How many people should attend?

Only as many as each decision area needs, with a decider present for every one. A workshop with twelve people and no decider on one topic will spend its time on the topic nobody can settle.

Should the workshop agree the reporting requirements too?

Agree the measures and their definitions, not the dashboards. Dashboards change often, while a clear definition of what counts as a resolved incident survives the next redesign.

What if two deciders disagree on escalation?

Record both positions, pick a provisional default with the service owner, and set a date for a review once the first real incidents have been run through the rule. Decisions made on theory are provisional until they meet live records.

Can the workshop be repeated after go-live?

Yes, and it should be. A short review at the first quarterly governance meeting catches the requirements that were wrong in practice, and it gives the team a reason to revisit the parking list.

The requirements workshop decisions guide covers a similar format in more depth.

Structuring a ServiceNow incident management process in the right order

Structure an incident process by deciding scope first, then ownership, then priority, then routing, then the lifecycle and closure rules, and only then notifications and reports. Each later decision depends on the earlier ones, so reversing the order is what causes rework after go-live.

The sequence below is the one that tends to hold up in practice.

1. Draw the boundary between an incident, a service request and a problem, so every record has one obvious home.
2. Name a process owner who can overrule a team, and a service desk lead who runs the queue day to day.
3. Agree how impact and urgency combine into incident priority, and who may change it.
4. Set routing: which group receives which kind of incident, and what happens when that group does not respond.
5. Define the states an incident passes through and the exit rule for each, including what a resolver must record before closing.
6. Decide the criteria for declaring a major incident and who has the authority to declare one.
7. Last, design notifications and reports from the decisions above, not before them.

Teams that start with notifications or dashboards usually discover that nobody agreed what a resolved incident means, so the reports cannot be trusted. If you want a delivery team to run this sequence with you, see our incident and problem management service.

What is the difference between an incident and a service request?

An incident is an unplanned interruption or reduction in quality of a service. A service request is a routine ask for something that is already offered, such as access or equipment. Mixing them distorts priority rules, targets and reporting.

Who should own the incident process?

One named person with authority across the resolver teams, usually a process owner in IT service management. Ownership split across teams leaves routing disputes and priority disagreements with nobody who can settle them.

How do you know the incident process is working?

Look for incidents that reach the right group first time, closure notes a different resolver could act on, and priority changes that are rare and explained. If those three hold, the design is sound. If not, revisit the earlier steps.