Look-to-book

In about three decades, the number of searches required to produce a single ticket sale has grown by a factor of 100, from roughly 100 to 200 in the early online baseline scenario to about 10,000 to 20,000 today, with AI tools now actively involved in finding and comparing flights across the web.

The numbers on the chart are not meant to be taken literally. They are rough estimates, triangulated from two independently published sources that rarely agree on anything, and consistent with OAG's own operational experience across billions of daily price points.

Sebastien Gibergues, formerly VP of digital search at Amadeus, laid out the trajectory in PhocusWire in early 2025, and Sabre arrived at almost identical figures in its "From Content Complexity to Connected Retailing" insights piece, published at the end of last year. Two of the largest GDS-adjacent companies on earth independently landing on similar numbers should tell us the trend is real.

To provide more context, here are the mechanics of each era in more detail.

As online traffic exploded over the past two decades, the web scaled through a single basic technique: caching. It means generating the page once on the server, storing the result, and serving it to every subsequent reader from memory instead of rebuilding it each time. It is the reason Wikipedia can serve billions of readers on a modest server footprint, and the reason most of the modern web survives traffic it was never architected to handle. The cache is the quiet workhorse of the open internet.

However, airline pricing cannot be cached in the same way, which is why the Look-to-Book problem is structurally harder in the travel industry than in any other sector now being reshaped by agentic AI.

The difference comes down to two properties of the underlying content.

This mismatch is the industry's own diagnosis. In October 2025, IATA published a white paper on Look-to-Book, drawing on research with 14 airlines, 11 IT providers, and 8 sellers (arguably the most comprehensive recent mapping of the problem).

Its conclusion on caching is worth quoting directly: caching "works best for standard (filed) fares, which are relatively stable, but it struggles with dynamic pricing" and with the dynamic bundles that now include ancillaries like baggage, seat selection, and lounge access.

The very product trends the travel-tech industry is investing in, such as personalisation, dynamic offers, and NDC-based retailing, are exactly the ones that make caching less useful.

• For example, a single NDC response can run up to 5 megabytes.
• A single calendar shopping request for one month can generate roughly 450 separate API calls to explore date combinations.

The cost of that computation falls squarely on the airline.

What makes the problem worse is the proliferation of caching.

Today, every major layer of the travel distribution stack runs its own cache. Metasearch platforms cache, OTAs cache, GDSs and aggregators cache, and airlines cache, and none of them talk to each other. IATA calls this the "cache to cache to cache" problem. The result is a distributed mess where stale prices at one layer pollute the next, latency compounds, and price accuracy degrades across the stack.

Travellers know the symptom even if they don't see the cause. Someone spots a tempting fare on a booking platform, clicks to confirm, and watches the price jump, or worse, finds that the flight has vanished from the results entirely. That little moment of frustration is the visible symptom of the invisible mess underneath.

The modernisation push over the last five years around NDC, dynamic pricing, personalised offers, and ancillary bundling was supposed to make airline retailing smarter and more customer-centric. And while the intention was the right one, it is also the single biggest structural force making caching less effective in the AI era we're living in today.

So what does all this mean for the future of travel-tech infrastructure?

It cannot go on as if nothing is about to change. Airline IT systems were never sized for traffic profiles that assume no peak, no trough, no sleep. But agents do not respect time zones. What used to be the off-peak baseline becomes the new operating floor. A single agentic query can inspire, evaluate, assemble, and execute in one go. The consumer sees simplicity, but beneath the surface, hundreds of calls fire across suppliers, aggregators, and APIs to produce a single deterministic outcome.

The industry is responding on two distinct levels. Both are useful, and it is worth being precise about how they differ.

The first approach is to make the existing question easier to answer.

What is the precise, bookable fare for this exact trip, right now? That question still needs to be answered millions of times a day, and vendors are racing to answer it at a lower cost.

Sabre's Mosaic Cache-powered Intelligent Shopping, launched in February 2026, is the clearest example.

• For any incoming query, a predictive algorithm decides in real time whether to return a validated result from cache or poll the airline live.
• Sabre claims a 95% alignment between cached results and live offers, sub-500ms response times, and an up to 28% reduction in look-to-book ratios in measured deployments.
• Importantly, the cache here is still serving fully bookable fares. The traveller sees a specific price that the system hopes will still be valid when they click.

Amadeus is addressing a similar problem from a different angle, using its Advanced Airline Profile filtering layer to block unproductive search traffic before it reaches airline systems, with one pilot carrier reporting that more than 70% of irrelevant requests are filtered out.

