ServiceNow Virtual Agent Requirements Workshop Questions

This page helps a team decide what the Virtual Agent will answer, through which channels, with which identity checks and where it hands off to a person. It sets out the questions that decide those points, the order to ask them in and how to record answers that are still open.

Questions on Scope and Use Cases

What are the most common questions or requests users submit today? These are good candidates for the virtual agent to handle—for example, ‘reset my password’, ‘request a laptop’, ‘check my leave balance’. How much of total support volume do these top requests represent? If they represent a significant portion, implementing a virtual agent to handle them can meaningfully reduce support volume. If the top requests represent only a small portion, virtual agent impact will be limited.

Which channels do users prefer to contact support today (email, phone, portal, Slack)? The virtual agent will likely operate in a web chat or Slack channel, so if users prefer phone support, virtual agent adoption will be lower. Plan channel strategy: should the virtual agent be available 24/7 or only during business hours? Should the virtual agent offer warm handoff to a human agent, or should it resolve issues independently?

Questions on Training and Content

Do you have knowledge articles covering the top support requests? Virtual agents are most effective when trained on accurate, up-to-date knowledge. If articles do not exist or are outdated, train the agent on them first or fix the articles before deploying the agent. What is the current state of your knowledge base: is it complete, current, and well-organized? If not, plan a knowledge refresh before or alongside virtual agent deployment.

Who owns the virtual agent’s training and improvement over time? Someone must be responsible for gathering feedback, identifying misunderstandings, and retraining the agent. If nobody owns this, the agent will degrade as the business changes.

Questions on Integration

Which ServiceNow modules should the virtual agent access? Password reset requires access to the Identity module; request fulfilment requires access to the Service Catalog; incident history requires access to the Incident module. Each integration increases complexity but also increases the agent’s value. What is the minimum viable agent: what integrations are required for launch, and what can be added later?

How should the virtual agent authenticate users? Should it ask for username and password, should it use SSO, or should it require no authentication? Requiring authentication ensures privacy but may increase user friction. No authentication is simpler but risks showing private data to the wrong person.

Questions on Handoff and Escalation

When should the virtual agent hand off to a human? For example, if a user asks a question the agent cannot answer, the agent should offer to connect them to a human support agent. If no human is available (after hours, or the queue is full), what should the agent do? Should it offer to create a request for later, or should it wait for a human to become available? Define escalation scenarios clearly.

What should happen if the virtual agent makes a mistake? For example, if it resets the wrong password, how is the error detected and corrected? Plan recovery scenarios.

Questions on Measurement and Success

What are you trying to achieve: reduce support ticket volume, improve user satisfaction, provide 24/7 support, or some combination? Define success metrics aligned with the goal. If the goal is to reduce tickets, the relevant metric is tickets avoided (requests resolved by the agent instead of submitted as tickets). If the goal is better user experience, the relevant metric is satisfaction rating.

What is the target adoption rate? What percentage of support requests should the virtual agent handle on launch, and what should it be at after one period? Realistic targets are substantial portion on launch, growing to high rates after improvement.

Questions on Risk and Guardrails

What are the risks if the virtual agent makes mistakes? For password reset, the risk is moderate (wrong user gets password reset, but it is reversible). For account provisioning, the risk is higher (wrong user is given access to sensitive data). Design guardrails: approvals, confirmations, or restrictions to prevent high-risk actions by the agent.

Should the virtual agent ever take actions (like creating incidents or approving requests), or should it only provide information and hand off for action? Design conservatively on launch: have the agent answer questions and gather information, but not take actions. As the agent matures and proves reliable, actions can be added.

Workshop Topics Checklist

• Top 10 support requests and their frequency
• Target user channels (web, Slack, Microsoft Teams)
• Knowledge base readiness and content audit
• User authentication approach
• ServiceNow integrations required on launch vs. phase 2
• Escalation and handoff workflows
• Success metrics and target adoption
• Risk assessment and guardrails
• Virtual agent ownership and governance model
• Timeline and resource requirements

Run the workshop as a decision log, not a question list

A pile of answers from a workshop is not yet a set of requirements. Answers earn their place once each one has an accountable name, a stated rationale and a list of what it closes off. Set up a simple register before the first session. Each row holds the topic, the answer given, who gave it, whether the answer was a fact or an opinion, and the follow-up that must be closed before the topic can be built. Keeping the register live during the session stops the group from agreeing things that contradict each other a few minutes later. The same discipline is described in the note on requirements workshop decisions.

The middle column is the reason to run the session at all. Many answers in a workshop sound complete. The register exposes the part that was left out.

Who needs to be in which session

One long session with everyone in the room can produce the loudest answers rather than the most accurate ones. Split the work. The people who should attend each of those sessions are described in the roles and RACI guide. Hold a short session with the service desk on the categories and the hand-off, another with the knowledge owners on the content, and a third with the security and identity owners on what the agent may see and change. Bring the three outputs together in a final session that reads only the open items in the register. A group that has heard the security answer before it discusses the topic list will ask better questions about the topic list.

• Service desk leads know the real volume and the wording users actually use. They should choose the categories.
• Knowledge owners know which articles are current. They should say which topics have usable content and which do not.
• Security and identity owners know which data is sensitive. They should set the rules for what the agent may ask for and repeat back.
• The business sponsor sets the outcome, but should not answer the content questions alone.

Questions that change the build, and how to order them

Some questions shape the whole design and should be asked first. The rest refine it. Ask the design questions in this order: which channel, which identity model, which actions are allowed, and which hand-off path. Then ask the topic questions, because the topic list is only valid once the rules above it are fixed. A topic that seems simple can become a large piece of work when the identity model requires a second check, so resolve the rules before anyone commits to a list.

1. Confirm the channels in scope and the hours each one is staffed for.
2. Agree the identity model and write down which topics it blocks until it is settled.
3. Decide the actions allowed at launch, and mark any action that needs an approval as a later wave.
4. Agree the hand-off path, including the out-of-hours behavior and the owner of the queue.
5. Choose the first topic list from the top categories, filtered by readiness of the content.
6. Record the success measures and the review rhythm, and name the person who reads the failures.

When the answers do not agree

Disagreement is a finding, not a failure of the workshop. When two owners give incompatible answers, for example one wants the agent to confirm identity by a question and another rules that out, write both positions into the register and attach the decision to a named person with a date. Do not let the group settle it by vote in the room, because the person who loses the vote will not own the outcome afterwards. The same applies to any answer that depends on a process nobody has written down yet. Record the gap, and do not build a topic on an assumption. For a wider view of how competing requests get ranked, see demand intake and prioritisation.

Frequently asked questions from the workshop

How long should the workshop take?

It should take as long as the open items require, and no longer. Sessions that run until everyone is tired can close items by default. Stop each session when the register has no more questions the attendees can answer, and schedule a second session for the rest.

Should users be asked for input before the workshop?

Yes, and in a lightweight way. A short set of real requests, pulled from the last few months of tickets, will test the room’s assumptions better than any list of categories. Keep the personal details out of the extract before it goes to the group.

What if the service desk wants everything in launch scope?

Ask which of the requested topics would be wrong to answer on a bad day. The topics that carry a high cost of error should move to a later wave, and the launch list should be the set the team can monitor and correct.

Who keeps the register after the workshop?

The person who will own the agent after launch. If that person is not yet named, the workshop has found a governance gap, and that gap should be the first item in the register.

Next step

A list of answers becomes useful once it is sorted into decided, open and conflicting items.