WT Airlines Proposal

[Hynek Urban]

Hello,

we are happy to announce the initial draft of the Winding Tree airlines proof-of-concept proposal; you can find it here:

https://github.com/windingtree/wtips/blob/master/WTips/wtip-003.md

Please refer to the proposal itself for further details, motivation, etc. We will appreciate any kind of feedback - feel free to post it here on the mailing list or even as issues or pull requests directly on GitHub.

Once we feel that a consensus has been reached with regard to the proposal, we will start with the actual implementation of all necessary parts.

Thanks,

Hynek

P.S.: You may notice that we have adopted an "improvement proposal" framework to guide further enhancements of the WT platform. You can read more about it here: https://github.com/windingtree/wtips

--

Hynek Urban @ fragaria.cz +420 733 600 214 www twitter blog

[Florian Pautot]

Winding Tree Airline proposition

HI,

Thanks for the proposal. I got a few questions and comments about it.

Regarding the NDC, you say that you see it as a possibility, but not necessarily as an end. 

In my opinion, there are no other viable options. If you want to handle the availability, fares, and bookings on WT same as the hotels instead of doing it on the airlines sides, you will just add tremendous complexity and integration issues. And every airlines have their own systems, so you will never have one common solution for every one.

You should already integrate the NDC as a component of the architecture, even for the POC.

NDC provides a standard for accessing and handling airlines offers and bookings, it will greatly simplify the processes and the architecture if you decide to use it.

The only issue with NDC is that it provides a standard for inputs and outputs, but not for the way to call the actual NDC API. Luckily, airlines are often part of bigger corporations such as Air France-KLM, Lufthansa Group, and IAG, providing one entry point for all the group airlines.

Architecture

• On the architecture and components parts, you don’t talk about the search API, will it be also be extended for the airlines ?

Data structure

• What do you mean by static data and services ? What data will be stored in there ? By Services I guess you mean inventory, booking etc
• For flights data, I will take the side of the NDC, and I don’t think it would be viable to work this way. You shouldn’t store any data related to flights or fare on WT, because it would be very complicated to stay synchronized with airlines data. Every airlines will have its own format, and if you don’t take NDC, you will have a huge integration work to do to translate airlines formats to your WT format. In my opinion you should design your data structure according to NDC services : 

• OFFERS (AIRSHOPPING)
• FLIGHTPRICE
• ORDERCREATE
• AIR DOC ISSUE/ORDER VIEW
• ORDER RETRIEVE
• ORDER LIST
• ITINERARY RESHOP
• ORDER CHANGE
• ORDER CANCEL

More information here : https://developer.airfranceklm.com/ndc_starting_guide

During the hackathon, we proposed an architecture using NDC. The data stored on WT were the data required to be able to call the different airline NDC API endpoints : URL, heads, request params, etc …

For us it was the simplest solution to provide an airline agnostic decentralized solution reusing your components.

Here is a diagram of the proposed architecture :  

(See "global architecture.pdf")

And here is an example of what the data structure stored in Swarm would look like: 

(See "data structure.png")

Thanks to this, you could generate the configuration on the fly based on the airlines registered on the WT index, and this configuration would be airline agnostic. 

The only issue is how to store the security data encrypted so no one can access it, because WT will need to have tokens for each NDC.

Example integration

• What would be the WT adapter ? Could it be NDC in that case ?
• What exactly will be stored on swarm ?
• What is the data consumer in that case ? One of your API/JS lib ? A client application ?

Booking API

As it is, I don’t see any problem. The thing is , if you want to use NDC, you will need to change it, because the booking process will be a bit different.

First you need to call AirShopping to get an offer. Once you selected the offer, you need to pass this Offer ID with the passenger information.

Based on AFKL NDC documentation, here is what the process would look like :

 

(See "ndc process.pdf")

So here are my comments, looking forward to here your feedbacks.

Florian

Dev Air France KLM

[Hynek Urban]

Hi Florian,

thank you for this well thought-out reply, we appreciate it a lot!

We have seen what you created during the hackathon and we understand what you propose - there has been a lively internal discussion about the two main approaches (WT hosting all the data versus WT only being an index of NDC-compatible APIs). I fully understand why the latter one might be more feasible from a practical point of view. However, aside from purely practical ones, there are also principal considerations to be taken into account: the main argument against a fully NDC-based architecture being (lack of) openness.