It is worth being honest about the boundaries of these approaches. Both are early-stage product launches with adoption levels unclear, so the headline performance numbers likely reflect initial deployments rather than industry-wide validation. More importantly, both operate through indirect distribution channels, most likely including EDIFACT, NDC, low-cost carrier APIs, and agency-private content. We believe neither covers airline.com fares, which is precisely where dynamic and personalised pricing is most prevalent, and where a meaningful share of consumer bookings happen, especially for the largest carriers. The slice of the problem most resistant to caching is the slice these solutions do not yet reach.

Nevertheless, these are real engineering moves by serious players, and each addresses a distinct portion of the problem. They make the existing architecture work harder and waste less. But they share the same underlying assumption that the precise, bookable fare is what should be served at every step of the traveller's journey, and the industry's job is to deliver it faster and cheaper.

The second approach questions that assumption itself.

This is the path we at OAG, especially our CEO Filip Filipov, have been arguing for publicly, and we call it indicative pricing.

The logic of indicative pricing is straightforward. For decades, travel products have been built to answer one very specific question: what is the exact price for this exact trip, right now?

That question is by no means irrelevant, but it matters much later in the traveller's journey than the industry has long assumed. When someone searches for Vienna to Tokyo, they are rarely looking for the exact fare, let's say $1,131 for a seven-day return in economy. At that stage, the decision is not yet formed to that level of detail.

Instead, the traveller is trying to understand something more approximate and far more important:

• Is this a $1,000 trip or a $3,000 trip?
• Is July broadly cheaper than June?
• Does extending the stay materially change the cost profile?

The traveller is not yet selecting. They are exploring.

Indicative pricing provides a rough price estimate at this early stage of the exploration phase. It provides a range, a sense of magnitude, and a directional understanding of cost. And not just of the base fare, but of the full offer, which today increasingly includes baggage, seat selection, upgrades, and other ancillaries that shape the real price of travel. None of those numbers need to be exact to be useful. They need to be directionally right (and credible).

This does not, on its own, reduce look-to-book volumes. Agents will still run massive numbers of queries on the traveller's behalf, and the ratios projected earlier in this piece will still climb. What changes is the cost of those queries.

Indicative pricing breaks the one-to-one link between a search and a full, personalised offer computation.

• A bookable fare quote must be true to the cent, right now, for this specific traveller, which is exactly what makes airline pricing impossible to cache in the conventional sense.
• An indicative range does not carry that burden. It can be served from a cache that is hours old, aggregated across thousands of travellers asking the same broad question rather than recomputed for each one, and answered without firing the full offer-management pipeline behind the scenes.
• The expensive computation (the part that actually strains the infrastructure) gets pushed later in the funnel, to the moment of real booking intent, where it belongs.

That shift also requires updating how the industry measures the problem. Look-to-Book was conceived in a world where every search triggered roughly the same expensive computation behind the scenes, so query volume and infrastructure cost moved together. Under indicative pricing, those two come apart. A 200,000:1 look-to-book ratio, with 99% of queries served from cheap cached ranges, costs the industry dramatically less than a 20,000:1 ratio, in which every query fires the full offer pipeline. IATA's October 2025 white paper makes this argument, proposing complementary metrics that reflect computational reality rather than raw volume, for example:

• Offer-to-Order tracks the number of full offers generated per confirmed booking.
• CPU-to-Order tracks the total computing effort per booking.

Both are likely better signals of where the real strain sits, and both are likely to drop sharply in a world where indicative pricing absorbs the exploratory phase.

Indicative pricing also reorders the entire experience.

• It provides orientation at the top of the funnel.
• Product and value shape the decision in the middle.
• Booking then becomes the outcome rather than the opening move.

A $5 cheaper fare with a seven-hour layover, in this frame, is clickbait of the past. It is not relevant to a traveller who has the confidence of a well-formed choice.

None of this means that indicative pricing replaces the work of smart caching. The two address different parts of the same problem.

• Smart caching like SabreMosaic makes bookable shopping cheaper to serve in the middle and lower funnel, where the traveller is converging on a specific option.
• Indicative pricing reshapes the top of the funnel, where the traveller is still orienting and bookable precision is not yet needed.
• A mature travel-tech infrastructure probably needs both.

But whatever combination the industry settles on, the Look-to-Book problem is the first visible crack in an architecture that was never designed for what is coming next. No single vendor, no single GDS, no single metasearch platform, and no single airline can resolve it in isolation. The industry has coordinated before on schedules, baggage standards, codeshares, and NDC, and it will need to coordinate again.