ServiceNow Virtual Agent Use Cases for Enterprise Teams

A Virtual Agent use case is a specific, repeatable request that the chatbot can answer or move forward without a person taking the request, such as a password reset, a policy question or a catalog order. This page sets out use cases across IT, HR, facilities, procurement and finance, and the four tests to apply before building one.

Virtual Agent earns its place when it takes a specific, repeatable request away from a queue. This page lists the use cases that tend to qualify across IT service desk, HR, facilities, procurement and finance teams, the four tests a candidate should pass before it is built, where enterprise teams misjudge the value, and how to choose and prove the first two use cases.

IT Service Desk Use Cases

Password reset is one of the highest-volume help desk requests. Virtual Agent can resolve most password reset queries: users describe the issue (locked out, forgotten password, need to change password), provide verification (employee ID, last four digits of phone), and the agent either resets the password directly (for self-reset) or creates a service desk ticket with the necessary context. This reduces help desk volume significantly.

Network and VPN connectivity issues are another common case. Users describe symptoms: unable to reach a resource, VPN is disconnected, email is slow. The agent can offer immediate troubleshooting steps (restart VPN client, check network cable, restart computer). If these steps do not work, the agent creates an incident with the troubleshooting history attached, so the help desk does not repeat diagnostics. This reduces mean time to resolution.

Software license and access requests are also well-suited to Virtual Agent. A user needs a software license for Adobe Creative Suite or access to a shared folder. The agent asks clarifying questions (which team is the user in, what is their role, does their role typically need this tool), then either grants access directly (if the request matches policy) or creates a ticket with the necessary approver assigned. This reduces cycle time and human intervention.

HR and Facilities Use Cases

HR teams often field repetitive questions: what is the company holiday calendar, what is the maternity leave policy, how do I request time off? Virtual Agent can serve as an HR front-line. Users ask questions; the agent retrieves policy information from the knowledge base and serves it in conversational form. For requests that require approval (such as time off), the agent collects the details and routes the request to the appropriate manager.

Facilities requests (such as room bookings, parking allocation, equipment requests) are also suitable. Users describe what they need, the agent checks availability, and either confirms the booking immediately or escalates to the facilities team for manual handling. During office reopenings or relocations, Virtual Agent can answer common questions (what is my new desk location, when is my team’s onboarding session) and reduce the volume of inquiries to the facilities team.

Procurement and Finance Use Cases

Procurement teams handle requests for equipment, software licenses, and vendor contracts. Virtual Agent can route simple requests: users describe what they need (a laptop, a software license for a specific tool), the agent verifies budget availability, and either approves the request or routes it to procurement for review. This is especially valuable during budget season when procurement is overwhelmed.

Finance teams often field questions about expense reimbursement, budget allocation, and invoice status. Virtual Agent can surface this information: users ask about the status of their expense report, the agent retrieves it and shows when it was submitted, who is reviewing it, and when they can expect payment. For questions the agent cannot answer (such as requesting an exception to the reimbursement policy), the agent escalates to a finance manager.

Designing Effective Use Cases

Good Virtual Agent use cases share common traits: high volume (so automation saves help desk effort), clear intent (the agent can reliably understand what the user is asking), and clear resolution (the agent can provide an answer or take an action, rather than requiring extensive back-and-forth). Password resets are high volume, clear intent, and clear resolution—good use case. Complex network troubleshooting that depends on details of your infrastructure is high volume but unclear intent and unclear resolution—harder to automate fully, but Virtual Agent can still gather initial information and escalate efficiently.

Before deploying Virtual Agent for a use case, train it on existing help desk conversations and knowledge base articles. Review the training data to confirm coverage: are there articles answering the most common questions? Do previous help desk tickets show a pattern of how issues are resolved? Missing knowledge or inconsistent help desk processes make it harder for Virtual Agent to learn effective responses.

Integration With Existing Workflows

