OBLYTECH Logo
Enquire Now
OBLYTECH Logo

OBLYTECH / ServiceNow

ServiceNow Virtual Agent: A Guide to Conversational AI for ITSM

Users expect quick answers to routine IT questions. Phone calls and emails take time, and waiting in a queue leads to frustration and lost productivity. ServiceNow Virtual Agent answers common questions in a chat window and handles simple requests on its own.

For readers evaluating this topic and deciding what to review next.

data securityServiceNowpractical guide
Discuss this topic

Guide map

A practical framework for ServiceNow Virtual Agent.

Key Features of ServiceNow Virtual Agent:

Check how each conversation path hands off to a person, because the quality of that handoff usually decides whether users trust the assistant.

Why Choose Oblytech?

Good conversational tools earn trust by answering the simple requests fully and by handing over clearly when a question falls outside what they were built to handle.

Define the question and scope

Write down which conversations the assistant should handle and which ones should reach a person from the start, so the boundary is clear before any build.

The practical framework

Users expect quick answers to routine IT questions. Phone calls and emails take time, and waiting in a queue leads to frustration and lost productivity. ServiceNow Virtual Agent answers common questions in a chat window and handles simple requests on its own.

What is ServiceNow Virtual Agent?

ServiceNow Virtual Agent is an AI-powered chatbot that provides conversational support and automates tasks within your ServiceNow instance. It uses Natural Language Understanding (NLU) to interpret user requests and provide relevant responses, guiding users through various processes and resolving issues efficiently.

Key Features of ServiceNow Virtual Agent:

  • Natural Language Understanding (NLU):  Understands the intent behind user requests, even if they are expressed in natural language, allowing for more human-like interactions.
  • Personalized Conversations:  Provides personalized responses based on user context, such as their role, location, and previous interactions.
  • Integration with ServiceNow Workflows:  Integrates with your existing ServiceNow workflows, automating tasks like password resets, incident creation, and knowledge base searches.
  • Omnichannel Support:  Available across various channels, including web portals, mobile apps, and messaging platforms like Slack and Microsoft Teams.
  • Easy-to-Use Interface:  Provides a user-friendly interface for building and managing conversational flows, even without coding experience.

Benefits of ServiceNow Virtual Agent for ITSM

  • Enhanced User Experience:  Provides instant, personalized support, improving user satisfaction and reducing frustration.
  • Increased Efficiency:  Automates routine tasks and deflects support tickets, freeing up your IT team to focus on more complex issues.
  • Improved Productivity:  Gives users self-service options, letting them resolve issues quickly and on their own.
  • Reduced Costs:  Lowers support costs by automating tasks and reducing the need for human intervention.
  • Self-Service Access: Users can start a support conversation from a chat interface and get answers to common questions without opening a ticket.
  • Scalability:  Easily scales to handle increasing volumes of requests and interactions.

Use Cases for ServiceNow Virtual Agent in ITSM

  • Password Resets:  Automate password reset requests, reducing the burden on your IT support team.
  • Incident Creation:  Guide users through creating incidents, ensuring that all necessary information is captured for efficient resolution.
  • Knowledge Base Searches:  Help users find answers to their questions by automatically searching your knowledge base and providing relevant articles.
  • Service Catalog Requests:  Enable users to request services, such as software installations or hardware replacements, through conversational interactions.
  • Employee Onboarding:  Guide new employees through the onboarding process, providing information, resources, and access to necessary systems.

Oblytech's Expertise in ServiceNow Virtual Agent

Oblytech's team of ServiceNow experts can help you implement and optimize ServiceNow Virtual Agent for your ITSM operations. We offer:

  • Implementation and Configuration: We'll guide you through the setup and configuration of Virtual Agent, ensuring it aligns with your specific needs and workflows.
  • Conversational Flow Design: We'll help you design engaging and effective conversational flows that guide users through various processes and resolve their issues efficiently.
  • Integration with ServiceNow: We'll integrate Virtual Agent with your existing ServiceNow applications and workflows to automate tasks and improve productivity.
  • Training and Support: We provide comprehensive training and ongoing support to ensure your team can effectively manage and utilize Virtual Agent.

Why Choose Oblytech?

  • ServiceNow Expertise: Our ServiceNow team works directly on implementing and optimizing ServiceNow solutions, including Virtual Agent.
  • How it fits ITSM: Virtual Agent handles routine requests so that agents can focus on issues that need a person.
  • Client-Centric Approach:  We work closely with you to understand your unique needs and challenges, tailoring our solutions to achieve your specific goals.
  • Cost-Effective Solutions: We use our offshore team to deliver high-quality ServiceNow services at competitive rates.

Common questions

Questions teams ask about ServiceNow Virtual Agent

What should a review establish first?

Start with the question, scope, decision boundary, ownership, and evidence that the reader needs to carry into the next action.

How should the next action be chosen?

Use the article framework to identify the unresolved decision, the responsible group, and the record that will show what happened.

The documented boundary

This article is presented as a practical reference. Apply its recommendations against the specific systems, responsibilities, and evidence available in the organization being reviewed.

Deciding which requests a conversational front door should answer

The most consequential decision in a virtual agent project is which intents it is allowed to complete. Every intent carries a different risk. Answering a question from approved knowledge is low risk, because the worst outcome is an unhelpful answer that the person can escalate. Creating an incident is moderate risk, because the quality of the record depends on the questions asked. Resetting a credential or changing access is high risk, because the action affects security and must be backed by a verified identity. Treating these as one category is how a conversational tool ends up performing actions it should only have suggested.

