By Ahmed Alhamayda
Airline retailing has spent years treating look-to-book as a distribution metric: the number of shopping requests generated for each booking. That remains useful, but it can hide a deeper issue. High look-to-book is not created only by consumer behavior, metasearch, or seller economics. It is also shaped by architecture, specifically by when a system decides it must ask an airline, GDS, aggregator, or retailing platform to create or validate an offer.
The practical question is not simply how many searches happen before a booking. It is which interactions genuinely require live offer creation, and which can be answered from lower-consequence data without misleading the traveler.
That distinction matters more as NDC and dynamic offer creation move more shopping work toward airline retailing systems.
From ratio to resource problem
IATA’s 2019 NDC scalability study showed how wide the gap can be between direct and indirect shopping. It reported look-to-book ratios of roughly 100 to 300:1 on airline websites. For OTAs and metasearch engines, 1,000:1 was described as a best case, while ratios above 10,000:1 were more common. The same study found that allowing metasearch engines to poll an airline’s offer-management solution from the initial search could multiply look-to-book by three to five times.
The important point was not simply that the ratios were high. IATA identified cost as the most significant challenge, alongside scalability and response time. It also noted that cost falls differently in traditional distribution and NDC, with airlines potentially bearing substantial risk when their own systems must answer very large volumes of shopping queries.
IATA revisited the subject in 2025 with a white paper developed with more than 30 ecosystem participants: 14 airlines, 11 IT providers, and eight sellers, including OTAs and metasearch companies. The paper outlines nine actionable propositions and introduces complementary metrics such as Offer-to-Order and CPU-to-Order. In section 1.1, IATA reports that leading IT providers handle between 3 and 13 billion requests per day and that large metasearch engines can reach up to 100 billion daily requests. IATA notes that the market-volume figures in that passage draw on cited external market-research sources rather than an independent IATA census.
That is not just a conversion problem. It is a resource-allocation problem.
Thresholds make the economics visible
Public airline policies show that the economics are no longer abstract.
Lufthansa Group’s NDC terms state that the group covers shopping costs up to a maximum look-to-book ratio of 500:1. Above that threshold, Lufthansa reserves the right to take measures that can include deactivating access.
Qantas publishes a maximum acceptable NDC look-to-book ratio of 2,500:1. Its policy names the behaviors it is trying to reduce: robotic shopping, metasearch traffic, duplicate requests, unsupported origin-destination queries, and other non-bona-fide traffic. Qantas recommends calendar shopping, O&D validation, targeted metasearch rules, and smart caching.[4]
More importantly, Qantas describes an operational throttling mechanism. It may cap the number of NDC requests processed inside a defined time interval (its example is every five minutes) and return errors for excess requests until the window resets. That is look-to-book becoming a runtime control, not merely a monthly KPI.
Air France-KLM provides a different commercial model. Its 2025 Booking, Ticketing & ADM Policy sets a monthly threshold of 2,500 availability requests per net segment for both GDS/EDIFACT and NDC activity. If the ratio remains above the limit after a one-month remediation period, excess requests can be invoiced through an Agency Debit Memo, at a published rate of EUR 0.00001 per excess transaction.[5] At that rate the charge works less as a revenue line than as a contractual deterrent.
The thresholds differ, and they are not directly comparable: Qantas measures against completed bookings, Air France-KLM against net segments (booked segments minus cancellations), and Kenya Airways, below, against flown tickets. The logic is nonetheless consistent. Below the limit, the airline absorbs shopping within its distribution model. Beyond it, the airline can restrict access, throttle traffic, or contractually push part of the excess cost back to the seller.
Freshness by consequence
Freshness is a cost decision before it is a technical one: the fresher the answer an airline is asked to give, the more it costs to produce. A useful design principle is to stop treating information as simply “live” or “cached.”
The better question is: what is the consequence if this information is stale when the traveler acts on it?
Reference information (airport data, route relationships, product definitions, supported markets, descriptive schedule information) changes, but usually not at a pace that requires a new offer computation for every interaction.
Then there is time-bounded operational information: a recently observed schedule, a fare calendar, an availability indicator, or a previously computed shopping result. It has a freshness requirement, but “fresh” does not always mean “recomputed for every request.”
Finally, there is transactional state: an executable fare, exact seat availability, traveler-specific ancillary pricing, payment eligibility, or an offer about to be booked. Here, stale data can directly create a repricing event, booking failure, or broken customer promise.
That is freshness by consequence. The closer the traveler gets to commitment, the stricter the freshness contract should become.
Where architecture amplifies look-to-book
A traveler exploring destinations, checking whether a route exists, or browsing broad travel-date options has not expressed the same intent as a traveler selecting a specific itinerary and preparing to purchase.
If those stages all trigger the same live upstream shopping path, the architecture itself amplifies look-to-book.
One customer action can also fan out. A flexible-date search may test multiple dates. A comparison engine may query multiple providers. An aggregator may normalize several content sources. A metasearch engine may repeat that process across sellers. None of those requests is necessarily abusive; many exist because the product is trying to provide useful choice. But every additional live request has a cost somewhere in the value chain.
The objective should not be to suppress legitimate comparison. It should be to avoid recomputing information when the consequence of reuse is low, while preserving live validation where commercial accuracy matters.
Who bears the cost?
This is where technical design and commercial design meet.
IATA’s 2019 scalability work made the distinction explicit: high look-to-book affects all participants, but costs fall differently in traditional distribution and NDC. In an NDC environment, airlines can face greater exposure because their systems are answering more of the shopping traffic directly.
Lufthansa absorbs cost up to a threshold, Qantas throttles, and Air France-KLM can bill the seller. These mechanisms solve different problems. Throttling protects systems in real time. Contractual thresholds influence seller behavior over longer periods. Filtering can suppress low-value traffic before it reaches the airline. Seller-side design can avoid generating duplicate or unsupported requests in the first place.
Filtering before the airline can create measurable value
Amadeus provides a useful production example, but its provenance matters.
Amadeus, in its own 2025 Global Report, says Air France-KLM saw a 74% reduction in unproductive shopping requests after Advanced Airline Profile was introduced. The figure is vendor-published, not an independent audit. Separately, Maxime Boussard, Air France-KLM’s NDC Program Director, said the filter had blocked “more than 70%” of irrelevant traffic and allowed the airline to concentrate on more relevant shopping requests with less system strain.
But the operational lesson is strong: meaningful shopping volume can be filtered before the airline performs expensive work.
That creates several intervention points: duplicate suppression, O&D validation, smarter calendar shopping, bounded reuse of suitable responses, aggregator-side filtering, airline-side profiling, throttling, and commercial enforcement.
Cache narrowly; revalidate deliberately
Every unnecessary live shopping call is paid for by someone. Caching is often offered as the obvious solution, but undisciplined caching simply exchanges compute cost for accuracy risk.
A route list can be reused differently from a fare. A product description can have a different validity window from personalized ancillary pricing. A recently observed schedule can tolerate different staleness than an executable offer.
The design therefore needs explicit contracts: how long a response is safe to reuse; whether an older response may still be shown when an upstream source is unavailable; which attributes are allowed to be indicative; and what must be revalidated before the traveler can act.
The objective is not “cache more.” It is: do not recompute what does not need to be recomputed, and revalidate what carries transactional consequence.
Measure intent efficiency, not just traffic
Look-to-book remains useful, but it should sit beside metrics that expose where computational effort is going.
Offer-to-Order and CPU-to-Order, highlighted by IATA in 2025, move in that direction. Operators can also examine shopping requests per meaningful user action, duplicate-request rates, throttling events, the share of requests safely reused or suppressed, supplier latency, revalidation failures, and infrastructure cost per completed order.
Two sellers can have the same headline ratio and very different underlying behavior. One may be generating duplicate or unsupported requests. Another may be supporting complex comparison behavior for customers who eventually convert.
The ratio identifies pressure. It does not diagnose the source. Diagnosis requires knowing what triggered the request, what upstream work it caused, whether the response could safely have been reused, and how close the traveler was to purchase.
A concrete African example: Kenya Airways
Kenya Airways shows how explicit these limits have become outside the largest groups. Its NDC FAQ sets a permitted look-to-book ratio of 1,000:1 for travel agents and 5,000:1 for OTA agents, counted per flown ticket. The airline reports the ratio monthly for each PCC and says it will recover excess usage through Agent Debit Memos or another mutually agreed format.
The structure matches the larger carriers: a published ceiling, regular reporting, and a contractual route to recover cost. For an African carrier, that places look-to-book control in the commercial agreement rather than leaving it as an internal infrastructure expense.
What the public document does not show is how much leverage Kenya Airways has over its sellers, or how much headroom its systems have. Those are the questions that decide whether a threshold protects the airline or constrains its own sales, and they are where carrier-specific evidence is needed.
A better contract between discovery and transaction
Modern airline retailing is moving toward richer offers, more personalization, and more dynamic interaction. That makes live computation more valuable, but it also makes indiscriminate live computation more expensive.
Look-to-book will always reflect channel economics, traveler behavior, seller design, and contractual relationships. It is also a design signal: when every interaction is treated as if it were one step away from booking, the architecture itself manufactures unnecessary “looks.”
The next stage of airline retailing therefore needs more than faster APIs or higher thresholds. It needs a clearer contract between discovery, shopping, and transaction, with freshness defined by consequence and computational cost aligned more closely with intent.
Author bio
Ahmed Alhamayda is the founder of Airpiv, a Berlin-based flight-search service. He works on flight-search architecture, supplier and API reliability, data quality, and the boundary between durable discovery data and user-initiated live transactions.
