Predictive Intelligence vs an LLM for ServiceNow routing

Routing is the first AI job most ServiceNow teams want done: read a new case or incident, work out which group should own it, and put it there. ServiceNow has had a tool for this for years, Predictive Intelligence. Now every vendor pitch says a language model can do it too. Both can work. They work in very different ways, they fail in different ways, and the only way to choose is to measure them against your own data. This post explains the difference and gives you a method to measure it.

It is part of my guide to ServiceNow AI integration. Product details below were checked against ServiceNow’s documentation in October 2026; check the docs for your release, because thresholds and names change.

Two different machines

Predictive Intelligence: learns from your history

Predictive Intelligence’s classification framework trains a model on records you have already closed. You create a solution definition that names the table, the output field you want predicted (assignment group, category, priority) and the input fields it reads, which in ServiceNow’s default definitions is the short description. You add a filter, such as cases from the last 12 months, and a training frequency, from “run once” up to every 180 days.

The model learns the patterns between what people wrote and where the record ended up. It predicts one field per solution definition, so routing to a group and setting a category are two separate models. After training, the solution shows an estimated precision (how often a prediction is right) and coverage (how many records get a prediction at all) for each class.

The documentation is specific about data. The minimum for classification training is 10,000 records, the recommended range is 30,000 to 300,000, and if your filter returns more than 300,000 only the most recent 300,000 are used. Any class with fewer than 30 records in the training data is left out entirely. In the newest releases the classification framework uses pre-trained “Workflow solutions”, so the old word corpus step is no longer needed for new solutions.

A language model: follows instructions

A language model does not learn from your closed records unless you show it some. You give it the text of the new record, the list of groups with a sentence on what each one handles, and your rules (“anything mentioning a refund goes to Billing”). It reads and picks.

Inside ServiceNow that can be a custom skill built with the Now Assist Skill Kit, if your licence includes it. Outside the platform, it is an integration that reads the record through the APIs, calls a model, and writes back a suggestion. The route you take is covered in the pillar guide.

Side by side

	Predictive Intelligence	Language model
Learns from	Your closed records	Instructions and examples you write
Data needed	Thousands of correctly labelled records (10,000 minimum per the docs)	A clear description of each group, plus a test set to check it
New group added	Has no history for it until records build up and the model retrains	Works as soon as you describe the group
Bad history	Learns your mistakes faithfully	Ignores history, so old mistakes don’t carry over
Explaining a decision	Confidence scores and per-class precision; newer releases add model explainability for scripted Workflow Classification solutions	Can give a reason in words, but the reason is not proof of how it decided
Running cost shape	Part of your ServiceNow licence where included	Per call, with Now Assist entitlements or an outside model provider
Stays the same	Until retrained	Until the prompt or the model version changes

I don’t quote licence prices because they are negotiated. Ask your account team what your contract includes before you plan around either option.

Where each one fails

Predictive Intelligence fails on bad or thin history. If a third of your past incidents were reassigned twice before landing in the right group, and nobody cleaned the final value, the model learns the wrong answer for those patterns. Small groups with fewer than 30 records are dropped from training, so it will never predict them. And when your organisation changes (a team splits, a product launches), the model keeps routing to the old world until it retrains on enough new records.

A language model fails on vague descriptions and hidden rules. If your group descriptions are one word each, it guesses. If the real routing logic lives in someone’s head (“Network handles anything from the Manila office, whatever it says”), it can’t know. It can also be steered by the text it reads: a customer who writes “this is urgent, send to the director” is writing into the prompt. That is prompt injection, and I cover the defences in guardrails for AI in ServiceNow.

Both fail quietly. A wrong route looks just like a right one until the record bounces. That is why measuring matters more than choosing.

How to measure them on your own data

The method is the same for both, and it takes an afternoon in a sub-production instance.

1. Build a test set from recent records that were routed correctly. Take the last few weeks of closed incidents or cases where the assignment group did not change after the first assignment. Those are records where you know the right answer. Keep them out of anything you train on.
2. Get each candidate’s prediction for every record in the set. For Predictive Intelligence, that is the trained solution’s prediction. For a language model, run the same records through your prompt.
3. Compare group by group, not just overall. An overall score hides the problem. A model can be right most of the time because it gets the three biggest groups right and every small group wrong.
4. Look at the confident mistakes. A wrong answer with high confidence is worse than a low-confidence one, because nobody checks it.

Before any of that, look at how your groups are spread. This background script, run in sub-production, counts the last 90 days of closed incidents by assignment group:

// Closed incidents in the last 90 days, by assignment group.
var agg = new GlideAggregate('incident');
agg.addQuery('active', false);
agg.addQuery('closed_at', '>=', gs.daysAgoStart(90));
agg.addAggregate('COUNT');
agg.groupBy('assignment_group');
agg.query();
while (agg.next()) {
  gs.info(agg.assignment_group.getDisplayValue() + ': ' + agg.getAggregate('COUNT'));
}

If a handful of groups hold most of the volume and a long tail holds a few records each, you already know something: a classifier will do well on the big groups and can’t learn the tail. And the same aggregate, filtered on records whose assignment group changed, tells you how noisy your labels are. The GlideRecord query builder will write variations of this for other tables, such as sn_customerservice_case.

Which to use, and when to use both

From the trade-offs above, this is how I would decide:

• Start with Predictive Intelligence if it is in your licence, you have tens of thousands of cleanly routed records, and your groups are stable. It is built into the platform and doesn’t send case text anywhere new.
• Start with a language model if your history is thin or messy, your groups change often, or the routing depends on rules you can write down but the history doesn’t show.
• Use both when you have a few high-volume groups and a long tail. Let the classifier take the predictions it is confident about, and send everything below a confidence threshold to a language model or to a person. Each tool does what it is good at.

Whichever you pick, start in suggest mode. Show the predicted group to the person triaging and let them accept or change it. Every change is a free label that tells you where the model is wrong. Only route automatically for the groups where the measured accuracy holds up over weeks, and keep a person on the rest.

And whichever you pick, the quality of the input decides the quality of the route. If short descriptions are “issue” and “pls help”, neither machine has anything to read. My 30-minute data check shows how to measure that before you build anything.

Next steps

Routing is usually workflow number two in my list of five CSM workflows AI can take off your team’s plate, after summaries. If you want a second pair of eyes on your routing data, or a measured comparison on your own instance, that is what my ServiceNow AI integration work and the AI Readiness Audit are for. Or just tell me what you’re routing today.

Questions people ask