Intent typeRisk if the answer is wrongMinimum design requirementSuitable outcome for the bot
Question answered from approved knowledgeLow: person can ask again or escalateArticle owner and review date on every answerAnswer, then offer a route to a person
Incident or request captureModerate: poor record slows the resolverMandatory fields checked before submissionCreate the record with the captured detail
Status check on an existing recordLow to moderate: wrong status causes a callIdentity confirmed before showing any recordShow status and next expected step
Credential or access changeHigh: affects security and controlVerified identity and an approved workflow behind the actionStart the controlled process, never bypass it

The right answer for a high-risk intent is often a guided start to a controlled process rather than an immediate action. The conversation can collect what the process needs, but the approval or verification remains with the workflow that already governs it.

Launching with a human route ready before the first conversation

A virtual agent that cannot hand off can be worse than no virtual agent, because the person is left in a loop. The sequence below puts the handoff in place before the bot is opened to users.

  1. Choose a small set of intents from the low-risk rows of the table, and write the answer or the captured fields for each one.
  2. Define the fallback for any message the bot does not recognize, and make the fallback offer a route to a person rather than repeating the question.
  3. Agree which team takes handoffs, what they receive, and the hours they cover, so that the bot never promises a response it cannot deliver.
  4. Pass the conversation so far into the handoff, including the intent detected and the details already captured, so that the person does not repeat themselves.
  5. Run a set of realistic test conversations, including misspellings, partial sentences and a frustrated tone, and read each transcript for the point where the person would have given up.
  6. Review unanswered messages each week, because the misses show which intents users expect that the bot does not yet have.

The handoff in step four is a detail that often determines whether users trust the tool. A person who is asked for their details again after explaining the problem may not use the bot a second time.

Failure modes that look like success in the metrics

Deflection is an easy number to report and a poor measure of value. A bot can deflect many conversations simply because people give up. Watch for the patterns that indicate this is happening.

  • Users repeat the same message several times, which suggests the intent is not recognized and the fallback is not helping.
  • Conversations end without a record and without an answer, so the person may return by phone with a more urgent problem.
  • Two intents overlap, such as a password question and an access question, and the bot picks the wrong one for a common phrasing.
  • Answers are accurate when written but stale in use, because the article behind them has not been reviewed since the process changed.

When a conversational front door is the wrong investment

If the request volume is low, or if most requests need judgment rather than a standard answer, a simpler portal with well-named services and good search may serve people better. Automation should follow the intents that repeat, not the ones that merely sound common in planning meetings.

Should the virtual agent be allowed to create requests without a person checking them?

Yes, where the required fields are validated and the request goes into a queue that a person monitors. The risk lies in requests that look complete but describe the wrong service, so the validation should check the service choice as well as the presence of fields.

How should we handle users who ask for something the bot is not designed for?

Offer the nearest correct route, such as a service or a contact option, and capture the unmatched request so that it appears in the weekly review. A polite redirect that leaves a record is better than an apology loop.

Who owns the content the bot relies on?

Each answer should have a named owner and a review date. Content that the bot presents as current, but that nobody owns, is a frequent source of wrong answers after launch.

Can the bot be used for employees and customers in the same deployment?

It can, but the audiences should have separate intents, separate identity checks and separate handoff teams, so that an employee’s access question is never answered with customer information.

Settle the intent list before building the flows

If your team is weighing which requests to automate first, the intent table and the handoff design are the decisions to settle before any conversation flow is built. The virtual agent topic explainer explains what a topic is and how it guides a conversation toward a specific task, and the self-service design for virtual agent and Now Assist deals with deciding what the conversation may do, where automation should stop and what context should transfer. Bring your intent table to a conversation with OBLYTECH before the first flow is drafted.

ServiceNow Virtual Agent names: topics, NLU intents and conversation records

ServiceNow Virtual Agent answers employees in a chat window by running a topic, a scripted conversation flow built in Virtual Agent Designer. Where an NLU model is set up, it maps what the person typed to an intent, and the intent points to the topic. Each stored conversation lands in a table you can report on.

These are common out-of-box names. Check them on your own instance and release, because menu labels, plugins and defaults change between releases.

NameWhat it is
sys_cs_topicThe table that stores Virtual Agent topics.
sys_cs_conversationThe table that stores each conversation.
Virtual Agent DesignerThe builder where topic flows are drawn and tested.
NLU WorkbenchWhere intents, sample utterances and models are managed.
kb_knowledgeThe knowledge article table a topic can search for answers.
incidentThe table a topic writes to when it logs an incident for the person.

Keeping these apart avoids a common muddle: a topic is the conversation, an intent is the label that routes into it, and the conversation record is the evidence of what happened afterwards.

Example (hypothetical): an employee types that the laptop will not join the office wireless network. The model matches an intent for network trouble, the intent starts a topic, the topic asks for the location and the device, then offers a knowledge article. If the person says the article did not help, the topic creates an incident carrying the answers already given, so nobody asks the same questions twice.

What is the difference between a topic and an intent?

An intent is a label learned from sample utterances; it recognises what the person means. A topic is the flow that runs once that meaning is recognised. Many differently worded sample utterances train one intent, and that intent starts the topic.

Where can I see what people actually said to the bot?

Conversation records are stored, so you can filter them in a list and report on them. Read a sample of the ones that ended without a useful answer regularly: they show which phrasing your intents miss and which new topic is worth building. Check retention and access settings on your release.

How long should a topic’s opening message be?

Short enough to read without scrolling in a chat window, and it should ask one thing. A long first message hides the question. Put background in a knowledge article and link to it from the topic, as in the topic explainer. The virtual agent overview and knowledge management pages give the surrounding picture.

A practical next step

Need a clearer operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. Use the OBLYTECH contact route to start the conversation.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Explore OBLYTECH services

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading