Loading ...
Global Do...
News & Politics
7
0
Try Now
Log In
Pricing
Death By Booking Engine Traps and Misperceptions about Travel eCommerce Author: Novak Niketic Sutra, Inc. 93 High Street, MA 01950 U.S.A. www.airkiosk.com Copyright Notice: 2000, Sutra, Inc. Reuse and reproduction is allowed provided the name of the company, Sutra, Inc., and the author, Novak Niketic, are included. The Gold Rush The latest figures for Internet-based airline sales, more than US$5 billion in the past year, have exceeded even the most optimistic projections of early industry analysts. Vendors nervous they will be left behind in the “new gold rush” are, one after another, leaping into a deceptive and incomplete model for “Travel eCommerce.” In essence, eCommerce is the use of the Internet as a distribution channel. The travel industry has been trading electronically for decades. The industry, primarily airlines, built specific systems and networks to do this. The Internet -- based on open platforms and network computing -- and the travel industry network -- built on proprietary platforms and mainframe computing -- are not easily wedded. Today’s attempt to bridge the gap between the new and old environments is the work of two groups of companies. One group, coming from the Internet side, is not burdened by the technology originally developed for electronic travel trade, but also does not have the substantial knowledge which went into it. The other group, the GDSs, “owns” the old travel distribution model and wants as little damage to it as possible. Together, the eCommerce “solution” they hope (and are succeeding) to proliferate is something called a “Booking Engine.” A “Booking Engine” provides a low-level gateway from the Internet into the GDSs. Hundreds of “Booking Engines” are being scattered into the travel environment and dominate Travel eCommerce today. The first wave of companies in Internet/Booking Engine-based travel sales (Expedia, Preview Travel and Travelocity, et al) positioned themselves as “virtual” travel agencies meant to replace the “brick and mortar” kind. They promised to reduce costs. The second wave of companies invented and expanded consumer access to “cheap tickets” -- consolidators, auctioneers, and wholesalers – and promised to dilute ticket pricing. The third and current wave is travel vendors themselves who see direct use of the Internet as a way to reduce costs and mitigate the threat of low-fare Internet sites. At least all major airlines now have a Booking Engine application which gives consumers direct access to their product database and sales functions. What very few in the travel community realize is that Booking Engines are a stopgap measure which adds cost and complexity to the distribution process and actually contributes to its continued inflexibility. Booking Engines do not really exploit the “cheaper, faster, better” promise of Internet technology and eCommerce. This White Paper was written to help top travel executives understand the true role of Booking Engines and point travel IT managers toward a new direction for real solutions and an effective model of Travel eCommerce Distribution. Death by Booking Engine 2000, Sutra, Inc. Page 1 Booking Engine Approach A Booking Engine is software which usually runs on a dedicated server to provide an interface between a front-end application that manages a User Interface and back-end programs and databases responsible for supporting a company’s business processes. New Network Local Data Repository 4 3 1 2 Business Applications and Databases Booking Engine 1) Software that emulates dumb terminal to talk to the existing applications. 2) Local Data Repository 3) Link to other Systems 4) Application that Manages UI User Interfaces (UI) (Browser) Booking Engine requests directed toward old applications are the requests originally designed for trained human intervention. Responses coming back from the applications are also designed for human interpretation. The reading of these responses and data input to internal processes is called Display Parsing or Screen Scraping. In some cases the requests and responses have a fixed format or inserted field delimiters, but here, too, the programs triggered to generate responses continue to be the same ones developed for trained people on the other end. So what is wrong with this approach? Death by Booking Engine 2000, Sutra, Inc. Page 2 The answer becomes apparent when we examine some basic transaction flows which regularly occur within the Travel Distribution model. Availability Display Availability Display is one of the most essential transactions in the Travel Distribution model. Availability Display shows which product and how much of it is available from given vendors (flights, hotel room, cars, etc). Evidence of what has been sold and what is still available is held in the Vendor’s Product Inventory Database. When sales occur using a non-direct sales channel, such as a GDS, or even some direct channels, this Inventory Database is remote from the selling application. Over the years the travel industry developed many methods to communicate between the front-end (selling) application and the back-end (inventory system). Of these methods two are most prominent: 1) Open/close sales messages, and 2) Direct Access. Open/close sales are messages which are sent by the Inventory System to notify the Selling System when the sales of a certain product should stop. Direct access transforms each transaction from the Selling System into a transaction for the Inventory System. This means that, for one example, for a single sale on a flight with 200 seats and 5 classes of service, the two systems will exchange approximately 5-10 messages in the first method and approximately 600 messages in the second method (assuming that one seat will be sold after three displays and there will be no cancellations). Power Pricing (Shopper) GDS companies developed “power pricing” or “shopper” software to help users (initially travel agents, and then consumers) find the cheapest option for travel between cities. The software searches for all possible combinations, checks the availability of classes for each segment in the combination and checks the total price of the journey. For obvious reasons (performance) there is some limitation on how many connections are checked for each journey, usually around 16. This is one of the heaviest applications running in GDS companies. Some of our studies found that this application may account for as little as 1.5-2 % of all business transactions but consumes more than 25% of system resources. Death by Booking Engine 2000, Sutra, Inc. Page 3 Communications Inter-vendor communications was one of the biggest distribution challenges for every airline before the commercialization of the Internet. For practical reasons several airlines formed a separate company, SITA, to share facilities and try to keep the cost of communications as low as possible. (In the past few years, airline ownership of SITA has been reduced to less than 50%.) Airlines use the SITA network to communicate among themselves, with their own remote locations, and with the GDSs. The pricing for SITA services is quite complicated. Users pay a subscription fee, pay for every connection point and for the volume of data transferred via the network. Compared to the Internet, the cost can be tremendous. SITA CRS Airline Host Dumb Terminal Booking Engines: “Wow” or Woe? A basic principle of the systems built to support traditional travel distribution was a degree of complexity requiring trained users at the sales end. Essentially, the transactions on these systems were once controlled by the ability of trained users (travel agents) to comprehend the display (interface) and react. Trained users protected against the excessive use of system resources. The entire point of Booking Engines is to allow non-trained users (consumers) to quickly and easily generate transactions (queries). These “web queries” translate into hits on vendor Inventory Systems. If a vendor’s connection to the GDS is high level (direct access, seamless), this translates into many hits on the vendor’s system. The number of hits will dramatically multiply when any of the power pricing software is used. With one “point and click” a Booking Engine “power shopping” query is able to generate the same number of transactions as would a productive travel agent, using a dumb terminal, in one day. Death by Booking Engine 2000, Sutra, Inc. Page 4 Impact of the Booking Engine on a traditional GDS-Vendor link: SITA CRS Browser Airline Host Internet Web Vendors 1. Every Query on the Web page translates into several transactions exchanged with the Vendor’s system. 2. Search for cheaper tickets is serviced by software which generates hundreds of transactions exchanged with the Vendor’s system. Distorted Financial Picture A Booking Engine hooked to a GDS allows web users to “shop” the GDS, generating hundreds of transactions on both the GDS system and vendor systems. To add “insult to injury,” the Booking Engine application may then bypass both the GDS and vendors by finding and allowing the purchase of a ticket from an entity (such as a “cheap ticket” consolidator) outside of this community. The “power shopping” aspects of Internet-based distribution combined with the proliferation of “cheap ticket” and “auction” sites have put tremendous downward pressure on average ticket prices. The result of Booking Engines for GDS-linked vendors is a dramatic increase in both system resource use and communications costs with downward pressure on ticket prices. Even if GDSs were to decrease or stabilize booking fees, the increases in established costs, plus new costs for websites, plus decreased ticket prices means that - even if the Internet helps fill a plane – there is a continuous squeeze on profitability. Booking Engines do not facilitate the Internet’s opportunity to decrease distribution costs. Death by Booking Engine 2000, Sutra, Inc. Page 5 Implication of increased use of the sales channels utilizing the Booking Engine approach. Effect of the Booking Engines attached to the GDSs or to the Vendors systems is similar with exception that if a new solution is placed near the mainframe, it may prevent some of the extra communications costs. Booking Transactions Volume Pushing Up Pushing Down Revenue Booking Engines create some losses in current revenue: • Average price of the ticket sold via the Web is lower • Some consumers and travel agents will choose newly available vendors, not part of the GDS distribution chain Costs Booking Engines increase the costs of the total solution: • Booking Engines do not replace any part of the existing solution, but • Increase the number of hits on the Inventory System causing communications costs to go up dramatically, and even requiring some mainframe upgrades • Add costs of new projects (new solution, equipment and resources), • Will soon start causing a nightmare as the two systems will need to be kept in synch continuously. Average Booking Fee Effect on the GDSs: Booking Engines make it more difficult to lower Booking Fees by: • Not helping to get the current high fixed costs down • Taking away some of the bookings that previously went through the GDSs Booking Transactions Volume $ 3.5 Death by Booking Engine 2000, Sutra, Inc. Page 6 Beyond Booking Engines The Booking Engine bridge from the Internet to legacy systems is not sustainable in the long run and does not deliver the full benefits of eCommerce to travel vendors. As long as the mainstream applications which run behind Booking Engines are grounded in the legacy world, the cost advantages (rather than just the marketing advantages) of Internet technology are lost to travel vendors. The solution is one which exploits on new platforms the travel industry’s long experience in efficient transaction processing. For vendors without ties to the legacy world, nothing else makes sense. For vendors still engaged with GDSs and mainframe investments, this solution must accommodate, at minimum, Inventory Management functions and Point-Of-Sale (POS) Control in a way which is seamless both with the Internet and with the mainframe environment. By allowing Internet traffic to be diverted and handled separately, this solution allows for reductions in communications costs and relaxes the load on mainframes. SITA CRS Browser Airline Host Internet Purpose-built eCommerce solution includes Inventory Management and POS control, at least. Fares can also be part of the solution, whether their source is private, ATPCO or the GDSs. This solution is the AirKiosk system. It is a genuine migration tool, delivering the economies of the Internet today and providing the tools for building a mainframe-less distribution environment -- one that gives control back to “best of breed” travel vendors – tomorrow. Death by Booking Engine 2000, Sutra, Inc. Page 7 Death by Booking Engine 2000, Sutra, Inc. Page 8 About Sutra: Sutra, Inc. is the developer of the first purpose-built Travel eCommerce Solution, the AirKiosk system. The AirKiosk system combines the open platforms of the Internet and Linux, the streamlined transaction processing facilities of the TPF environment, and the structured database management needed for the object-oriented world of networked applications. The AirKiosk system is available with full, integrated Reservations, Inventory Management, Revenue Management and Check-In applications. About the Author: Novak Niketic has worked in Travel Information Technology for 27 years. As an employee of KLM he was responsible for networking architecture and was a member of the initial Galileo GDS Architecture Team. He led the development of the first distributed airline reservations system, a product built on a Fault Tolerant platform for Shanghai Airlines. As president of Sutra, Inc. he is the principal developer of the AirKiosk system and consults to companies such as Worldspan, Sabre and Atraxis, among others.
