Look-to-book: the (old) new evil
Since the creation of NDC, Airlines have been offering access to their API for free without enforcing many restrictions. The main reason is that it encourages the adoption and usage of the API by travel agencies and other third-party developers, which can help to increase the distribution of the airline’s content and services. However, with volumes growing in the NDC world, a new issue arises; “look-to-book”.
In the late 90s and early 2000s, look to book was already a challenge, with availability queries increasing considerably as airlines started to offer direct access to availability to the GDS. This was somewhat managed over time, but now has come back in full force.
1. About look-to-book
The look-to-book ratio is a comparison between the search requests (AirShopping) versus the actual bookings. The term is an industry-specific version of the more general “conversion rate”. While airlines earn money with bookings, shopping requests cost money. Indeed, high look-to-book ratios impact both performance and costs of airlines, as they require significant resources to process large volumes of search requests.
There are two aspects which an airline must consider – security and cost. In terms of security, OWASP, a group of leading security experts, identify “unrestricted API usage” as a security risk that can “lead to DoS due to resource starvation, but it can also lead to operational costs increase” (https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/). From a cost perspective, the airlines will be paying both availability calls as well as the shopping engine consumption, which is often limited to levels which were agreed pre-NDC. This does not allow for the high look to book seen today, which can easily reach 10,000:1.
2. AirlineProfile: the mitigation step
AirlineProfile, an IATA NDC Standard message, is a way for airlines to indicate their supported itineraries to agencies. By supporting this, agencies can avoid sending shopping requests to the airline for routes it doesn’t sell.
While this does reduce the number of shopping requests, it still has a lot of limitations. It does not account for seasonal routes (all supported routes throughout the year need to be included), it requires the agency to implement it, and it still does not reduce the number of queries for routes that are sold by the airline.
Thus, while the airline profile is helpful, it will not solve the airline look to book issues.
3. Taking action
There are several actions available for airlines when it comes to look-to-book:
- Absorb the costs: Most airlines, today, pay for those shopping costs. While this is viable short-term, when it comes to very large shopping volumes, it may result in exponentially growing costs.
- Block/Throttle: By applying limits/quotas, and applying blocking or throttling in the shopping requests, it is possible to mitigate the costs. This comes with the risk of losing some sales and is not an optimal solution.
- Put a price on it: By asking the API users (aggregators, agencies) to pay for their excess usage, airlines can shift induced costs to the agencies.
To put it in more crude terms, excessive shopping queries must be blocked, or someone will pay for them.
The fact is, by implementing a pricing model for their NDC API, airlines can incentivize travel agencies and other third-party developers to use the API more responsibly and efficiently.
This can help to reduce the costs associated with high look-to-book ratios while also improving the performance of the airline’s systems.
4. Looking outside
Airlines have become API Providers, and by entering this realm, it would be wise to look at the existing giants.
Google, Microsoft, and plenty of other companies have been providing APIs for a long time now, having to deal with high volumes of search queries as well. All of those APIs have two things: usage limitations, and pricing models for users who need higher look-to-book ratios.
Some common pricing models include:
- Pay-as-you-go: This model charges users based on the number of API calls they make. It is a flexible model that allows users to pay for only what they use. An example of a pay-as-you-go API pricing model is Apigee by Google Cloud.
- Subscription-based: This model charges users a fixed fee for a certain period, during which they can make an unlimited number of API calls. This model provides more predictable revenue for the airline. An example of subscription-based pricing is Azure API Management by Microsoft.
- Transaction-based: Stripe, a payment processing platform, offers a transaction-based pricing model where users are charged a percentage of the value of each transaction processed through their API.
Ultimately, it’s up to each airline to determine the best model for their NDC API based on their specific needs and goals, as well as their partners.
Travel in Motion still believes that the API should be available at a base level for free, with restrictions on look-to-book ratios. And, for any agency or aggregator needing higher ratios, agreements should be made based on one of the previously presented models.