Booking.com replaces its filter menus with natural-language search using OpenAI models

The filter was the bottleneck

Booking.com's account of this project starts with a frontend problem, not a model problem. The platform offered hundreds of filters, but those filters only helped travelers who already knew what to search for. CTO Rob Francis names the gap directly.

You might want to go on a romantic getaway, but make it cheesy. There's no filter for heart-shaped beds or Elvis impersonators. Traditional search just wasn't built to unlock that kind of intent.Montana Labs

That is a precise description of why dropdowns and checkboxes fail at discovery. Every filter is a predefined axis the product designer chose in advance. Intent that doesn't map to an existing axis has no input field. The company was strong at what Adrienne Enggist calls the last mile, moving people from search to booking, but the earlier phase where travelers are still figuring out what they want had no usable surface.

The interface change was small; the grounding was the work

The visible frontend shift is modest: a text box that accepts prompts like "Where should I go for a romantic weekend in Europe?" or "sunset views." The harder engineering sat behind it. Smart Filters and AI Review Summaries run on GPT-4o mini; Property Q&A was fine-tuned on Booking.com's user-generated content and property descriptions.

The described breakthrough is combining two data types the company had kept separate. Structured data, pricing, availability, and cancellation policies, had been tuned for years. Unstructured data, reviews and natural-language descriptions, was now layered on top so the model could generate suggestions grounded in both. A conversational input is only useful if it resolves to real inventory, and that resolution is what keeps this from being a chatbot bolted onto a catalog.

Notably, integration ran through existing APIs and data infrastructure rather than a rebuild. That is why the first AI Trip Planner prototype, capable of destination discovery and itinerary building, shipped in ten weeks after starting from the API and a hackathon.

Users learned to type differently

The strongest evidence here is not the feature list but a behavioral observation. Enggist reports that users initially treated the new input like the old one, typing "Myrtle Beach," a single destination string. Over time the queries changed shape.

But now we're seeing more detailed, conversational queries: 'I want to go to a quiet beach in September with my dog.'Montana Labs

This matters because it shows the interface change actually shifted mental models. Users only express nuanced intent once they trust the field to handle it. The company frames its reported outcomes, longer engagement on the Trip Planner, faster search via Smart Filters, fewer support contacts from Property Q&A, as measurable lift, while acknowledging long-term performance data is still being collected. The honest caveat is worth keeping in view: the durable metric so far is changed typing behavior, not audited conversion figures.

Discovery today, orchestration next

The specific implication for teams building conversational frontends is that the input box is the easy part; the payoff comes from wiring free-text intent to structured, real-time inventory and to the messier unstructured signals a catalog already contains. Booking.com had both a decade of ML infrastructure and years of reviews sitting unused for discovery until a language model could read them together.

Their stated next step raises the difficulty sharply. Enggist describes a concierge companion that rebooks a canceled flight, finds a new hotel after a delay, and suggests nearby restaurants on arrival. That moves from answering queries to taking actions across the trip, which is a different reliability and safety bar than summarizing reviews. The discovery frontend they shipped is the proof of concept; the agent-driven version is where the harder engineering still lives.