ServiceNow AI Search

AI Search indexes sources such as knowledge bases, catalog items and tables, applies relevancy and personalisation, then presents results through search profiles and result configurations attached to a portal or workspace.

The change worth understanding is what AI Search replaced. Classic text search matched the words in the query against the words in the record, so a user searching for cannot log in found nothing when the article said authentication failure. Users learned to guess the vocabulary of whoever wrote the content, and most of them stopped trying.

AI Search sits on a different foundation. It indexes content into search profiles, applies natural language processing to the query, and ranks results by relevance signals rather than by word overlap alone. The practical effect is that a question phrased the way a person would phrase it finds the article written the way a support engineer would write it.

Where it lives: indexed sources define what is searchable, search profiles group sources and apply configuration to them, and search applications bind a profile to a place users search from, such as the portal or a workspace. Three layers, and a result that appears in one place and not another is almost always a different profile rather than a broken index.

The decision to make early is what goes in the index. Knowledge articles and the service catalog are obvious. Beyond that it is a judgement: including incidents lets people find how a similar problem was solved and also exposes text written for internal readers, and including attachments makes documents findable and can surface content nobody reviewed. Every source added is content the search is willing to show somebody, so the question for each one is whether you would be comfortable with any result from it appearing in front of any user who is allowed to search.

Permissions are enforced on results, so users only see what they can already read. That is the safety net, and it is not a substitute for the judgement above, because plenty of readable content is still poor search material.

One more thing about indexing that surprises people: it is not instant. Content is indexed on a schedule, so an article published this morning may not be findable this afternoon, and a correction to a wrong article is equally delayed. Knowing the interval matters when somebody is fixing content during a major incident, because the search results will keep showing the old version until the index catches up.

An hour, and it produces a list of concrete work rather than an impression that search is poor.

1. Open the search analytics and sort by searches with no results.
2. Take the top twenty. For each, decide which of three things it is: content that does not exist, content that exists under different words, or a query nobody could answer.
3. The second category is your relevancy work. Take one and search for it yourself.
4. Find the article that should have matched. Read its title and its keywords.
5. Add a synonym for the user's phrasing, or a query rule if the phrase should always return a specific result.
6. Search again and confirm. Then check the click through rate on that query in a week.

Step two is what makes this useful. Missing content and missing vocabulary look identical in a report and need entirely different responses, and teams that skip the classification end up writing articles that already existed.

Out of box results are decent, and small tuning yields large gains. Boost recent articles, weight the title field, and add synonyms for the vocabulary your organisation uses that the article authors did not.

Three tools, and it is worth knowing which problem each one solves.

Synonyms teach the index that two phrasings mean the same thing. This is the right tool for vocabulary mismatch, which is the largest category of failed searches in most organisations. Build the list from the analytics rather than from imagination.

Query rules force a specific result or banner for a specific query. Right for a small number of high value cases: the password reset link, the current major incident, the thing everybody asks in January. Wrong as a general mechanism, because a hundred query rules is a hand maintained search engine.

Relevancy tuning and boosting adjusts how the ranking weighs signals, such as favouring recent content or a particular source. Powerful and blunt, so change one thing at a time and measure, because a boost that fixes one query usually moves a hundred others you were not watching.

Before reaching for any of the three, check the content itself. A large share of poor results comes from articles with vague titles, no keywords and bodies written for the person who solved the problem rather than the person who has it. Retitling twenty articles usually beats any amount of relevancy configuration, and it is work the knowledge team can do without touching the platform.

Search analytics tells you what the knowledge base is missing.

• Review zero result searches weekly, that is your content backlog
• Track click through, articles nobody opens are titled badly
• Retire duplicate articles, they split ranking signal
• Use spell correction and synonyms for product and internal system names

Two metrics carry most of the signal and they are often confused. Searches with no results is the obvious one, and it understates the problem. Searches with results that nobody clicked is the more important one, because the system answered confidently and the user still did not find what they wanted. A high no click rate with a low no result rate is the worst combination and the easiest to miss.

The other thing worth watching is what users do next. A search followed immediately by raising an incident is a specific, measurable failure, and the queries where that happens most are the best possible list of articles to write.

Version note: AI Search replaced the older Zing search, and on any current instance it is the default. Older documentation and older instances behave differently enough that guidance does not transfer, so check which one your instance runs before following a tuning instruction. See Now Assist and its configuration for the generative layer that sits on top of this, and Employee Center for where most users meet it.

Worth setting expectations before go live: search quality is not a project with an end date. Vocabulary changes, content ages, new services arrive, and a search tuned once degrades quietly. An hour a month against the analytics keeps it useful, and the teams whose search everybody praises are simply the ones doing that hour.

Two more signals worth reading alongside the rest. Position of the clicked result tells you whether the ranking is right: users clicking the fourth result consistently means the first three are wrong for that query. And repeat searches within a session, where somebody rephrases two or three times, marks queries where the vocabulary gap is real and the user knew what they wanted well enough to keep trying.

• Tuning without analytics. You will fix the queries you imagined, not the ones people type.
• Query rules as a general tool. They do not scale.
• Watching no results and ignoring no clicks. The second is the bigger failure.
• Indexing everything. Sources nobody should see in results dilute the ones that matter. See AI and ML integrations.

Turning it on takes an afternoon, and running the analytics loop that makes search genuinely useful is the practice the course builds.