There is a fundamental difference between having the data stored on the WT platform, in a decentralized fashion, available to anyone to process them however they want it - and having them behind NDC gateways, available only by small chunks on request. I think you have touched this fundamental difference yourself in your remark about "storing the security data encrypted so no one can access it" which goes contrary to the self-appointed WT mission of building a system that is truly decentralized, with no central guards, owners or middlemen that cannot be bypassed.

I'm very glad you have presented the alternative, though, as I expect more discussion to take place around this - I would personally be very interested in a reply by Jakub and Robin to this :)

Now to answer your specific questions:

- search api should certainly be integrated as well, just not necessarily in the first step

- "static data" is data that is hardly ever changed, such as a name of the airline

- "Services" was supposed to mean "Airline services"; in other words, it's the various "flight numbers", such as AA123, BB456, etc. This document would then contain information for these services (e.g. the flight segments they are composed of). The "Flights" document would then show the actual individual instances of flights (e.g. available seats for the flight AA123 that departs on Monday 26.11.2018 at 13:00).

From you question, I can already see that "Services" is a misleading name for this. We will try to find something more idiomatic.

- "What would be the WT adapter ? Could it be NDC in that case ?" - Yes, a WT Adapter could be a thin layer between NDC and the outside world that would translate the NDC data structure to WT data structure, transparently handling the security credentials in the process.

- On swarm, anything can be stored that a particular user/airline deems appropriate for this storage. In our example, just the data root would be stored there (i.e. a list of references to the other documents) because that's a piece of data that hardly ever changes (so the relatively high swarm latency for write is not an issue).

- "What is the data consumer?" - in the spirit of Winding Tree, anyone could be a data consumer. It could for instance be a backend of a website that sells flight tickets. They could use wt-js-libs to consume the data, but they could also simply use their own way of consuming the data (as the ways of accessing it are known). Another example of a data consumer could be an instance of the read API.

I hope I have answered your questions. Thanks again for you input!

All the best,

Hynek

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/23930c2c-d3e2-40c1-a015-c318e4a87d93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Pautot]

Hi Hynek,
Thanks for the detailed answers.
I understand your position. It is clearly not the easiest one, but I see why you want to stand by it.
On the other hand, I don't really feel like using NDC would prevent you from being decentralized and open, because at some point you will have to access the airlines content, and on this, it will never be open because it will be managed by the airline, and they won't allow it.

But as you said, using the NDC and their access tokens goes against your principle. We could go around it though. We could imagine a way where it wouldn't be stored but dynamically added.
That way you could provide your version of the platform, but if someone would run its own version, he could provide its own set of access tokens, it would be still open and decentralized.

On the other side, as I discussed with Augusto this afternoon, there may be some issues with the IATA license for NDC solution. We will try to look into it.

The thing with airlines is that you have a a lot of legal actors and organizations defining and standardizing the market, and most of the time you have to work with them if you don't want to be limited. I understand your will to be open and decentralized, but you will maybe need to do some compromises on some aspects to be able to be fully integrated with all the stakeholders.

One other point, you should focus on giving the smallest amount of actions and components on the airlines side if you want an easy and quick onboarding. And using the NDC makes it easy on this, because the component already exists and the airlines don't have anything to do to be integrated to your solution, except registering to the WT airline index for example.

Looking forward to hear your feedbacks :)
Have a great day/night.
Florian

[Karel Alvarez]

Hi 

Just curious, and to the point of openness that this community abides by, I would like to know what are the issues referred to by this comment:

"there may be some issues with the IATA license for NDC solution."

As far as I can tell, there is a very open terms and condition agreement to download the NDC docs, which of course I did not read, curious to learn what is keeping people away. I also think NDC might be the key to bring WT to reality in a short term and would also like to help adopt NDC.

I might see some people from IATA at the end of this week and can bring it up to them...

Augusto, feel free to reply here... saludos!

cheers

Karel Alvarez

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/6f609a5e-cb3e-4af4-a94d-d0f488d10bdf%40googlegroups.com.

[Hynek Urban]

Hi,

to briefly answer Karel's question - in my view, the NDC standard is not open because, according to its license, it cannot be freely redistributed. In some of the possible scenarios of WT's NDC usage, that could be an issue (e.g. it could make it hard for us to publicly document our own interface).

