ServiceNow Event Management Requirements Workshop Questions

Workshop Structure and Objectives

An Event Management requirements workshop has one output: a recorded set of decisions about which monitoring sources feed the platform, which events are kept or filtered, how related events are correlated, and how the surviving events become incidents and reach the right team. The questions below are grouped by those themes, with a note on what each answer commits the design to and a warning sign where a weak answer points to a visibility gap. The closing sections give a decision log format and a way to run the sessions so the answers can be used afterwards.

Theme: Event Sources and Volume

Question: Which monitoring tools currently send alerts to your operations team? Answer determines how many integrations to configure. If you have ten different monitoring tools, expect significant integration work. If you have two or three, integration is straightforward.

Question: How many events per day does each monitoring tool generate? This establishes scale and helps size the Event Management infrastructure. More than five thousand events per day typically requires careful correlation tuning and filtering to prevent overwhelming operators.

Question: What is the highest priority or severity threshold for events you want to collect? Not every alert from every tool is valuable. Defining minimum severity or event type prevents low-priority noise from cluttering the system.

Warning Sign: If teams cannot articulate which monitoring tools they have or how many alerts those tools generate, you have visibility gaps. This suggests hidden alert channels that operators are using informally. Investigate before design.

Theme: Event Prioritization and Escalation

Question: What events need immediate escalation and to whom? This answer defines notification and escalation workflows. Events affecting critical services might escalate immediately to the infrastructure manager; routine events might route to a monitoring dashboard only.

Question: How should we distinguish between informational events that just get logged and critical events that require immediate action? This defines filtering rules. Many teams log all events for audit purposes but only notify operations about high-priority events.

Question: What should happen when multiple related events arrive at nearly the same time? This answer guides correlation rule design. Infrastructure teams often want related events grouped and presented as a single actionable issue.

Warning Sign: If the team wants to escalate all events with high priority, you have not done the filtering work. Escalating everything defeats the purpose of Event Management. Push back and narrow the escalation criteria.

Theme: Incident Creation and Assignment

Question: Which events should automatically create incidents in IT Service Management? Only the most critical events should auto-create incidents; others should route to dashboards or require manual investigation before incident creation.

Question: Who should be assigned to incidents created from events? If assignment is by service or infrastructure type, automate this in the workflow. If assignment requires judgment, keep incidents in a queue for manual assignment.

Question: How should we handle events for services that are not yet in our CMDB or service mapping? This answer determines whether you can automate incident assignment. If your CMDB or service map is incomplete, your escalation will be incomplete too.

Warning Sign: If your CMDB or service map cannot support the assignment rules you want to implement, you have discovered that data quality work is a prerequisite for Event Management success.

Theme: Correlation and Deduplication

Question: When the same alert arrives from multiple monitoring tools, should it create one incident or multiple? If your monitoring is redundant, you want deduplication to avoid duplicate incidents.

Question: How should we group related events from the same infrastructure problem? For example, should a disk failure that triggers multiple filesystem alerts be shown as one infrastructure problem or three separate events? This answer guides correlation rule creation.

Question: How long after the initial event should we consider subsequent similar events as part of the same incident versus separate incidents? Time-based grouping helps correlate bursts of similar events.

Warning Sign: If the team wants perfect correlation without accepting any false negatives or false positives, reset expectations. Correlation rules always involve trade-offs between grouping too much and grouping too little.

Theme: Handoff to Incident Management

Question: For events that become incidents, what information must be included in the incident? This answer determines the required field mapping from event to incident. If incidents require approval before creation, this affects automation design.

Question: What should happen when an operator manually escalates an event to an incident? Should this use automatic incident creation rules or require manual incident form completion? This answer defines whether operators have shortcuts for common situations.

Question: Who should be notified when events create incidents? This determines notification workflows and escalation paths once incidents are created.

A decision log format for workshop answers

A requirements workshop for event management produces a lot of talk and not much that can be built from. The answers are often sincere but partial, and they arrive in the order people remember them rather than the order the design needs them. The way to avoid that is to record every answer against the decision it forces, not in a notes document that nobody reopens. This section is for the facilitator who runs the sessions and the business analyst who turns the output into a design. It explains how to recognize the answers that signal a real decision, and what to write down when an answer is missing.

Running the sessions so the decisions can be recorded

The structure of each session matters as much as the questions. A session that moves from topic to topic produces a transcript, while a session that walks through one decision at a time produces a design. The sequence below is intended to be used in the room, with a scribe filling in the decision log as the discussion runs.

1. Open by reading back the decision the session is meant to reach, so the group knows when the discussion has finished.
2. Ask for the current behavior first: what happens to an event today, who sees it and what they do next.
3. Ask for the desired behavior second, and write the difference between the two as a numbered gap.
4. For each gap, ask which event attribute would let the system tell the two cases apart, because that attribute is what the rule will depend on.
5. Record the decision, its owner and the date it was agreed, and mark any decision that was deferred with the reason.
6. Close by reading back the open decisions, and confirm who will bring each one back to the group.

When the group cannot agree

Disagreement in a workshop is useful, provided it is recorded precisely. The most productive disagreements are about trade-offs, such as whether a missed event is worse than a flood of extra events. Write the trade-off as the decision, name the people with the authority to make it, and set the question aside if no one holds that authority in the room. A disagreement that is simply postponed without an owner tends to return in the testing phase, when it is far more expensive to resolve.

What if nobody can answer the escalation questions?

Treat that as a finding. It often means the escalation paths exist on paper but no one has checked them against the rota. Record the gap, then ask the on-call lead to walk through the last few real escalations. The actual sequence of events is more reliable than a description of the intended one.

Should the monitoring vendor attend the workshop?

A specialist from the monitoring team should attend for the sessions on event content and volume, because they know what each tool can and cannot send. The vendor is not needed for the decisions about routing and ownership, and including them there can make the internal group defer to the vendor’s defaults.

How do we handle questions that need data we do not have?

Record the question with the data it needs and the person who can pull it, and mark the related decision as provisional. Do not guess the answer to fill the log. A provisional decision with a named data source is far more useful at the next review than a confident-sounding entry that nobody can check.

The requirements workshop decisions article is about workshops that produce decisions, and the roles, responsibilities and RACI guidance covers assigning the owners that the log depends on. Where the answers depend on configuration data, the ITOM and CMDB alignment article covers how operational signals connect to configuration data, and the demand intake and prioritization piece helps when the workshop surfaces more requests than the first phase can carry.