In the future, we're hoping to write a piece about how air fare pricing works too. There's a lot of interesting stuff re. fare buckets, forecasting supply + demand, etc. It's also very topical with COVID: https://www.flyertalk.com/forum/united-airlines-mileageplus/...
(If HN has any ideas about what else we should write about, let me know! I'm david AT retool.com)
I just have one remark - how on earth does a 737 fly from SFO to LHR without stopping as in the example?
~Unfortunately, the output is in png format which was generated by carbon.now.sh, so I'll have to type everything out. I'll change it once I have a few minutes...~
Edit: just changed it into BA286, which is an 388. (For fun, I also added in first class fare buckets, which United no longer offers.) For additional accuracy, I also updated the UA equipment to 772s, which IIRC is what they actually fly (as opposed to 77Ws).
(If we did this more often, we'd probably actually design it in HTML instead of using Carbon, but an image was much faster, haha.)
The MAX has a range of 3850 nm, LHR-SFO is 4664 nm
So unless it's an empty ferry flight and you've got very favorable winds, you're not doing that without stopping.
Hawaiian needed extra tanks to ferry their 717 (or was it MD something) over there (there's a picture around IIRC)
Seems obvious once you've seen it...
I've seen that happen, reproducibly and in a plausible way: The (third party) site was adding an "agency discount" (name may not be precise, this is from memory, IIRC it was ~$10-30) that turned into a significant (IIRC $50+) "agency surcharge" on your second visit. Clear cookies, discount is back, revisit, surcharge is back, 100% reproducible.
I presume the price goes up and down based on aggregate searches or reservations for the flight, i.e. supply and demand. I know for hotels, there are programs crawling and searching for competing hotel’s prices and changing pricing based on that as well as changes in inventory and prior year’s data.
I can imagine that a route with 500 available seats won’t be programmed to be sensitive to one search, but a route with 10 seats could be.
If SFO/T-7 is 7 hours behind Greenwich Mean Time and LHR is in the (same) GMT time zone, how is that 8 hours ahead of the origin airport?
It's not exactly correct that SFO is 7 hours behind GMT because this isn't true for around half the year. It also isn't exactly true that LHR is in GMT.
Most of the year, SFO is actually 8 hours behind LHR. A few weeks are off due to different DST dates.
It's just easier to think of yourself in UTC/GMT all the time (known as Zulu time or /Z in the aviation world) and deal with the relative offsets later. Don't forget that US Daylight Saving has different start/end dates to the UK while you're at it too...
Great story and pictures, thanks for the information.
I'm Tim, and I lead airline partnerships at [Duffel] (YC S18) - although I'm an engineer by trade ;) We're building a new API platform to make it easy for anyone to sell flights (think "Stripe for travel").
We make integration simple with our beautiful REST API (no XML or EDIFACT) and allow anyone to sign up in 30 seconds, with no need to become an accredited IATA agent.
We're rebuilding the industry's infrastructure from scratch, with direct connections to 20+ airlines' systems using the new technology mentioned in the article, NDC, rather than going through the traditional GDSs like Sabre and Amadeus.
If you want to give our API a try for yourself, you can sign up on our website and book your first flight in our sandbox in less than 2 minutes.
Equally, if this sounds like an interesting problem space to you - we're hiring, so do reach out. My email is in my bio.
We're also in a good position today to help existing travel sellers who want to access exclusive NDC content (mentioned in the article) that they can't get through a traditional GDS.
From there, the sky's the limit really. We'll be in a great position to help anyone who wants to sell flights - new entrant or existing seller.
Typing commands starts at 2:05 in. Watching this left me feeling like I was being taught how to use the "rm" UNIX command while logged in as root on a production machine that wasn't backed up and this was my final chance to keep my job.
see this talk "Where in the World Is Carmen Sandiego?" from 33C3 conference (2016).
Although the story describes in a technical way that the EDIFACT, XML, etc standards are cumbersome, inert, and resistant to change, I think the real story is somewhat external to the "code" level reasons. And it will also be a lesson (for the proponents of some change to any kind of standard) about why just a technically better solution doesn't always win.
Because, if you look at almost any standard, there's generally nothing stopping someone from proposing an alternative or better version. It's the adoption that's the tough part.
The more fundamental root cause of why this particular "bad" or outdated standard persists so long is that airlines are a very risk averse and capital intensive business. Any change -- especially one so fundamental as could interfere with their minute-by-minute booking engine (companies can lose billions if that system goes down) -- is highly risky. And it wasn't really built with incremental changeability or "hot swappability" in mind. Changing it involves retraining thousands of people, changing computer terminals, keyboards (with special character keys coded in plastic), practices, interfaces to yet other vendors. And when your company is burning dozens of millions of $ per day, that's something that you don't risk unless it's a strategic decision.
So that dynamic flows down into what your software vendors are incentivized (or become attuned) to produce or charge you for. Until there's some ground-level shift -- for example suddenly everyone needs to charge baggage fees -- no airline was actively asking for that capability to add on ancillary fees. And no GDS provider was seeking to innovate on it. Airlines simply wouldn't pay the extra for that unnecessary functionality... until they did.
Old, expensive, risky industry -- and that's why sometimes the change has to come from new entrants who aren't tied to these legacy systems. Although, and this is an even more involved topic, sometimes those new entrants find they have to tie into the legacy system to survive and get customers.
And at the time ITA found getting airlines to adopt their tech even more challenging (though a big exit to Google validated their tech stack). The complexity and legacy code behind existing integrations is also part of the GDS suppliers moat when it comes to renewing contracts and whilst airlines want the ability to upsell 'packages' with hotels/transport etc (one of the rationales for NDC, because now baggage fees and travel partnerships are really important to airlines), the GDS companies' travel agent partners whose bookings represent a sizeable part of client airlines' revenue base (and therefore their other moat) want to sell their own hotel/transport bundles.
Banks also relied (rely) for years on "antiquated" systems but they took the "they just work" and built some security around them. Airlines did not. This  presentation from 33C3 was really interesting (more readable form ).
While it sounds horribly inefficient, I can't understand what sort of archaic process can make reserving a ticket a 1.5 hours task. Any ideas?
Find the flight's index card: 1 minute
Indicate the booked seat: 0.5 minutes
Return the flight's index card: 1 minute
Write flight ticket out by hand: 2.5 minutes
That seems a very conservative estimate to me. What happens during the other 85 minutes?
Either that, or there's a big queue in the middle of the day where an operator would take down the reservation request, put it in an already-tall stack, and only call the travel agent back 90 minutes later on average.
But since a queue would be highly variable, 90 seconds seems much more likely.
(The former error is indeed because I confused the outbound / inbound flights. I've taken BA286 quite a few times, but I forgot which direction was which. When I was initially fixing the article I thought it was "BA286" but then looked it up and found it was "287". I then fixed the error in the screenshot but forgot to fix the error in the text itself. Apologies the edit introduced annoying little errors — this is entirely on me trying to do fix something quickly.)
>"LHR/GMT¥8: the arrival airport, LHR, which is in the GMT time zone, which is 8 hours ahead of the origin airport"
Why exactly is the Yen sign used at the destination? Why would this not warrant an explanation?
By convention, large airlines typically number their flights so that even-and-odd numbered pairs operate between the same two cities.
For example, QF49 flies MEL-SFO and QF50 flies SFO-MEL.
My first job was in that sector.
I learned a lot during that time. It was an enormous c++ codebase (as I remember it, millions of lines) and as much as I profoundly disliked some aspects of it, there were also a lot of interesting things. IIRC they had a pretty large platform team maintaining their own compiler and eclipse plugin.
One aspect of pricing (and availability, just because there are free seats on a plane does not mean they are available to you) that is not touched in that article is not multi legged flights are almost all the time deeply favored by the algorithm.
So if you absolutely NEED to go somewhere but the website shows zero availability, try to search for a multi leg trip including your intended destination.
fscking GDS was like staring into the abyss
Another place where this leaks through is if your initials are similar to "Mr", you'll get very strange tickets once in a while because the system doesn't actually have the components of your name in separate fields. It parses them from a text command.
The NDS change should solve all of these things, but it's a costly exercise so expect it to be delayed by the current downturn in the travel sector.
Side note, I can get faint hints of how this topic relates to Retool (eg, the GDS CLI is not a good internal tool), but it's pretty rare in my experience for a corporate blog to not try to shoehorn its own solution into the picture, and there's literally no mention of Retool in here. Kinda novel to just have a vaguely related exploration on a company blog.
Unfortunately, the booking part is almost the most pleasant aspect of it all.
The actual travel experience itself though has totally gone in the other direction!
Almost looks like Uber and Lyft!
While Uber and Lyft might not be as crazy-profitable as people had hoped, establishing a marketplace by connecting a large number of suppliers with a large number of buyers is a valid business. The other big commonality is that both air travel and taxis are low-margin.
Fascinating article, but the wild optimism about air travel at the end was almost creepy. Then I looked at the publish date, 18 November 2018.
When you see a person entering something like "flight from Istanbul to Moscow with a mandatory 24-hour layover in Frankfurt for a family of three" in under 5 seconds, your worldview is shattered :)
HL7 for health information. https://www.hl7.org/
MARC for bibliographic information. https://www.loc.gov/marc/
XML has been the vehicle for attempted rework of these formats. I wonder, though, whether the time might be ripe for less cumbersome reworks, maybe using JSON with validated schemata?
Metasearches more or less killed OTA's since. Nobody cares about user experience anymore, if tickets are 1 dollar cheaper on some other OTA, traffic will go there.
Also, ILS itself is fairly primitive, as is anything prior to GPS. It was all more radio technology than computer technology.