ServiceNow Now Assist for ITSM Requirements Workshop Questions

What Now Assist for ITSM Enables

Now Assist for ITSM uses generative AI to augment incident handling, problem investigation, and change management. The capability can auto-generate incident descriptions, suggest next steps for investigation, recommend knowledge articles, and generate change summaries. The effectiveness of Now Assist depends on how the deployment is planned and how the AI is configured for the organisation’s workflows.

Requirements Workshop Topics and Question Bank

An effective requirements workshop covers these themes. For incident handling, ask: Which incident types should Now Assist provide recommendations? Should the AI auto-generate incident summaries or should humans review? What is the acceptable accuracy threshold for AI-generated content? For problem investigation, ask: What data sources should the AI consult when investigating root cause? Should the AI recommend knowledge articles automatically or wait for human request? What level of AI confidence warrants auto-suggestion?

For change management, ask: Should Now Assist auto-generate change descriptions from change request details? Should the AI identify potential impacts automatically or only when requested? What risk level warrants human review rather than AI recommendation?

Capability Assessment Questions

Before deploying Now Assist, assess current state. Ask: How consistent are incident descriptions today? Do support staff have time to investigate thoroughly or are they rushing through tickets? What percentage of incidents require knowledge article consultation? How are changes currently documented? Are change impacts assessed consistently?

Assessment also addresses data quality: Is incident and change data structured and complete enough for AI to learn patterns from? Are field values consistent enough that AI can identify relationships? If data quality is poor, Now Assist effectiveness will be limited.

Use Case Validation

Validate each proposed use case before full deployment. For incident auto-summary, start with a pilot on a subset of incidents, have humans review the summaries, and collect feedback on accuracy and usefulness. For knowledge recommendations, track whether recommended articles are actually helpful to the support team.

Pilot deployments allow tuning before full rollout and build confidence in AI-generated content before making it a standard part of workflows.

Data Preparation and Training

Now Assist learns from historical data. The organisation should provide clean, representative incident and change data covering various scenarios. Training data should include incidents where resolution went well and incidents where there were complications, so the AI learns both typical and edge cases.

What Answers Change in Design

If the organisation prioritises fast first-contact resolution, Now Assist should be configured to provide immediate knowledge recommendations and suggested next steps. If data quality is poor, Now Assist deployment should be limited to areas with structured data until quality improves. If the organisation has highly specialised incidents that require domain expertise, Now Assist should recommend human review rather than attempt automated resolution.

Warning Signs During Workshops

If stakeholders express concern that the AI will make mistakes, that concern is valid: plan for human review and continuous improvement rather than full automation. If support staff worry that Now Assist will reduce their autonomy, address their concerns by explaining how the tool augments their work. If requirements conflict between teams—one team wants auto-action while another wants human review—that conflict must be resolved before implementation.

Change Management for AI Deployment

When Now Assist changes how work is done—automating parts of incident description or auto-suggesting assignments—teams need time to adjust. Change management should address training on AI capabilities and managing expectations about AI reliability and limitations.

Model Training and Data Requirements

Now Assist requires training data to learn patterns from. Historical incident data should be reviewed for quality before using it to train the model. Training data should be representative of real incidents the team handles. If training data is skewed toward a particular type of incident, the model will be better at handling that type but may mishandle edge cases. Include negative examples (incidents handled poorly or where problems occurred) so the AI learns not to replicate bad outcomes.

Turn each workshop answer into a configuration decision

A workshop produces opinions. The build team needs decisions: a named setting, a named owner, and the condition under which the setting changes. Much of the value of running the workshop comes from translating what people said into that shape before the session closes. The table shows how the answers that come up most often convert into decisions, and what evidence should sit behind each one.

Run the sessions in an order that exposes conflicts early

The order of the sessions matters more than the length of any one of them. Conflicts that surface late tend to reopen decisions that were already treated as settled, so sequence the room to find them while there is still time to resolve them.

1. Begin with the data owners rather than the enthusiasts. Ask which historical fields they trust, which they would not use to train anything, and which records they would exclude outright. This sets the boundary for every later decision.
2. Walk through three recent records from the moment they were raised to closure. At each step, ask what a helpful suggestion would have looked like and whether the person who made the decision would have wanted to see it.
3. Turn every proposed automation into one sentence that names a trigger, an output and the person who can stop it. Until a proposal reads that way, it is still a wish.
4. Hold the security and audit questions in a separate session with those roles present. Data access negotiated as a side effect of a feature debate is a common source of later rework.
5. Score each proposal on reversibility. A suggestion that an agent can ignore can start wide. An action that changes an assignment group on a major incident should start narrow and widen only after evidence.
6. Read the decision log back to the room and ask each owner to say yes or no to their own line. Silence in a workshop is not agreement, and it is the first thing that gets reopened.

Requirements that are assumptions in disguise

Several statements sound like requirements but are really guesses about the data or the people. “Our categories are consistent” is a common one. Test it with a random sample of closed records and check whether the same kind of problem carries the same category across teams. “Knowledge is current” can be tested by looking at the review dates of the articles the team already links most often, not the articles it was proud of at the start of the year. The knowledge management hub is the guide to check for how those review cycles are organized before the assistant depends on them. “The team will accept suggestions” should be tested with the two most skeptical people in the room, because their use of the tool can predict the rest of the floor. Each assumption belongs in the risk register with an owner and a test date, not in the requirements section where it looks settled. Access questions raised by those assumptions are easier to settle in the access guide for Now Assist, so they are not settled by default in a feature debate.

Answers that change the design, not just the wording

Some questions look like housekeeping but change how the feature is built. The table below lists four of them and what each answer does to the design. The enterprise use cases for Now Assist give a longer list of candidate decisions if the room needs prompting.

What you bring out of the room matters as much as what happens in it. The output should be the decision log, the list of open assumptions with owners, and a short statement of which items are in the first release. When the room disagrees about the current state, a written process baseline is a useful reference.

Practical questions raised after the workshop

How many workshops are enough?

Often three: one for the data owners, one for the process owners, and one for security and audit, followed by a single review session that reads back the decision log. Extra workshops rarely add decisions. They often add opinions. Stop when every open item has an owner and a date, even if some of those dates are later than people wanted.

Who should keep the decision log?

Someone outside the build team, typically a business analyst or a delegate of the service owner. Build teams tend to log what they can build rather than what was decided, and that difference becomes important when an auditor asks why a setting was chosen.

Should the vendor attend the requirements sessions?

Invite the vendor for questions about what a feature does, and keep the questions about what the feature should do inside the organization. A product team can describe a capability precisely. Only your own service owners can say which capability is appropriate for which records.

What if the business wants everything in the first release?

Ask which two items would stop a live service if they failed, and place only those in the first release. Everything else goes into a ranked backlog, with the evidence each item still needs before it can be built. That is often enough to end the argument without refusing anyone.