A client once told us their search was "broken" because a guest searching for a family room for two adults and two children was shown a luxury suite that technically sleeps four — above three rooms that were a far better fit. Nothing was broken. The engine did exactly what it was told. It just had no idea what a hotel room is.
What "wrong result" really means
"The right room didn't show up first" is never one bug. It's usually the symptom of indexing the wrong thing, at the wrong granularity, with the business rules applied too late. The query is rarely the culprit. By the time a relevance complaint reaches the search box, the mistake is three steps upstream in how the data was shaped.
Most search problems are data-model problems wearing a search costume. Tuning the analyzer is treating a symptom.
Choosing the unit of search
The first real decision is what a "result" even is. A property? A room type? A room type for a specific occupancy and date range and rate plan? Hospitality teams almost always start by indexing the property and then fight the engine forever, because the thing the guest is actually choosing between is a bookable configuration, not a hotel.
We typically denormalise to the unit the guest decides on — room type × occupancy × stay — and accept the index size, because matching the index to the decision is what makes relevance tractable. Everything downstream gets simpler once the document is the answer.
If your index granularity doesn't match the decision the user is making, no amount of scoring will save you.
Constraints aren't filters
The second mistake is treating hard rules as soft filters. "Sleeps at least four" is not a nice-to-have to boost; it's a constraint that should remove non-matches entirely, before relevance is even considered. Conversely, "near the sea" is genuinely fuzzy and belongs in scoring, not in a binary filter that throws away good rooms.
Getting this split right — what is a constraint, what is a preference, what is a tiebreak — does more for perceived quality than any embedding model bolted on afterwards. We write it down explicitly with the client, because it is a business decision disguised as an engineering one, and the business is the only one who can say whether "ground floor" is a deal-breaker or a wish.
Takeaway
Search that understands a hotel room isn't a cleverer query. It's a document modelled at the granularity of the guest's actual decision, with constraints enforced as constraints and preferences scored as preferences. Do that and Elasticsearch looks like it finally understands hospitality. It doesn't — it never will — but you've handed it data shaped so it doesn't have to.