ServiceNow Virtual Agent for Technology and Software

In an engineering helpdesk, Virtual Agent is a chat front door that takes repeat requests such as password resets, licence keys and software installs, and hands anything that needs judgement to an analyst with the context already gathered. The page explains which topics to build first.

Virtual Agent in a technology company earns its place by taking predictable, high-volume requests such as password resets, licence keys and software installs away from the support queue without frustrating the engineers who use it. This page covers which request types to automate first, intent detection and vocabulary training, back-end integration, handling ambiguous requests, language and accessibility, feedback loops, staffing impact, designing topics around what the user is trying to finish, keeping security-sensitive answers out of the agent, and when a virtual agent is not the right first step.

Request Types and Automation Opportunities

Start with high-volume, low-complexity requests. Password reset requests are excellent candidates: user tries to login, enters wrong password repeatedly, requests reset, and virtual agent can walk them through self-service reset or connect them to support. License key requests follow similar patterns. Software installation requests can be scripted: user requests software, agent confirms appropriate group membership, then automates deployment.

Escalate to more complex requests only when necessary. A user troubleshooting a configuration issue might start with a virtual agent that asks clarifying questions and suggests solutions based on the answers. If no solution is found, the agent escalates to an analyst with context already gathered. This pre-filtering makes analyst work more efficient.

Natural Language Understanding and Intent Detection

Modern virtual agents use natural language processing to understand user intent from unstructured text. A user might ask “I forgot my password” or “I cannot login” or “please reset my access”. Good intent detection recognises these as password reset requests. Intent detection quality determines agent effectiveness; poor detection frustrates users and increases escalation.

Train your virtual agent on your common requests and user language. Do users say “restart my computer” or “reboot my workstation”? Do they ask for “office software” or “productive suite” or “word processor”? Tailor the agent’s vocabulary to match how your users actually speak. This improves accuracy and user experience.

Integration with Backend Systems

Virtual agents become truly powerful when connected to backend systems. When a user requests software installation, the agent can verify their group membership in your directory system, check license availability in your asset management system, then submit a service request to deployment systems. Rather than handling the request, the agent coordinates the workflow, starting the automation that would have required manual processing.

Integrate the virtual agent with identity systems (active directory), ITSM platforms, asset management, and software deployment systems. These integrations are the difference between a chatbot that answers questions and a bot that actually solves problems.

Handling Complex and Ambiguous Requests

Some requests are genuinely complex or ambiguous. A user saying “my system is slow” could mean many things: network congestion, disk full, application misbehaviour, or resource contention. A virtual agent can ask clarifying questions to narrow the problem space, but eventually escalation to an analyst might be necessary. Design your agent to escalate gracefully, providing the analyst with all context already gathered.

Do not try to automate every interaction. Virtual agents are most effective for clear-cut requests with well-defined paths to resolution. For nuanced problems requiring troubleshooting and judgment, escalate.

Language Support and Accessibility

If your organisation is multilingual, support multiple languages in your virtual agent. Train agents separately for each language since natural language patterns differ. For accessibility, support text-based interaction (easier for screen readers) and voice interaction with clear audio. Some users prefer text; some prefer voice; some need both.

Continuous Improvement and Feedback

Monitor virtual agent performance: what percentage of interactions are resolved without escalation, user satisfaction with agent interactions, and common escalation reasons. Use this data to identify opportunities: if users frequently ask the same question that the agent does not handle, add support for it. If escalation reasons show a pattern, add more intelligence to handle that scenario.

Collect user feedback on agent interactions. Did the agent understand the request? Was the solution helpful? Would the user prefer to chat with a human? Use feedback to improve response quality and accuracy.

Staffing Impact and Managed Transition

Deploying virtual agents changes support workload: fewer routine requests reaching analyst teams, more complex requests remaining. Support staff might worry about job security. Communicate that virtual agents eliminate tedious work, freeing analysts for higher-value problem-solving. In most organisations, support volume is high enough that automation unblocks capacity rather than eliminating positions.

Choosing which engineering questions a virtual agent should answer