If we were clever about it, we could probably work around this limitation. However, given that at its core, Winding Tree's main focus are open protocols usable by anyone, I'm not sure if relying heavily on NDC would fit the bill (and not just because of the license). On the other hand, the practicality of using something that's already established is obvious.

In other words, there are two very different competing visions of WT's airline model: a) NDC-based and b) fully open. This proposal is detailing the fully open one. If we were to go the other route, the proposal would have to look very differently. Hopefully, the other guys from Winding Tree will chime in and join the public discussion on this :)

In any case, thanks a lot for your input!

All the best,
Hynek

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAPdq_aa19Q0gV9qV9u52eb6ruNKb6zkM8w0CHPjZetR9LBNBfg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Karel Alvarez]

Hi

I like this thread, the collaboration, so, in that spirit:

I actually read the license now, and am not a lawyer, but the way I understand it, the restriction for redistribution the documents do not apply to anything WT wants to use, maybe I am missing something: 

"2.1 License. Licensor hereby grants to Licensee and its Affiliates a non-exclusive, transferable, sub-licensable, royalty-free worldwide license to (use the Specifications for the purpose of developing, implementing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Licensee’s products or services implementing in whole or in part the Specifications, in all cases subject to the conditions set forth in this License.

2.2 Restrictions. Licensee and its Affiliates shall not publish, sell, sublicense, redistribute or otherwise transfer or make available the Specifications or any of their rights under this License to any third party. However, Licensee and its Affiliates may sublicense the Specifications to their End Users for sole the purpose of exercising their rights under Section 2.1 above, but only to the extent necessary for such purpose and strictly in compliance with the terms and conditions of this License."

I think it would be really interesting to hear from airlines if they are willing to:

-invest in yet another the technology channel to get to the market, after they took years to get to NDC

-provide ALL their data, including availability, CRM, private data (not as services, but the actual raw data) in the open for all to see, I understand this is what WT thinks should be done, please correct me...

-provide their business functions/contracts in the open for all to inspect (as smart contracts) including refunds, but also yield management etc.

Maybe a reality check would help educate me... please if you are reading this and work for an airline, comment here.

thanks

Karel

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAFEpYkR5hhWxUnFddxfhnw3LDn68AsqxO%2Bx%2Bk2ff7SBV9LeyAg%40mail.gmail.com.

[alex.me...@windingtree.com]

IMO: NDC is expected future, airlines are going to accept it, but not every company happy with it. 

And if Winding Tree can "upgrade" NDC-related processes, make usage and distribution via NDC more convenient, then WT will be met by the industry much more friendly than with any new standards

[Mathieu Tahon]

Hello,

I think indeed here there is a major difference between hotels and airlines.

Airlines are operating with very low margins and a seat in a plane is a very scarce resource. There are many reasons for an airline not to advertise the full inventory availability: Revenue Management strategies (like overbookings or closure of lower fare classes when the demand is raising, bidding for upgrades), competition with other airlines on the same route, .. 

Currently in a GDS the availability for a booking class is always returned to the travel agent with a number between 0 and maximum 9 (9 meaning there are at least 9 seats available, if you want more than 9 it is a group booking which is another process). This is a mechanism to avoid full disclosure of the inventory. 

Bottom line: Regardless of the protocol to access the inventory (NDC or other wt-custom one), I don't believe airlines will put any time soon their full data on the open. However they are obviously keen to provide means to access the necessary parts to create and interact with a booking.

Cheers

Mathieu

Le mer. 28 nov. 2018 à 04:10, <alex.me...@windingtree.com> a écrit :

IMO: NDC is expected future, airlines are going to accept it, but not every company happy with it. 

And if Winding Tree can "upgrade" NDC-related processes, make usage and distribution via NDC more convenient, then WT will be met by the industry much more friendly than with any new standards

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/412bf032-6122-4f22-b57a-414fa0a65bc4%40googlegroups.com.

[Hynek Urban]

Hi Mathieu,

thanks for an interesting insight!

I think from our point of view, it's perfectly OK to publish just a subset of one's inventory. What is important is that anyone can then freely access what has been published (i.e., there are no obstacles such as security credentials that would prevent "unauthorized" parties from accessing the data).

