Why Your Intranet Search Returns Nothing Useful

A nurse types "can't chart vitals" into the intranet search box. The system returns four results: a policy on vital sign frequency for telemetry patients, a job description, a newsletter from the year before last, and something from human resources about charting overtime.

The document that answers the question is called "Flowsheet Row Unavailable — Resolution Steps." It exists. It is current. It is approved. It was written eight months ago by someone competent, and it is sitting in the same system that just failed to return it.

Nothing is broken. That is the part people find hard to accept.

The two vocabularies never meet

Search failure in a hospital is usually not an indexing problem or a permissions problem or a stale-crawler problem, though all three exist and all three get blamed first. It is a vocabulary problem, and it is structural.

Documents are written by people who know the system. They use the system's nouns, because those are the correct nouns and because using them signals competence to the reviewer. The row in the flowsheet is a flowsheet row. The failure is an unavailability. The document is titled accordingly, and the title is precise and professional and unimpeachable.

Questions are asked by people who are stuck. They use the words for the thing they are trying to do and the way it is failing them. They do not say flowsheet row, they say vitals. They do not say unavailable, they say can't, or won't let me, or it's greyed out.

Keyword search matches strings. The query string and the document string share no words. There is no clever configuration that fixes this, because the system is doing precisely what it was asked to do, and the thing it was asked to do is the wrong thing.

I find it helps to state the shape plainly: your search index knows the vocabulary of your authors, and your users are not your authors. Every hospital has this and most have concluded that their staff need better search training, which is a remarkable place to land.

Synonyms are a treadmill

The first fix everyone tries is a synonym list. Map "vitals" to "flowsheet." Map "greyed out" to "disabled." Enter them in the search admin console and the specific failure goes away.

That works, and I would not talk anyone out of doing it for the twenty worst cases. But it does not scale, for two reasons that are worth understanding before you commit somebody's time to it.

The first is combinatorial. A synonym list has to be authored, and the person authoring it has to think of the wrong words in advance. Nobody can enumerate the ways a stressed person might describe a problem. You will get the obvious ones and miss the phrasing that actually shows up, because the phrasing that actually shows up is idiosyncratic and local — an abbreviation used on one unit, a nickname for a screen that came from a trainer six years ago.

The second is maintenance. Each new document, each upgrade that renames a screen, each new local nickname adds entries. Nobody owns this. It gets built during an implementation by a project resource and is never touched again, and two years later the synonym list is describing a version of the application that no longer exists.

Synonym lists are a reasonable patch for a known top-twenty. They are not a strategy.

Semantic retrieval is a different mechanism

The thing that actually addresses vocabulary mismatch is not a better keyword engine. It is a different mechanism, and I think it is worth understanding the difference at a conceptual level, because buyers who think of it as "smarter search" evaluate it wrong.

Keyword search asks: which documents contain these words? Semantic retrieval asks: which passages mean roughly the same thing as this question? It gets there by converting both the question and the document passages into numerical representations positioned so that similar meanings end up near each other, and then looking for what is nearby. "Can't chart vitals" and "flowsheet row unavailable" land close together not because anyone mapped them, but because in ordinary language they describe the same situation.

That is genuinely different in kind, and it fails differently too, which matters. Keyword search fails by returning nothing, which is annoying but honest. Semantic retrieval fails by returning something adjacent — the passage about a different flowsheet problem, which is about the right topic and the wrong issue. A system built on it needs to be judged on whether it can tell the difference between close and correct, and whether it declines when everything it found is merely close.

Retrieval quality is where nearly all of the accuracy in these systems lives, and it is the layer buyers spend the least time evaluating. Given a correct passage, a capable model will answer well. Given a plausible but wrong passage, the same model will answer confidently and wrongly, and the failure will look like a model problem when it was decided two steps earlier.

Nothing fixes a corpus that contradicts itself

Here is the part I would not want to skip past, because it is the most common reason a retrieval project underdelivers after a good pilot.

If four documents in your corpus describe the same procedure and three of them are obsolete, better retrieval finds all four. It will return the one whose language best matches the question, which has nothing to do with which is current. You have upgraded from finding nothing to finding the wrong thing faster, and the wrong thing now arrives with a citation attached, which makes it more persuasive than it was when it was buried.

Retrieval quality and corpus quality multiply. Neither compensates for the other. An organization with excellent documentation and keyword search has a findability problem, which is frustrating and survivable. An organization with a contradictory corpus and semantic retrieval has an authority problem, which is worse, because now the system is confidently arbitrating between versions using a criterion nobody chose.

So the sequence matters. Decide what is authoritative, retire what is not, and get owners on what remains — then point retrieval at it. The order is not negotiable and every attempt I have seen to run them in parallel has ended with the retirement half unfinished.

This is the work Solution Compass expects an organization to have done, and the reason we would rather point at a curated subset than at everything reachable. Coverage is the easy number to sell and the wrong one to optimise.

One test you can run this week

Take your last hundred service desk tickets. For each one, read the user's own description of the problem — their sentence, not the analyst's categorization. Paste it verbatim into your current search box.

Count how many return the right document in the top three. Not a related document. The one that would have prevented the ticket.

Whatever number you get is your real baseline, and it is the only one worth quoting when someone asks whether search is working. Everybody's intranet search works fine when you type the title of the document you already know exists.