ServiceNow AI Agents: where the support service breaks
In most IT departments, a request does not go into work immediately. First, the first-line operator reads the subject and text, manually determines the category, priority, and assignee, and only then the ticket goes to the right queue.
Manual routing eats hours for every hundred requests, and without a keyword in the subject, the ticket arrives at the wrong place — for example, to the second line, which sends it back.
The second source of losses is repetitive requests.
Password reset, access provisioning, license renewal, a question about the status of one's own ticket: these are more than half of the incoming flow, but each time the operator processes such a request anew and responds manually.
The queue grows at peak hours, the night shift remains without backup, and the second line spends time on what is resolved by an instruction.
The third failure is lost tickets at shift handover. Duty is handed over without context, the ticket hangs in an intermediate state, the user writes again and creates a duplicate.
History is blurred across several records, escalation triggers later than due, and reporting shows closed requests without reflecting tasks that simply expired by time.
All three support bottlenecks rest on one thing: the service has no automatic layer between request arrival and the assignee. This is exactly where ServiceNow AI Agents work — we analyze how this is closed and what remains with the human.
What changes after launching virtual assistants
The effect of virtual assistants is visible only in comparison, so before launch we record a baseline slice: the median response time to a request, the share of requests that reached the second line, distribution by category, and the number of manual reassignments in the group.
We take the same metrics after a month and after a quarter — otherwise the "before" and "after" figures are not comparable.
First, response time changes: the assistant responds in seconds, not in a queue for an assignee, clarifies the request, and pulls user and equipment data from record systems.
Next — unloading the first line through repetitive operations: password reset, account unlock, standard access provisioning, ticket status, step-by-step instruction. Humans are left with requests that have non-standard context.
The share of requests closed without human involvement grows in steps. First the assistant handles scenarios with an unambiguous answer, then multi-step ones, with condition checks and calls to the service catalog.
Routing errors fall: category, priority, and group are determined by the request text and catalog rules, not by the user's choice in a free field.
We also calculate the cost of error: how many requests were closed incorrectly and how many came back from the user. The history for each request in ServiceNow shows which scenario worked and where the assistant handed the dialog to an operator.
We allow a scenario into work when it produces a stable result on a labeled sample; before that, it works in suggestion mode. Reaching a plateau takes several weeks: we configure thresholds and rules until the metrics stop changing.
Modes of AI agent operation: comparison of approaches
Before launching ServiceNow AI Agents in production mode, you choose the connection scheme: it determines how much data needs to be prepared, who is responsible for answer quality, and how the agent behaves at the boundaries of its knowledge. Below are four options that we deploy on projects, with their limitations.
Comparison of options
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made out-of-the-box agents | Quick start on typical scenarios: request classification, routing, operator hints | Work only in predefined scenarios; local regulations and non-standard processes are not taken into account |
| Training on your own knowledge base | Articles, resolved incidents, and requests have accumulated — answers are needed in the company's terms | Requires cleaning and labeling of sources; on cluttered data, answer quality drops |
| External language model | Free-form wording is needed, summaries of long chats, unstructured text | Answers are less predictable; an approval loop and control of sensitive data are needed |
| Hybrid scheme with rules | Critical actions follow the procedure, while the dialog remains natural | Harder to maintain: escalation rules, confidence thresholds, and roles are maintained as a separate artifact |
The key fork is escalation rules: the agent closes typical cases itself, and at low confidence or deviation from the scenario, it hands the dialog to an operator together with the collected context.
We fix these rules before launch: what the agent does autonomously, what a human confirms, what goes immediately to the second line.
How implementation proceeds: stages of engineering work
An audit of support processes is the first and largest part of the project.
We look at what requests actually come into the system, what share is closed by a typical scenario, and where escalation to the second line is mandatory; we check the knowledge base, service catalog, and history of closed tickets.
This determines the boundaries of the agent's authority: what it closes itself and what it only suggests to the operator.
- Audit of support processes and data sources. We label requests by topic and cause, check the relevance of knowledge base articles. The output is a list of scenarios with a forecast of the automation share for each.
- System interaction scheme. We determine how agents are connected to ticket queues, the service catalog, and external systems: what is read, what is written back, where permissions to change a record are needed. We agree on the scheme before configuration.
- Scenario configuration. We assemble ServiceNow AI Agents for specific topics: operator hints, self-service on the portal, request classification and routing. We set escalation rules and points where the agent must hand the dialog to a human.
- Answer quality check. We run scenarios on real requests from the archive and on a test flow: we calculate classification accuracy, the share of accepted answers, and the number of reopened tickets. We fix the logic, not the wording.
- Handover to operation. We train the first and second lines, fix the procedure for scenario edits and the metrics dashboard. After that, the team runs the agents itself, and we join for changes and development.
Handover package: configurations, knowledge base, procedures
Implementation is considered complete not when the agent answers a test query, but when the customer can change its behavior without us.
Therefore, handover of configurations is not an archive, but a breakdown by layers: what is configured, where it lives, and by what rule it changes.
- Configured configurations — request processing scenarios, dialog branches, binding to categories and priorities, auto-reply conditions, and handover to an operator.
- Knowledge base structure — article tree, binding to request topics, source labeling: which articles the agent reads, which are closed for use.
- Integration schemes — map of connections to record systems, service catalog, email, and messengers: data flow direction and failure points.
- Access policies — roles and permissions, separation by groups and regions, rules for working with personal data, who edits scenarios and at what level.
- Escalation procedure — conditions for handing a request to a human, levels and deadlines, to whom the ticket goes when triggered.
- Instructions for operators — how to accept the dialog, what is visible in the interface, how to mark an agent error so it gets into retraining.
- Change log — what edits were made, by whom, and why, so the agent's behavior remains explainable.
Acceptance takes place on real scenarios: we run typical requests and look at what share the agent closes itself and where it goes to escalation. After that, ServiceNow AI Agents remain a manageable tool inside your team, not a contractor's black box.
Case: removed manual request routing
The customer has an internal support service with several thousand requests per month. Routing was handled manually by a dispatcher: they read the ticket text, determined the category, group, and priority.
At peak times, the shift could not keep up, some requests went to the wrong team, and about a quarter of tickets had to be reclassified again — with loss of time and a repeated notification to the user.
What changed
On top of the existing installation, we deployed ServiceNow AI Agents — ServiceNow remained the system of record, while the agents took on parsing the request text, history for the object, and configuration database data.
The agent outputs category, group, and priority, while the decision on ambiguous cases remains with a human.
For the first weeks, the layer worked in recommendation mode: the dispatcher confirmed or rejected each choice, and based on these rejections, the rules were refined point by point rather than rewritten entirely.
What happened after two months
First response time dropped from forty minutes to six: the request goes to the right queue immediately instead of waiting for triage.
The share of tickets closed without an operator reached 38% — these are typical requests for access, renewal, and standard changes, where the agent performs a check and inserts a ready answer.
Incorrect routing fell from 24% to 4%, and peak shift load no longer required an additional duty officer: work shifted from manual distribution to exception review.
What to do if support processes are already built
ServiceNow agents are embedded not instead of procedures, but on top of them — as an execution layer between the request and the operator.
Records remain in a single system: the agent writes to the same card fields as a human, so queues and history do not have to be maintained in two places. Routing, response times, and escalation rules are preserved — the executor changes for some steps.
We start with one request category where the scenario is predictable: access reset, typical equipment requests, ticket statuses. The first stage is suggestion mode: the agent prepares an answer, the operator confirms sending. Response times do not shift by a single day, but statistics on wording quality accumulate.
Roles and permissions are separated in advance. The agent receives a separate account with a limited set of actions and cannot go beyond it.
Every step is recorded in the request history, the owner of the record remains a human, and a complex case returns to the line with ready context.
Next we enable auto-close for a narrow set of scenarios and monitor three numbers: the share of requests closed without a human, first response time, and the share of returns for rework.
If returns grow, the agent is disabled by category — the procedure continues to work, and the queue does not stop.
At the start, we review the map of current procedures, select scenarios for the first wave, and criteria by which we consider the embedding successful.
Technical questions before starting work
Before the engineering stage begins, we remove doubts that usually determine whether the ServiceNow AI Agents implementation reaches productive operation.
Below are short answers on access, escalation, quality, and the knowledge base; detailed schemes are analyzed already at the design stage.
How does the agent get access to systems and data?
A separate service account with the minimum necessary permissions: read where read is enough, write only to permitted ticket fields. Secrets are stored in a secure vault, not in configuration, and every call is recorded in the log with the initiator and result. This leaves a clear answer to the question of who changed the record and on what basis.
How is handover to an operator arranged?
Handover happens by confidence threshold and by direct user request. The operator receives the entire dialog: request history, agent actions, attached data, and already collected context — there is no need to ask the client again. Reverse handover to the agent is also provided for if the question reduces to a typical scenario.
How is answer quality checked?
Before production release, we run a set of control dialogs and compare decisions with reference ones.
Then we monitor the share of correct decisions, the share of escalations, and the number of repeat requests on the same topic — error analysis is based on specific cases, not a general assessment.
What are the requirements for the knowledge base?
One article — one topic, each record has an owner and a review date, outdated content is archived rather than left in the selection. Structured fields and unambiguous wording are more important than volume: a weak article leads to a confident but incorrect answer.
Where are the boundaries of applicability?
We give the agent scenarios with a repeatable decision and clear data for verification. Unique investigations, disputed conditions, and everything that requires responsibility for the decision remain with a human — we fix this at the start, not after errors occur.
Let's discuss the task and return with an estimate and plan
We start with an analysis of the task, not a template proposal: it is important for us to see your process from the inside.
At the start, the customer needs to provide a list of typical requests and their share in the overall flow, a routing scheme and escalation rules, access to the test environment, reference data, and a dump of ticket history for past periods, as well as a person with the authority to change the procedure and accept the result.
- We conduct process analysis and fix which steps the agent closes itself and where employee approval necessarily remains.
- We draw up a stage-by-stage work plan with acceptance points — from configuring dialog scenarios and routing rules to careful release into the production environment.
- We collect source data for the start: access, service catalog structure, role-based permission separation, a test set of requests for verification.
- We determine the team composition — a dedicated ServiceNow AI Agents engineer, a process analyst, an integration engineer for external systems, and a tester.
- We discuss the estimate procedure: the volume of scenarios, the number of connection points with record systems, requirements for logging and control of agent actions.
- From the first conversation, you receive a map of automation scenarios, a solution scheme, responsibility boundaries, and risks that we see in advance.
Describe the task in a convenient format — we will return with an estimate and a plan where each stage has deadlines, requirements for your participation, and acceptance criteria.