Regards,

Hynek

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAPnC4U2qhjw0GK9Uk%2BZD-UmzwgLeAj%3D5MW%2BJp9Z6cbxU_LyN8A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Florian Pautot]

Hi,
From an airline point of view, using the NDC as the way to go would be clearly the easiest and simplest option.
To provide inventory on WT like what has been done for GDS and travel agents would be definitely less appealing. Because it would require a lot of efforts from the airline to integrate with WT. And I'm not sure they would prioritize it against NDC, since as it has been already said, it was already pretty difficult to pull out. As Mathieu said, Airlines will never provide all their inventories.
I am afraid that going with WT storing the data would kind of "scare" the airlines, and because of that they would be less willing to participate as pioneers before the platform has proved its value and its efficiency.
That's my honest opinion. I understand what it means for WT, but the open solution has quite a lot of drawbacks for the airlines.
On the other side, the openness of NDC software components need to be confirmed before considering it as a final option.

[metas...@gmail.com]

Hi Hynek & all, 

After the event, I pulled together some notes and thoughts from all the information that was provided as well as from some of the coffee/cocktail discussions on the side.  

I agree with the concern below on the challenges of storage of inventory on the WT platform (either airline or hotel).  Provider core inventory management and business rules is likely be held closed as it represents the business' competitive advantage. AFAIK provider core inventory storage doesn't necessarily have any business or technical advantage in being "solved" with a blockchain and/or distributed/swarm storage approach.  

Shopping is a different mess, the concern again is that it is quite complex and heavily dependent on how the airline manages its inventory: dynamic & volatile seats, revenue management rules & tweaks, O/D logic, various fare rules and pricing calculations including taxes, etc., additional fees, bundling/merchandising, etc.  In short, it is more of a calculation problem where again blockchain and/or distributed/swarm storage technology doesn't seem to provide any obvious advantage.   At best, WT could provide an NDC gateway to other shopping providers (but still no need for blockchain and/or distributed/swarm) or one of the other shopping providers.  On the point of NDC it is being strongly adopted and needs to be considered.  WT can be open but it will need to be able to interface with closed systems if it is to be competitive in the industry. 

One last note is that looking at the WT hotel approach it was by hotel/property.  This is again an inventory approach but does not facilitate as easily for booking.  The customer wants a seat (on a flight) and a room (in a hotel/property), which should be one of the core elements (along with price & eligibility rules).  

The recommendation would be for the Winding Tree solution to focus on distributing OFFERS which are converted to ORDERS.  The OFFER is a smart contract constructed post-shopping by the provider (airline/hotel),  where an airline commits a seat + price to a customer.  The OFFER is converted to an ORDER when the customer reciprocally commits booking/payment, typically via an via an agent/merchant which could also be the airline itself.   The ORDER smart-contract could eventually be followed by fulfillment/servicing rules as well ("flown", change rules, cancellation, etc). There would still need to be some interaction with the providers PSS system including securing/blocking inventory (the seat on the flight) as well as other sales processes (ex: validate form of payment, issue tickets, etc).  This would be a more adapted to the needs of the industry and the benefits which are provided by blockchain, Ethereum, and Winding Tree and is in line with the industry developments in distribution, notably IATA One Order.   

On general payment, e-Commerce Payment has its own complexities again including local acquiring banks and the plethora of means of payment that there are out there today.   In the medium term, is unrealistic to expect any cryptocurrency to be adopted across the entire scope of travel payment across all of the markets and stakeholders.  That said, the LIF could be considered & used specifically to represent the value of the distribution & sales commission between the airline & the agent/merchant.    

The following elaborates it a bit more and is submitted as hopefully constructive feedback/alternative on the design, etc. and the eventual extension to the airline industry.  

https://gist.github.com/metasimian/68342c390baa667b92c516766095ffb1

Interested in any comments :)

William

[Augusto Lemble]

Hello William, thanks for the detail and complete feedback!

I see that you jumped right into using blockchain for shopping and settlement, that's something we have been thinking too, but we see that as the last step in the process of decentralizing the Airline industry.
Don't you think that using the current WT index in a similar way that we are using it for the hotel industry but only to share the entre point of access to airline APIs and also distribute their API specifications will help to have an easier access and a more standardized of way of connecting and communicating with APIs?

