OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow conversational service practice

ServiceNow Now Assist and Virtual Agent self-service with a safe handoff

ServiceNow Now Assist and Virtual Agent self-service should help a person complete a defined task or reach the right human route without starting again. OBLYTECH helps organisations decide what the conversation may do, where automation should stop and what context should transfer.

Discuss ServiceNow Now Assist and self-service design

Define the task the conversation should complete

Start with a narrow task: find a service, check a request, gather information, guide a standard action or route a case. The task should have a clear success condition and a safe point where the conversation can stop. If intent is ambiguous, ask a focused question or offer a small set of recognisable paths.

Set a boundary for automated answers

Automation should stop when confidence is low, required information is missing, the request needs a decision outside the defined flow or the action could create material access, service or user-impact risk. An answer that sounds plausible is not necessarily a safe answer. Keep the human route visible when the automated boundary is reached.

Preserve context when a person takes over

The receiving agent should see the user intent, questions already asked, relevant answers, affected service or record and reason for escalation. The user should not repeat information the workflow already collected. Send a useful summary rather than an unnecessary transcript, and state what the agent must decide or do next.

Protect information during escalation

Decide what the conversational route may collect, display, store and pass to a human. Limit fields to the purpose of the request and keep sensitive data out of unnecessary summaries. Access rules still apply after escalation; a human route does not justify showing information the receiving role should not see.

Improve self-service through real conversations

Review escalated conversations for repeated confusion, missing knowledge, unclear catalogue language and requests that should have been routed earlier. A high escalation level does not by itself prove poor automation; it may show a conservative boundary or a genuine need for human judgement. Improve the task, knowledge, question sequence or ownership before adding another automated answer.

For AI controls, see ServiceNow AI Governance and Control. For a controlled pilot, review ServiceNow AI Workflow Pilot.

Discuss ServiceNow Now Assist and self-service design

Bring one conversational task, escalation boundary or context-loss problem. OBLYTECH can help define the self-service route, human checkpoint, information boundary and evidence for improvement.

Start the conversation

Designing the first few turns of a conversation before the answers

A conversational route is judged in its first minute. A person who states a clear problem and gets a sensible question back is more likely to finish the task. A person offered seven unfamiliar options will leave. The ServiceNow solutions page lists the related solution areas, and much of the design work for this route is about the opening turns: how the conversation recognizes intent, what it asks next and how it confirms that it understood. The table sets out a simple sequence for those turns and the failure each step is meant to prevent.

TurnWhat the route doesFailure it prevents
Recognize the taskMatches the request to one of a short list of tasks the route can completeAnswering a question nobody asked
Confirm the scopeRestates the task in one sentence and offers a correctionRunning the wrong workflow with confidence
Collect what is missingAsks only for the fields the workflow needs, one at a timeA long form presented as a chat
Show the next stepStates what will happen and what the person will receiveA person waiting without knowing whether anything has happened
Offer a human routeNames the group that takes over and how to reach itA dead end with no visible way out

What should carry over when a conversation reaches a person

The handover is where many conversational routes lose their value. The receiving agent often asks the user to repeat everything, which undoes the work the route did and leaves the user feeling the automation was a barrier. A useful handover contains the request in the user’s own words, the answers already collected, the record or service affected and the reason the route stopped. It should not contain the full transcript unless the receiving team needs it, because a transcript tends to hold more personal detail than the case requires.

Features that draft or summarize for the agent, such as Now Assist content generation, belong on the same side of the boundary. A generated summary is a proposal the person reviews and edits before it is relied on. It is not a record change, and the handover should show the reviewer which text was generated and which was typed by the user.

Protecting information during the conversation and after it

A conversational route can collect information the user offers without being asked. A person describing a service problem may include a bank detail, a health remark or a note about a colleague. Design should decide in advance what the route will record, what it will display back to the user and what it will pass on. Fields should be limited to the purpose of the request, and any free-text box should say clearly what the user should and should not enter.

After escalation the rules for the record still apply. A handover to a human does not extend that person’s access to information they should not see, and a summary that quotes sensitive detail can give a wider audience a view the source record would have denied.

Reading escalation data to improve the route rather than the metrics

