ServiceNow NLU Model Explained

What is an NLU Model?

An NLU (Natural Language Understanding) model is a machine-learning algorithm trained on example user requests to help Virtual Agent classify and route incoming questions accurately. Virtual Agent uses NLU to determine what the user is asking (their intent), then routes them to the right topic, FAQ, or workflow. Without NLU training, Virtual Agent cannot reliably understand user intent and will misroute conversations, frustrating users and creating rework for your team.

How NLU Models Work on the Platform

Virtual Agent contains an NLU model for each language and channel (chat, email, phone). The model learns patterns from training examples you provide. For instance, if you train it on examples like “I forgot my password”, “I cannot log in”, “Login not working”, “I’m locked out”, and “Password reset”, the model learns these phrases express a password reset request. When a new user types “I can’t access my account”, the model recognizes it as similar to trained examples and routes it to the password reset topic with a confidence score indicating how certain it is about the classification.

NLU models work by calculating similarity scores between new user input and all trained phrases. The model returns a confidence score (0 to 1) and the best-matching intent. Confidence above 0.80 usually means the classification is reliable; below 0.50 indicates uncertainty. You configure what confidence threshold Virtual Agent requires before routing automatically versus escalating to a human or fallback handler.

Where NLU Models Live

NLU models are stored in the Platform as part of the Virtual Agent instance. Each conversation record can show the confidence score the NLU model assigned to its classification. Model performance metrics and accuracy reports are visible in Virtual Agent analytics and reporting dashboards. If your organization uses multiple Virtual Agent instances (for example, one for HR self-service, one for IT, one for Facilities), each instance has its own NLU model that trains independently and can be tuned to different vocabulary and priorities.

Worked Example: Password Reset Intent

You set up Virtual Agent for your service desk. You train the NLU model with variations of password reset requests: “reset password”, “forgotten my password”, “locked out”, “cannot log in”, “change my password”, “password expired”, and similar phrases, all tagged with the intent “password_reset”. The model learns the patterns in these phrases. When a user says “I lost my password”, the NLU model computes similarity to all trained examples and returns intent “password_reset” with a high confidence score that exceeds your configured threshold. Virtual Agent routes them to the password reset workflow without human intervention. If the user says something very different like “what is the network outage status”, the model recognizes it does not match any trained intent sufficiently and routes them to a fallback handler or human agent to avoid a wrong answer.

Common Misunderstandings

Teams often assume NLU works perfectly out of the box. It does not. The quality of your NLU depends entirely on the quality and variety of your training data. Poor training data yields poor classifications and user frustration.

Another misconception: that you train an NLU model once and forget about it. Models degrade over time as user language evolves, new intents emerge, or slang changes. Retraining periodically and reviewing misclassifications improves performance significantly.

Some believe NLU understands semantics perfectly. It does not. NLU relies on statistical patterns from training examples. If your training data is heavily skewed toward one intent, the model learns that frequency distribution rather than deep semantic understanding. This can cause misclassification of requests from underrepresented intents. Balance your training data evenly across all intents.

Related Concepts

Intent is the user’s underlying goal (password reset, incident report, FAQ lookup). Topic is the Virtual Agent node or workflow that handles that intent. Confidence score is the model’s certainty about its classification. Fallback handling routes requests the model cannot classify reliably to a human or default handler. Training data is the set of example phrases tagged with intents that the model learns from.

Training and Rebuilding Models

After adding training data, you rebuild the NLU model to incorporate new examples. Rebuild typically takes minutes and does not impact active conversations. Monitor your model’s accuracy over time using Virtual Agent analytics. If accuracy drops or you add many new intents, schedule a retraining cycle. Review low-confidence conversations and use them as new training data.

Splitting intents only where the answer differs

Many NLU problems in a service desk begin with the intent list rather than the training data. A team that creates one intent for every form in the catalog ends up with many intents whose example phrases overlap heavily, and the model spends its confidence splitting hairs between them. The discipline that helps is simple to state. Two requests deserve separate intents only when the resolution path, the owning team or the required fields differ. If a person asking about a lost laptop and a person asking about a stolen laptop both end up in the same workflow, they belong to one intent, and the workflow can branch on the detail afterwards.

Situation	Better design	Why
Two intents with the same answer and the same owner	Merge them into one intent	Overlapping examples make the model unstable between the two
One intent that leads to two very different workflows	Split it, and keep the phrases that separate the two cases	A single intent cannot route to two destinations without a second question
A rare request with few real examples	Route it to a human or to a topic with a fixed menu until examples accumulate	The model cannot learn a pattern from three phrases

A review loop for misrouted conversations

Training data is a living list, not a one-time task. The loop that keeps a model useful runs on a fixed rhythm chosen by the service owner, and it has the same five steps each time:

1. Pull the conversations where the user rejected the suggested topic, or where the conversation ended in a handover shortly after a routing decision.
2. Read each one and write down what the user actually wanted, in the user’s words rather than the team’s vocabulary.
3. Decide whether the phrase belongs to an existing intent, needs a new intent, or is simply out of scope and should go to a fallback.
4. Add the accepted phrases to the right intent, and remove any phrase that now sits in two intents.
5. Rebuild the model and compare the routing results for a fixed set of test phrases before and after the change.

Keep a list of phrases that must always route correctly, such as a password reset request phrased in several different ways, and check it after every rebuild. A change that improves one intent while breaking the test set is a regression, and it is much easier to catch when the set is written down.

Designing the fallback so it is not a dead end

The fallback path decides whether a low-confidence message becomes a helpful handover or a frustrating loop. A fallback that repeats the same menu after every unclear message teaches users to type the word agent. A better fallback offers one clarifying question with two or three concrete choices, then hands over to a person if the user still does not match. Measure how often the clarifying question resolves the conversation. If almost nothing resolves, the choices are probably written in the team’s language rather than the user’s.

When rules or a fixed menu beat NLU

Natural language understanding is not always the right front door. A small catalog with a handful of well-defined requests can be served by a fixed menu, a keyword rule or a short set of guided questions, and that route is cheaper to explain to a governance board. NLU earns its place when users describe problems in their own words and the set of possible requests is too large to menu. Before building a model, count the distinct requests the service receives over a typical period and check whether they fit on one screen. If they do, a simpler design will serve users and the team better.

Questions to ask about an existing model

• Which intents route the most conversations, and what share of those routings does the user accept?
• Which two intents are most often confused, and do they still need to be separate?
• When was the last time the test phrase set was run, and what did it show?
• Who owns the model, and who signs off a new intent before it goes live?

Frequently asked questions about NLU models

Why does a new intent sometimes steal conversations from an old one?

Its example phrases probably overlap with the old intent’s phrases. The model separates intents by pattern, so a shared word or a shared structure pulls traffic across. Remove the overlapping phrases from one side or rewrite them to reflect the difference in the request.

Can the model learn from conversations automatically?

It can learn from examples that a person has reviewed and approved, which is the safe pattern. Feeding unreviewed conversations back into training bakes in the mistakes the model already made, and the accuracy figure then looks better than the real routing quality.

What should happen to phrases in languages the model was not trained on?

They should fall through to the fallback or to a handover, not to the nearest English intent by accident. Plan language coverage explicitly, and treat each language as its own training set with its own review loop.

How do we know the threshold is set correctly?

Review a sample of routed and fallen-back conversations at each threshold you consider. The right threshold is the one where wrong routings are rare enough that the service owner accepts them, and fallbacks are not so frequent that users give up. That judgment belongs to the owner, not to a default value.

Next step

If users keep landing in the wrong place, start with the intent list rather than more training phrases.