Shopping is a hard problem to solve! Maybe even the hardest one. In a world where a solution like a WT Index of API airlines is in place, and I can get offers from all of them, it will be very take a lot of computation to aggregate them. Here is maybe the weaker point and the one that needs more work, the only thing I came up is to build something like an open-source aggregation API. But needs more work and inputs from experienced people in the subject.

Last topic, settlement on orders executed, In the document, I share below I share how payment channels can be used with something like One Order and blockchain for the escrow of funds and orders exchanged.

I invite you to read the document that I presented in the WT Hackathon, is a bit outdated but I will get time soon to update it again based on how we decide to move on the airline side :) https://docs.google.com/document/d/1VRm3ncmFMyphpVy44BYO_SgprAzbvgsvcyBeJLS_ric/edit?usp=sharing

[Meta Simian]

Hi Agusto,

I should apologize as the feedback is slightly delayed (I compiled it after the Prague event in October but only recently sorted out how/where to submit it....)

I took a look at the document, apologies but I must have not gone through it in as much detail as previously. It does effectively confirm my understanding of WT's current approach for airlines.  I do think we are looking at the problem from different ends. 

On the background on legacy vs. NDC for "indirect" distribution,  it is interesting to note that most GDSes were actually created by the airlines: Sabre came from American Airlines, Amadeus from Lufthansa, Air France, Iberia & SAS, Worldspan from Delta, Northwest, and TWA, etc. (a side note, it was based off of Cold War SAGE project built by IBM ;) ).  Point being that the airlines themselves actually designed all of it then spun off as a "GDS" business.  

The fact is that airlines struggle to sell in a bubble, distribution or more specifically brokering travel relies on a complex community of intermediaries and merchants, either airlines (ie: distributing themselves) or 3rd parties such as OTAs, even possibly via aggregators such as GDSes, or data partners such as OAG or ATPCO.  Distribution in one form or another is still relevant the mechanism that corrals the general public into the funnel to eventually put down money and book travel.  Pulling the whole travel domain off of legacy tech is a bit of a mess, but the underlying industry needs & associated players are likely here to stay in one form or another.

 
Initiatives such as IATA NDC and One Order are trying to solve & evolve not only the technology but also provide a framework around the new travel distribution business models meaning personalization, merchandising including packaging, etc.  But as you are probably aware IATA is for the most part not itself a software developer and as such hopes other parties to actually build the supporting platforms.  A lot of the "API standardization" that is described in the WT paper seems to duplicate NDC. Also, IMHO an API gateway itself is a pretty trivial thing to do these days.  Maybe technically interesting, but IMHO it shouldn't be a focus of WT effort.

On using blockchain as a common payment/settlement mechanism, I generally like the idea but 1) this problem is not limited to travel and 2) as such it gets into overall global banking complexities which IMHO is waaaaay beyond the scope of this.  At best, it'd be better to spin it off into a completely separate (non-travel) project but at the very least it should be kept out of WT scope.  That said, using LIF for the distribution & sale commissions between providers and agents seems to be a good application and worth keeping in scope as it matches the value of what the platform is providing to an associated cryptocurrency. 

In the end,  WT shouldn't try to itself wrangle together all of the aspects of travel business among all of the stakeholders including airlines, OTAs, GDSes, banks, PSPs, etc. Ultimately it doesn't matter whatever funnel they came into, airlines or OTAs, direct, indirect, what have you, on whether a search is done on Google or NDC or a GDS or a static page, or wherever, or whether the payment itself is PayPal or Visa or bitcoins or mPesa, what matters is HOW they come together.

IMHO the juicy part that is being overlooked/deferred is the "last step" that you mentioned.  The airlines NEED to lock the offer in, get customers to accept it including mutually capturing a payment is acceptable to both, and conversely to commit themselves to the service (seat in this case). Once the shopper is down the funnel, the airline/merchant mildly cares on how they got there (notably commissions and referral fees, marketing focus, etc).  Yet in the end, the booking/order is the fundamental objective.  The full-service carriers kind of do it with their ticketing systems and kind of via GDSes but these are all closed systems and difficult for the various external partners to reconcile.  Low-cost carriers often skip ticketing, but can only reconcile with themselves.

