ServiceNow Virtual Agent: Guides and Services

What Virtual Agent Is and When to Use It

Virtual Agent is a conversational AI module in ServiceNow that handles routine service requests without human intervention. It uses machine learning to understand intent and route conversations to the right resolution or escalate to a human agent when needed. If your service desk receives hundreds of password reset, access request or status check inquiries daily, Virtual Agent can deflect many of these from your human team.

The module works as a chat interface on your employee or customer portal, or as a component you embed in other channels. Users type a question; Virtual Agent interprets the intent, runs a flow to fulfill the request, or passes the conversation to a human agent for complex issues.

Virtual Agent is most effective when deployed against a limited set of high-volume, well-defined requests. Automating 10 conversation topics that together handle most high-volume incoming tickets can be done in weeks. Trying to make Virtual Agent handle every possible request leads to complexity and poor accuracy.

Conversation Design and Intent Matching

Each Virtual Agent conversation is built around an intent. An intent is a category of user need—for example, “Reset my password,” “Report an outage,” or “Request a new laptop.” For each intent, you define example phrases a user might say, and link it to a ServiceNow flow that handles the request.

Conversation design requires understanding what users actually ask, not what you think they should ask. Run a quick analysis of your current tickets: search for keywords like “password,” “reset,” “can’t login,” “locked out.” The variation is enormous. Virtual Agent’s ML learns to recognise that “I forgot my pwd,” “I can’t get in,” and “Please enable my account” are all variations of a password reset intent.

Keep conversations short and linear. Ask users only the information you need. If Virtual Agent requires six questions before it can reset a password, users will abandon the conversation and email your team instead. Identify the minimum needed (username, phone number for verification), collect it, and act.

Integration with Fulfillment and Human Escalation

When Virtual Agent recognises an intent, it runs a flow. This flow can reset a password by calling an Active Directory integration, update a ticket status in the Incident table, or create a new Service Catalog request. The flow is the same one a human might trigger from a form, so you reuse existing integrations and avoid building duplicate logic.

Escalation happens when Virtual Agent cannot resolve the request—either because it failed to understand the intent, or because the request requires human judgment. Define escalation rules: if the user says “I don’t understand,” or if the ML confidence score drops below a threshold, hand off to a human agent. This handoff includes the conversation history so the agent can see what Virtual Agent tried.

Track Virtual Agent performance. Monitor conversation completion rates, escalation reasons, and user satisfaction scores. If many conversations about data access requests escalate to humans (indicating high escalation rates), consider whether the flow needs redesign or if that intent simply requires manual review.

Deployment and Administration

Virtual Agent runs as a widget on your Service Portal or Employee Center. You enable it at the instance level and then design the conversations it should handle. The module requires a separate license; confirm your ServiceNow contract includes Virtual Agent before proceeding.

Configuration involves creating training data for each intent, linking flows, setting escalation rules, and defining the UI. Most of this is done through a low-code builder; if you need advanced conversation logic, you can extend it with JavaScript or by calling flows with complex decision trees.

Depending on your release, Virtual Agent may integrate with Now Assist, a generative AI layer that can help summarise conversations or suggest responses. Review your release notes to understand which AI features are included.

Planning a Virtual Agent Rollout

Phase one identifies your top-volume request types and builds conversations for them. Phase two adds conversations for medium-volume requests and refines the high-volume ones based on user feedback. Later phases might add integration with external channels (Teams, Slack, web chat) or support for multiple languages.

Start small: one conversation, one high-volume intent, five people testing it. Collect feedback, refine the conversation logic, then expand to production for a department. Only then expand to the whole organisation.

Oblytech supports Virtual Agent deployment through design workshops that identify which intents to automate, flow design and integration, and performance monitoring after go-live. We build the conversation model, connect it to your existing ServiceNow workflows, and train your team to maintain and improve it.

Common Pitfalls and Tradeoffs

Overloading the first conversation with too many intents leads to poor accuracy. ML models generalise better on smaller datasets of high-quality examples. Two conversations with ten good examples each outperform one conversation with 20 examples mixing unrelated requests.

Ignoring user feedback after deployment means missing opportunities to improve. If users consistently ask questions Virtual Agent does not recognise, those are new intents to add or signs that the conversation needs clarification.

Escalating to a human but losing the conversation history is frustrating. Always ensure the flow passes the chat transcript and any collected information to the human ticket so they don’t repeat questions.

Start With the Stage You Are In

Readers arrive at this overview at different points. Some are still deciding whether a conversational channel would reduce demand on the service desk. Others have a live topic that is misunderstanding users, or a legacy chatbot that must be replaced before a contract ends. A single overview cannot answer all of those, so the table below routes each stage to the guide that handles its real problem.

If two rows fit your situation, start with the one that carries the larger risk. A failing topic that users rely on for access requests matters more than a planned improvement to a low-volume topic, even if the second is easier to fix.

A Short Readiness Check Before Any Build

Before reading further, confirm the basics. Each item below is a yes or no question. Three or more no answers mean the next step is groundwork, not configuration.

1. Can you name the five request types that generate the most contacts, from ticket or call data rather than memory?
2. Does each of those requests have a fulfillment path that a system can execute without a person in the loop?
3. Is there a named owner who can answer for each topic after go-live?
4. Is there a route to a human that works outside the hours the bot is designed for?
5. Has the license position for the channel been confirmed in writing with the contract owner?

Answers to the readiness check also tell you where to begin. A yes to the first two questions and a no to the third usually means ownership is the gap, and a topic built without an owner can drift out of date within a few release cycles. Fix that before writing more intents.

What an Overview Cannot Settle

An overview is a map, and maps do not decide routes. Two decisions in particular sit outside any single guide. The first is whether to run the channel as a replacement for an existing chatbot or as an addition beside it. The second is how much of the service desk’s budget should move to content upkeep. Both belong in a sponsor conversation, with the service owner present, before the first topic is designed.

Frequently asked questions

Which guide should a service desk manager read first?

Start with the automation opportunities guide to see which requests are candidates, then read the governance model before any topic is published. Managers who inherit a live channel should read the troubleshooting guide first, since it shows what to measure.

Is this overview the right place to compare channels?

It is not built for that. The guides here describe one channel in depth. A comparison needs criteria set by the buyer, which the automation and governance guides help you draft.

Does a readiness check need to be repeated?

Yes, whenever the request mix changes sharply, such as after a product launch or an acquisition, because the top five requests will no longer be the same five.

Each stage above has a dedicated guide that goes deeper than this overview. Start with the automation opportunities guide for scoring candidates, the best practices guide for conversation design, the governance model guide for ownership, and the troubleshooting guide for stalled conversations.

Organisations that already run a service portal can also review the service portal use cases to see which requests belong on the same front door.