Escalation rates are often read as a verdict on the automation. A high rate can mean the route is too cautious, that the task genuinely needs human judgment, or that the knowledge behind the answers is out of date. Each explanation calls for a different fix. Reviewing a sample of escalated conversations, grouped by the question the user was trying to answer, often shows which explanation applies. The review should look for repeated confusion, missing articles, catalog names that users do not recognize and requests that should have gone to a person at the start.

The knowledge and self-service optimization page covers that subject, and the knowledge base is often the cheapest place to fix a conversation.

Where automated answers should not go

Some requests should never receive an automated answer, however confident the route appears. Anything that changes access, releases a payment, alters a personnel record or concerns a health, safety or legal matter should move to a person at the first point the route recognizes it. The route should also stop when its confidence in the intent is low, when the information it holds is incomplete and when the user asks for a person. A route that keeps trying to answer after a request for a human has been made will be remembered for the wrong reason.

The list of excluded requests should be written by the service owner and reviewed whenever the route’s scope changes. It should be visible to the people who write knowledge articles, because an article that promises an automated outcome for an excluded request will undo the boundary. The AI governance and control page covers access, approvals, exceptions, monitoring and evidence for AI workflows.

Which tasks suit a conversational route first?

Tasks with a short, well-defined path and a clear point of success: checking the status of a known request, finding a standard service, or collecting the details for a common request. Tasks that depend on judgment or on a long history of exceptions are better left with people until the path is understood. For customer-facing routes, the customer service case routing page covers case routing in customer service.

How should the route describe itself to users?

Plainly. It should say what it can help with, that it may hand over to a person and how a person will be reached. Describing it as a full replacement for the service desk sets an expectation the route will not meet.

Does a virtual agent need its own knowledge base?

As a rule it should draw on the same knowledge as the self-service portal, with a named owner for each article. A separate, unmaintained set of answers for the route tends to contradict what users read elsewhere.

What if users keep asking for a person?

Treat that as a signal about the route, not a failure of the user. Repeated requests for a person often mean the task is outside the route’s scope or the first answer did not help. The fix belongs in the task definition or the knowledge, not in making the handover harder to reach.

Discuss a self-service route for your service desk

Bring one conversational task, the escalation boundary causing problems or a case where context was lost in the handover, and contact OBLYTECH to talk it through. The self-service route, the human checkpoint, the information boundary and the evidence needed to judge whether a change has helped are the points that conversation should settle.

Virtual Agent and Now Assist do different jobs in a self-service route

Virtual Agent runs a designed conversation: it recognizes a request, asks for missing details and completes a defined task. Now Assist generates language, such as summaries, drafts and answers composed from knowledge. Use Virtual Agent where the path is known and repeatable, and Now Assist where a person needs help reading or writing text.

The confusion usually comes from treating them as rival products. In most implementations they sit side by side. A Virtual Agent topic collects the fields and starts the workflow, while a generated summary helps the agent who receives the case. What matters is who is accountable for each output.

A rule that holds up in design reviews: if the outcome must be the same every time, give it to a designed conversation, because someone can test it and own it. If the outcome is wording a person will read, edit and decide on, generation is a reasonable fit, provided the reviewer can see what was generated.

NeedBetter fitReason
Check the status of a known requestVirtual Agent topicFixed steps that can be tested
Summarize a long case for the receiving agentNow Assist generationA reading task a person reviews
Change access or release a paymentA personNeeds approval and accountability

The design questions behind each feature are covered in the Virtual Agent optimisation service and the Now Assist consulting service. The rules for passing a conversation to a person are in the guide to Virtual Agent escalation and handoff.

Can Now Assist replace Virtual Agent topics?

Not for tasks that must run the same way every time. A topic gives a tested path with defined steps and an owner. Generated text suits drafting and summarizing, where a person reviews the result before it is relied on.

Which should a service desk switch on first?

Start with the one that has the clearer success test. In most service desks that is a Virtual Agent topic for one frequent request, because completions can be counted. Generated summaries can follow once reviewers know what good output looks like.

Do generated answers need a human check?

Yes, wherever the answer is relied on. A generated answer can read confidently and still be wrong or out of date. Show the reviewer which text was generated, keep the source article visible and keep access and payment requests with a person.

ServiceNow guides on this topic

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

Related guides

More in this section