The offer/order smart contract becomes a shared record to capture all of the stakeholders: travelers, airlines, OTAs, aggregators, payment gateways, other partners, etc.. This is fundamental to the business and hugely important for accounting of revenue, promised services, terms and conditions, etc. in a manner that can be transparent between multiple parties. 

If WT can build a solid smart-contract based platform and a straightforward API that clearly allows these stakeholders to come in themselves around the booking and allows them to transparently reconcile amongst themselves, the wider travel community will likely connect on their own.   

Anyway, my 2 cents...  Admittedly it is a different view/path than the one already put forward, but then the intent here is to put forward alternatives :)

Hopefully worth at least a thought ;)

William

[Meta Simian]

(sorry, fixing some misposts above...)
Last quick point is to differentiate between the airline's internal inventory, pricing, and associated mechanisms which will likely be proprietary - as previously mentioned, travel providers will not likely want to decentralize their core business data...

vs. the sales/distribution: searching & booking... which could benefit from decentralization ie: a new means of distribution. 

My suggestion is for WT to not address inventory itself,etc,, also leave the searching/shopping calculation complexity for other players on the market, rather for WT to prioritize the distributed complex booking problem.

...

[LIF Hodler]

Hello,

I am a LIF Hodler and understand only a bit on this topic. Maybe this makes sense:

In terms of acquiring,^[15] one focus is travel and transport. Already in 2007, Wirecard took over payments and credit control for the tour operator TUI,^[16][17] and in 2014 for KLM Royal Dutch Airlines.^[18] The product Supplier and Commission Payments (SCP)^[19] by Wirecard is also made to measure the travel sector. It is based on the automatic output of virtual credit cards and enables electronic payments to partners and suppliers, for instance for commission payments. In this way international payments can be made via electronic transmission of virtual credit card numbers.

Source: https://en.wikipedia.org/wiki/Wirecard

Best Regards,

LIF Hodler

[Meta Simian]

Worth a read if you haven't seen it already...

https://www.travel-industry-blog.com/travel-industry/ndc/

On Monday, November 19, 2018 at 10:50:56 PM UTC+8, Hynek Urban wrote:

[Mathieu Tahon]

Hello,

Thanks for sharing, great detailed article indeed!

While browsing through the site, I also came across this article on fees and commissions.

I am copying the schema here for convenience (all credits to the author):

This is a topic I think is missing in the proposal as it is taking the viewpoints of airlines, but not the one of the other actors: Travel Agencies.

Basically Travel Agencies booking though a GDS receive today some commissions both from the airline and the GDS, if they move to Winding Tree with the current design they would lose the GDS incentive, and therefore would not have any interest to move.

I believe airlines, in particular when there is no GDS surcharge, should incentivize even more the agency bookings made through direct channels such the WT platform. According to the figures on the article, this should be up to USD7-USD16 per booking.

When a GDS surcharge is in place (Lufthansa Group, AFKL Group), this is less obvious to quantify. Agencies would of course benefit of WT by accessing a lower fare and therefore being more competitive, but would they receive an additional incentive from the airlines?

The technology is great, but without business incentive I don't see why Travel Agencies would adopt the WT platform.

What do you think?

Best Regards,

Mathieu Tahon
+32 483 318 821

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/affdcbdd-b9b6-419c-a82a-03093faaff0d%40googlegroups.com.

[Meta Simian]

HI Mathieu,

Nice reference on NDC (also I noticed article #9 "Blockchain in Travel: All you Need to Know – for Now"... worth a read as well as the comments after ). There's a good infographic that sums up the distribution landscape here: https://www.altexsoft.com/infographics/how-airline-distribution-works/  and this article is pretty good from the travel agency angle: https://blog.yieldr.com/the-relationship-between-airlines-and-online-travel-agencies/  From this it is pretty safe to assume that 1) Aggregators/OLTA/Travel Agencies will still be around 2) they will expect some kind of business incentive to do this as you indicated.

How this is handled by WT is as of yet unclear.  My thought is that the business incentive could be achieved by the LIF in the form of the airline-to-agent commissions: airlines would post commissions in the smart contract which agencies/aggregators would earn if they sell them. This could also overcome the existing airline distribution problem where all bookings are charged about the same - the airline could actually offer higher commissions for higher yield fares/bundles rather than having travel agencies only going for the low-hanging fruit.