Virtual Agent triggers Flow Designer or Workflow Studio workflows, and Integration Hub connectors reach third-party systems. When the agent creates an incident or catalog request, it flows through the standard ServiceNow change management and approval processes. If a request needs approval (such as software access), the agent routes it to the appropriate approver in the platform. This means setup is simpler: you are not building custom integrations or middleware; Virtual Agent works within the ServiceNow platform.

Qualify each candidate use case with four tests before it is built

A list of possible use cases is easy to produce and hard to rank. Many enterprise teams end up choosing by who asked loudest, which is how an agent ends up handling a request that is rare, sensitive and expensive to get wrong. A short qualification step fixes this. Score each candidate on four tests: how often the request arrives, how reversible a wrong answer is, how much data the answer depends on, and how many systems the user’s next step touches. A use case that scores well on frequency and reversibility but poorly on data and integration is a good second-wave candidate. One that scores well on everything is rare, so check the frequency figure before celebrating it.

The reversibility test is the one that often changes a team’s list. Many requests that look like simple lookups turn out to change access, and access changes deserve a human check until the approval path can be automated safely.

Where enterprise teams tend to misjudge the value

Value is usually counted as the number of tickets avoided. That is only part of the picture. A use case that removes a thousand near-identical questions from the queue is valuable, but a use case that answers two hundred difficult questions badly can cost more in rework than it saves. Count the handling time of the categories that move, the rework created when the agent is wrong, and the time a human spends reading the hand-offs the agent generates. A category with a low ticket count and a long, painful handling time may be worth more than the high-volume category next to it. Knowledge-led deflection, which is a different measure, is covered in knowledge deflection for incident resolution.

A sequence for choosing the first two use cases

1. Pull the last few months of requests by category and by the wording users used, not only by the category labels the queue assigned.
2. Remove categories where the requester needs a judgment the agent cannot reproduce, and note the reason for each removal.
3. Score the remaining categories on the four tests above, using the team’s own examples for each score.
4. Check the knowledge behind the top three candidates, and remove any whose article is out of date or missing.
5. Choose one use case that is high frequency and read-only, and one that is lower frequency but reduces a known delay for the requester.
6. Write the decision with the scores and the removals, so the second wave can be argued from the same record.

Use cases that deserve a deliberate no

Some use cases should stay out of the agent for a long time. Requests that involve an exception to a policy, a complaint about a named colleague, a request that depends on a manager’s discretion, or a report of a safety concern carry a risk that a scripted conversation cannot manage well. Telling a user that a case has been received and that a person will respond is often the best outcome, and that outcome should be designed as a deliberate route rather than as a failure of the agent. Where the request is structured enough to be a catalog item, the eligibility questions in catalog request eligibility are a useful next check.

What the first use case should prove

The first use case has a job beyond saving effort. It should show the team how the content, the hand-off, the measurement and the review rhythm fit together. Choose a use case with clean content and an obvious owner, even if its volume is modest, because a clean first build makes the second wave faster. A first use case that fails for reasons nobody can diagnose tends to end the program, not just that topic. The sequencing around this choice is set out in the implementation roadmap.

Common questions about choosing use cases

Should a department-specific request go first?

Only if that department owns the content and will review the conversations. A request that is high volume but owned by nobody in particular will not get the content maintenance it needs, and the agent will drift away from the current process within months.

Is a request that is mostly a status check a good candidate?

Often yes, because it is read-only and the answer is a record. Check that the status the user sees matches what the record means, since a status shown without the right context invites a second contact.

What about requests that need an approval first?

The agent can gather the details and explain the approval path, which saves the requester a form. Leave the approval itself with the people who hold the decision until the approval routing is trusted to be reproducible by the agent.

How many live use cases can one team really review?

Run as few as the team can review. Each live use case needs an owner, a review rhythm and a set of failure cases, so the number is set by the capacity to review, not by the length of the backlog.

Next step

Scoring the candidates is quicker with real data in front of you. Bring a few months of categories and the knowledge articles behind the leading candidates.