Thank you for your suggestions, however many times the availability of new features are constrained by the data that we have access to and the ways in which we can access that data.
Originally Posted by
Keter
Dear EF, have you investigated public interest for adding "sale date" to fare information?
That would basically provide access to fare archive and more importantly to fares which are already filed/ posted but yet being displayed as not yet effective.
I don't think this is difficult from the technical standpoint, but you definitely need that demand is demonstrated.
It's not an issue of technical difficulty, it's just not possible to ask a GDS for a list of fares without including a travel date, even if you also have the ticketing date. A fare archive search may be possible, put again it would require a travel date as well as a ticketing date. GDSs unfortunately were built to return specific, applicable information as opposed to as much data as possible.
Originally Posted by
Keter
- booking classes for secondary airlines (in case the fare allows to have other airlines segments you will no longer have to guess or use ITA to check which booking class it books to say on LH and how many miles you will get).
This may be possible, we'll add it to the list to research and prioritize.
Originally Posted by
jackal
Two other things that bug me constantly:
1) Inability to specify more than two connection points when searching for availability
2) Inability to set alerts across a whole itinerary (you must set alerts for each individual segment).
1) The reason why it's only two connection points is because that's all the GDS will accept from us. I'm not even sure GDSs can return an itinerary with more then 3 segments as you can always get from A to B in 3 segments or less.
2) That is something we want to change to support married segment logic, however it is not simple. There are many issues and problems that a multi-segment alert creates as well as the increased input that is required when creating such an alert to make sure it does what the user wants it to do. It's something we'll give thought to after our current round of changes are complete.