Why Your Search Misses Things

Almost every search box in business software works the same way. It looks for the words you typed, in fields somebody remembered to fill in.

Underneath, that means a LIKE against a description, an IN against a list of tags, and a set of tick boxes someone has to maintain. It works when the person searching uses the same words your data uses. The moment they don't, the record simply isn't found.

Worse, it is invisible. Nobody sees the results that were never returned. Your staff assume the stock isn't there, your customers assume you haven't got what they want, and everyone moves on.

A Worked Example

Take an estate agent. A buyer walks in and describes what they want, the way people actually describe things:

"We want a new build with three bedrooms and an office, somewhere for the kids to play, and it needs to be near a school."

What a traditional search does with that

It extracts what it can match. Bedrooms equals three. New build, if that's a tick box. Near a school, if somebody tagged it. Everything else is discarded, because there is no field called "somewhere for the kids to play" and there never will be.

So the buyer is shown three-bedroom new builds near schools, and the agent hopes one of them is right.

What a vector search does with it

A vector search compares meaning rather than words. "An office" is close in meaning to a study, a box room, or simply a fourth bedroom. "Somewhere for the kids to play" sits near a garden, a playroom, a garage conversion, a park at the end of the road. "Near a school" quietly implies a family, which makes a bigger kitchen and a downstairs loo matter more than they otherwise would.

The result is that a four-bedroom house with a garden and a converted garage comes back near the top, because it genuinely is what they described. Under the old search it was excluded by the very first filter, on the grounds that it had too many bedrooms.

That property was always on the books. The search was the reason nobody saw it.

It doesn't replace your filters

This is the part that gets misunderstood. A budget ceiling is not a matter of interpretation, and neither is a postcode radius or a completion date. Those stay as hard constraints, exactly as they are now. Meaning is layered on top of them, not instead of them, so you get the precision of structured data and the flexibility of natural language in the same query.

Where Else This Changes Things

The property example is easy to picture, but the same gap exists anywhere people search free text that somebody else wrote.

Recruitment

A CV that says "led a team of eight" never matches a keyword search for "management experience", so a good candidate sits unseen in a database you already paid for. Matching a CV to a job specification by meaning is the difference between a placement and a near miss.

Law Firms

Finding the clause you drafted two years ago in a matter nobody remembers the name of. Surfacing precedent by the shape of the argument rather than the words used. Triaging disclosure without reading every document twice.

Distribution & Engineering

"A bracket like this one but three millimetres wider" is a real question asked at trade counters every day, and no part number search answers it. Catalogues built from inconsistent tags and legacy SKUs are exactly where meaning-based search earns its keep.

Insurance & Broking

Comparing policy wordings that say the same thing in different language. Finding historical claims that resemble the one on your desk, so that pricing and liability decisions rest on more than the handful of cases one person happens to remember.

Housing & Local Government

"There's water coming through the ceiling in the back bedroom" needs to reach the right trade, at the right priority, without a person reading it first. Repairs triage from free text is one of the clearest wins available, and the data is already sitting there.

IT Service Desks

Years of ticket history that nobody can search usefully. An engineer facing an unfamiliar fault should be shown the three similar incidents from two years ago, not left to guess at the right keyword and conclude it has never happened before.

What's Actually Involved

The technology is the easy part. Storing vectors is a solved problem, and plenty of tools will do it. What decides whether the results are any good is everything around it.

Deciding what to embed, and at what granularity, is the first real judgement call. A whole property listing behaves very differently from its description field alone, and a hundred-page contract has to be broken up before any of it is useful. Get that wrong and the results look plausible but land in the wrong place, which is harder to diagnose than an outright failure.

Then it has to be blended with the structured filters that still matter, kept current as records change, and made fast enough that nobody notices. That last part is a database engineering problem, and it is where a search that demonstrates beautifully against ten thousand rows quietly falls over at five million.

Which is the honest reason this sits with us rather than with a search vendor. Knowing what the engine will do with your data at scale is the same skill we bring to performance tuning. The vectors are new; the discipline underneath them is not.

What You Need to Run It

Native vector support arrived in SQL Server 2025 and is available in Azure SQL. Most estates we look at are still on 2016 or 2019, so for many businesses the honest answer is that this capability comes as part of an upgrade or a move to Azure rather than on its own.

That is worth knowing early rather than late, and it is usually a better conversation than it sounds. An upgrade justified only by support dates is a grudge purchase. An upgrade that also gives your business something it demonstrably could not do before is an easier case to make, and the efficiencies found along the way often go a long way towards paying for it.

We can talk through what a migration or upgrade involves, and what it would cost you to stay where you are.

How We'd Start

Not with a proposal. With your data.

Give us an extract of the records you want searchable and we will build a working search against them, for a fixed price agreed up front. At the end of it you type a sentence into a box and watch your own catalogue answer a question it cannot answer today.

That is a far more useful basis for a decision than any document we could write. If the results are compelling, we build it out properly inside your environment. If they aren't, you have lost a fixed and known amount, and you'll know exactly why rather than wondering whether it was worth trying.

What Would Your Customers Ask For?

If you can describe the question your search can't answer today, that's enough to start a conversation.

Talk to Us

Or call us directly on 01293 988004.

Search That Understands the Question