Monday, 1 February 2010

JetBlue's switch to Sabre: What's it mean to you?

From 36 hours from midnight Thursday night through mid-afternoon Saturday, JetBlue Airways' telephone reservations center (actually a virtual "center" -- when you call 1-800-JET-BLUE, the phone is answered by someone working from home anywhere within a couple of hours of Salt Lake City, mostly mothers with children but also some retirees) and Web site were unable to make or change reservations. Many flights Saturday and Sunday were cancelled, and advance tickets on the remaining flights had been been capped at a maximum of 60% of capacity.

And all this was deliberate.

What was going on? And what could possibly have justified the hit to both current and future revenues (JetBlue wouldn't say how much they expected it to cost) from these disruptions?

JetBlue was switching the hosting of its reservation and e-ticket databases from one Computerized Reservation System (CRS) to another, from Navitaire to Sabre.

The transition seems to have gone as well as might have been expected.

But the effects on travellers won't be over for months, and there are a couple of important lessons about how the airline business works:

If you bought tickets before the transition for flights in the future, check your reservations as soon as it's convenient -- while there is time to fix any problems before you show up for your flight -- to make sure that everything in your PNR (flight arrival and departure airports, dates, times, flight numbers, names, Secure Flight data, frequent flyer numbers, reservation status, record locators (there will probably a new one in Sabre along with the original one from Navitaire), ticket numbers, special meals, seat assignments, special meals, other special services, etc. -- was properly migrated.

If you have to deal with JetBlue in the next few months, either on the phone or at the airport, expect it to take extra time, and double-check your reservations, tickets, boarding passes, and baggage claim checks before you leave the counter. Mistakes will be made.

I've been through a few CRS conversions, and managed one, on a dramatically smaller scale (although still mission-critical for that business) at a travel agency. It's a painful process, not so much because of difficulty in converting Passenger Name Records (PNR's) from one system to another, but because of the need for workers to switch from one set of command formats and procedures to another without interruption. Unless the staff are already using multiple CRS's on a daily basis (not too uncommon at the most sophisticated travel agencies, but rare at an airline), it's likely to take at least a few weeks of practice for them to get mostly back up to to speed.

Typically, reservations staff will have been through several full days of training in advance, and for the first week or two they'll have extra Sabre support staff and trainers on site or on call. They'll learn the basic commands they use all the time in a matter of days. But some command formats are needed only rarely, and less common tasks will go slowly for many months to come.

If it's going to cause all these problems, why would an airline bother?

Differences in mere database hosting and transaction processing functionality wouldn't be reason enough to change. Real-time, 24/7, large-scale, mission-critical, globally connected distributed hosting and processing isn't easy, but the major CRS's all offer roughly comparable capabilities.

There are some differences in connectivity: A CRS serves not merely as an airline's outsourced host for an internal data, but as its connection to other airlines and travel agencies, either directly or through the CRS's "backbone" connections to the other major CRS's. By migrating to one of the big four CRS's, an airline connects itself to a global network of networks that includes hundreds of large and small airlines (basically all airlines except a few "low-fare" airlines that run their own isolated reservation systems) and a hundred thousand or more travel agency points of sale around the world. That connectivity provides bidirectional messaging, flight schedule and seat availability information, payment processing and ticketing, and support for interline reservations, ticketing, check-in, and baggage checking.

A few years ago, connectivity would have been the main reason for an airline to move to one of the big four CRS's. But XML messaging standards adopted by the Open Travel Alliance provide an increasingly viable (although still limited) alternative to the traditional AIRIMP protocol for messaging between airlines, CRS's, and travel agencies.

At this point, the payoff for an airline like JetBlue from migrating its reservations to Sabre is likely to come from the ability to deploy more of Sabre's other integrated software products for pricing, "yield management" (real-time decision-making on the availability of seat confirmations, and allocation of availability between booking classes), flight and equipment and crew scheduling (if you think the "travelling salesman problem" is hard, imagine the problem of thousands of simultaneously travelling pilots and flight atttendants!), and so forth.

CRS's compete vigorously on the (precisely measurable) performance of all of these optimization software packages, most of which only work, or work best, in conjunction with their own hosting systems. A switch to a new yield management package that achieves a sustainable 1% increase in average revenue per available seat-mile will recoup the cost of a two-day transitional shut-down in less than a year. (If this leads you to suspect that CRS's are at the pinnacle of applied operations research, you're right.)

More efficient airline operations are, of course, in the interests of travellers as much as of the airlines. But there's an unfortunate (for travellers) corollary to the role of CRS's in the air travel industry: They are paid by, and optimized for, airlines. Not travellers, and not (despite ongoing debate) travel agencies. And the only way to access these systems is through toolsets and query languages provided by those CRS's themselves, and optimized to serve the interests of their paying customers, the airlines. Their goal, on which they compete, is to ensure that each traveller pays as much as they are willing to pay, and no less.

That means that anyone -- an online travel agency, an offline travel agent, a "search" or "metasearch" 'bot, or an individual traveller -- trying to use the tools they provide to enable travellers to pay as little as possible is trying to use them against the best, and very skillful, competitive efforts of their designers and maintainers to achieve exactly the opposite result.

It's in that sense of trying to use software tools against their designers' intent that those travel agents who work as agents of travellers, rather than as agents of suppliers of travel services, necessarily have a "hacker-like" attitude toward the CRS's they use, and are constantly looking for undocumented "features", exploitable back-doors, and the like.

I've often said that asking the airline how much they want you to pay for a ticket is like asking the IRS how much tax they want you pay. They'll give you an answer, but it's unlikely to be the one that's in your best interest. The same, unfortunately, goes for asking a CRS.

[Follow-up: Tnooz reports, "Navitaire admits that Sabre has one advantage in that Sabre's revenue management system supports O & D (Origin & Destination) forecasting and Navitaire's SkyPrice revenue-management system does not. JetBlue had been using a revenue-management system from a third party, which does not support O & D, and presumably will be switching to Sabre's."]

Link | Posted by Edward on Monday, 1 February 2010, 21:02 ( 9:02 PM) | TrackBack (0)
Comments
Post a comment









Save personal info as cookie?