An engineering helpdesk receives a mix of questions that look alike in the chat window but have different risk. “How do I reset my build cache” can be answered from a runbook. “Why was my deploy key revoked” touches a security control and should reach a person. A virtual agent works well when each topic it handles has a fixed answer, a known set of inputs, and no consequence that depends on who is asking. The first design task is to sort the candidate topics into those three groups, because the virtual agent’s scope is set by the sorting, not by how many articles the knowledge base holds.

Designing topics around what the user is trying to finish

Topic design goes wrong when topics mirror the knowledge base, one topic per article. Engineers do not ask for articles; they ask to finish a task, such as getting a sandbox running before a demo or recovering access to a test tenant. Write each topic around the finished task, and let it use several articles in sequence. In practice that means a topic has a clear starting utterance set, a short list of questions to narrow the intent, and an exit point that either completes the task or hands the conversation to a person with a summary. A topic that cannot name its exit point is usually a search result with a chat window in front of it.

An ordered approach to launching the first topics

1. Pull the chat transcripts and ticket titles from the last period and group them by the task the person was trying to complete, not by product area.
2. Discard any group whose correct answer depends on the account, the approver, or the state of a live system. Those belong in the table’s right-hand column.
3. For each remaining group, write the answer as a short procedure, then check it with an engineer who did not write the article.
4. Build the topic with the narrowing questions first, then the procedure, then a yes-or-no check on whether the task is finished.
5. Define the fallback for each topic: the handoff text, the destination group, and the fields the agent passes so the person picking up the conversation does not ask the same questions again.
6. Run the topics against recent real questions before publishing, and record every question it answered wrongly or too confidently.

Where the natural language layer tends to fail

Engineering language is dense with abbreviations, service names and error strings, and the intent model will often confuse two neighboring problems that share a word. A question about a failed pipeline stage and a question about a failed artifact upload may both contain the word “publish”. Train the model on the exact phrasing that appears in your own tickets, not on generic examples, and review misrouted utterances every fortnight for the first months. Pay attention to questions that contain pasted logs. Those should be routed to a person, because a virtual agent that tries to interpret a stack trace will produce confident and wrong advice.

Keeping security-sensitive answers out of the agent

A virtual agent is a public-facing surface inside the company, and anything it says can be captured in a transcript. Keep account states, credential details, internal hostnames and architecture descriptions out of its replies. Where a person asks whether their access was revoked and why, the agent should confirm that a case has been opened through the topic path and say what will happen next, not reveal the reason. Test this boundary deliberately: try the questions a curious contractor would ask, and check that the replies stay generic.

Signs the agent is earning its place

Measure whether the person finished the task, not just whether the conversation ended. Useful signals are the share of conversations that reach a successful exit point, the share of handed-over conversations that the receiving group had to re-ask questions about, and the rate at which a resolved conversation is reopened as a ticket within a short window. A high deflection rate paired with frequent reopening means the agent is closing conversations rather than solving problems.

When a virtual agent is not the right first step

If the knowledge base is out of date, an agent will faithfully repeat stale steps with complete confidence. Fix the articles first, using the knowledge management routines the team already runs. Likewise, a team with few repeat questions gains little from a conversational layer, and a catalog form or a short runbook link will serve better. Build the agent when there is a steady stream of identical questions with stable answers, and when someone owns the topics after launch.

Should the agent be able to open a catalog request directly?

It can collect the details and start the request, but the approval should happen in the catalog where the approver’s identity is verified. Presenting the request as complete before it is approved sets the wrong expectation, so the agent’s reply should say what happens next and who will decide.

What should the agent do when the same question keeps coming back from one person?

Stop answering and hand over. Repetition from one person usually means the first answer did not fit their setup, and a third automated reply will not fix that. Pass the transcript to a person with the reason for the handoff noted.

How do we keep topics current as tools change?

Assign each topic an owner who is the same person responsible for the underlying article, and review the topics when the tool it describes changes. A topic without an owner should be retired rather than left to decay.

Can the agent answer in more than one language?

Only if the topics, handoff text and fallback replies have been written and checked in each language. Machine-translated runbook steps are a poor basis for engineering instructions, because a single mistranslated command can cause real damage.

If your engineering helpdesk is repeating the same questions and the answers are already written down, scoping the topics before building anything is worth doing. The virtual agent overview covers the platform side, and the escalation and handoff guide explains the transfer step in more detail.