The Better Airline Ticketing System™

Why can’t we book airline flights the same way we route TCP/IP packets? An airplane ticket is kind of like a guarantee. You tell the system: “I want to go from Portland to Boston on March 4th. I want to leave in the morning and arrive in the afternoon.” The system replies: “I can guarantee you seat 32A on flight NW 425 to Chicago at 8:15 am, and from Chicago I can guarantee you seat 16B on flight NW 1620 to Bostom at 1:22 pm, arriving in Boston at 4:30 pm.” The current system has a fixed number of seats on a fixed number of flights (all flying at fixed times). This is another way of saying: the number of seats and flights almost never varies in response to changes in traffic. Such a system made sense when airlines had to coordinate flights via telephone (or the hatefully archaic SABRE system), and had limited computing power to calculate the best capacity for any given flight/journey between two cities. After all, a Portland travel agent (without a computer) couldn’t book connections through Chicago without absolute certainty about the flights leaving Chicago.

This system has very little flexibility built into it; moreover it provides the wrong kinds of guarantees to customers. If I’m flying from Portland to Boston, I don’t need guarantees about the exact seats I’m sitting in, the cities I fly through, or even my departure time. The only guarantee I need is “you’ll be in Boston by 5:00 pm on March 4th.” Which is pretty much the only guarantee the current system can’t provide. Especially if a blizzard on the west coast shuts down all flights into Boston...the next day there are twice as many passengers trying to book seats on the same number of flights.

The Better Airline Ticketing System™ would provide only a guarantee of arrival times, then would allocate airplanes and flights on the fly. The well-heeled traveller can pay a premium for exact guarantees: “I need a 90% assurance I’ll arrive in Boston by 5:00 pm.” The happy-go-lucky traveller can get a discount for flexibility: “I need a 50% assurance I’ll arrive in Boston by 5:00 pm.” Of course, this system would need to provide exclusions for weather or other Acts of God, but just as TCP/IP routing can guarantee eventual transmission of 100% of my data packets, The Better Airline Ticketing System™ would do the same.

Here’s how it would work: I book a flight from Portland to Boston. I have to be there by March 5th, but the time I arrive on March 4th is flexible, and I can actually start my journey on March 3rd. The system checks to see how many other travellers need to arrive by March 5th, then decides whether that number justifies committing an entire flight direct from Portland. If I’m booking my flight early (say, early February), the system might not see any need to fill an entire plane for this flight. It would send me an email (or voicemail, or text message, or IM) that says, “we’ll get you to Boston on a March 4th flight, but you’ll have to change planes somewhere. Arrive at the airport by 8:00 am on March 4th.” As we approach the date of the flight, more passengers (for whatever random reason) are booking flights direclty to Boston on March 4th, so the system sends me an email: “Good news! You now have a direct flight from Portland to Boston on March 4th. You’ll need to arrive at the airport before 9:20 am.” (Note that the earlier information, the 8:00 airport arrival still obtains. If I don’t get this “Good News!” email, the only damage I’ll incur is an extra 80 minutes at the airport.) As March approaches, The Better Airline Ticketing System™ realizes there’s a lot of traffic (for some reason) from Portland to Boston on March 4th, so it increases the size of the plane, or adds another flight.

What happens if there’s a blizzard in Boston that closes the airport? Again, the The Better Airline Ticketing System™ has the current system beat. Instead of trying to squeeze twice as many passengers onto the previously-scheduled flights for March 5th, the system adds more plane capacity into Boston. Of course, Logan is limited in its capacity to land planes, so it probably can’t double the number of planes landing here. But I bet it can land more (and larger) planes.

These are not unknown or untested principles. I’m basically imagining a Just-in-Time airplane ticketing scheme, functionally similar to sending packets through TCP/IP, routing long-distance telephone calls, buying a Dell computer, or managing Wal-Mart’s supply chain. Hell, this is approximately how the U.S. Postal Service operates.

If some pioneering airline (Hello, JetBlue? Southwest?) reorganized its ticketing in such a way, I imagine it could shave costs (no more empty seats!) while improving customer service. So why isn’t anyone doing this yet? I see two roadblocks.

First, the air travel industry has enormous sunk costs on the current system. Not only has it invested in icky old SABRE, but more importantly it has created an infrastructure that supports hub-to-hub (as opposed to end-to-end) routing. So we have a few “superstar” airports that serve as huge mega-hubs for travel, with many small regional airports that are mostly the end of the line. To maximize the efficiency of end-to-end routing, you’d need a large network of medium-sized airports that are suitable as both hubs and destinations. (I’m sure there are other sunk costs, for example in air fleets or labor, as well.)

Second, such a system will require an attitude shift for everyone involved. Travellers are accustomed to a system that provides perfect information at the cost of accuracy. (Sidenote: this is like the old saw about a stopped clock being right twice a day). They’ll have trepidations about tickets that can’t tell you exactly when you leave or what seat you have until basically the moment the plane takes off. Airline crews work highly regular schedules, and will bristle at having more idle days when travel is light, or being on-call when travel is heavy. Finally, this would pretty much seal the coffin on travel agencies as viable businesses.

Has anyone else thought of this already?