21st Century Travel Distribution System

by

George A. Smith

Smith's Net Services

Posted: 9 June 1997

Synopsis

Most people agree that the Current Travel Distribution System (consisting of the CRS/GDS and the Travel Agencies) is dramatically too expensive. Many in the Travel Industry are working to eliminate (or at least reduce) the role of the Travel Agency. My goal is to address the issue of eliminating (or at least dramatically reducing) the role of the CRS/GDS! Furthermore, any such solution should be as inexpensive as possible for all parties, but more importantly significantly cheaper in total than our current CRS/GDS centric one.

Any attempt to eliminate the CRS/GDS from the travel distribution process, must retain (or at least reproduce) both the Customer and Vendor required "outputs". In addition it needs to recognize the "fundamental value adds" that the CRS/GDS provide, and reproduce them!


The Current Travel Distribution System is made up of the following players:

 
Current Distribution System (Players and their Relationships)

Fundamental Value Adds of the CRS/GDS

With literally millions & millions of Travelers (are we at billions yet?) and probably a half million (500,000) Travel Vendors, the number of connections (Travelers times Vendors) is staggering! Furthermore, without some structured and indexed, catalog of Vendors (and/or the products they offer), no travel researcher would even be able to begin to construct an itinerary utilizing the most appropriate travel Vendors/products (yes, yes, I know, advertising & local familiarity does allow one to pick a travel vendor/product, but do you always want to pick the vendor that spends the most on advertising?). This problem was admirably addressed by the CRS industry. Back before the Internet, the idea of creating a network with M by N connections was unthinkable. The CRS industry solved the problem in the classic way, converting M by N to M to 1 & 1 to N (this reduces the connections from M by N to M + N). Along with this networking problem the CRSs solved the routing (of messages) problem.

Three other problem areas were also resolved by the CRSs. First was the development & adoption of an inter-Vendor protocol (in the OSI protocol stack the layer of interest here is the Application Layer, TCP/IP or ALC is much lower in the OSI stack, and in reality nearly immaterial to the application programmer). This protocol was usually EDIFACT. The second problem area was Vendor selection. This was resolved by the creation of a vendor/product catalog. This catalog allowed the CRS to know which Vendors were even viable for any specific query. This Vendor filtering dramatically reduces the network bandwidth requirements (the adoption of CRS based free-sell space further reduces bandwidth needs). The final problem area was the creation of a On-Line Vendor Market or Mall (thus allowing Comparison Shopping).

So, to recap the CRS/GDS Value Adds are:

Note: The existence of a PNR (Passenger Name Record) to store "links" to the appropriate Vendor Reservations is necessary! But the PNR living IN the CRS/GDS "was" a historical necessity! With the advent of networks (the Internet) and the near ubiquitous computing power, the PNR could "live" just about anywhere!


"Outputs" required by the Customers/Vendors

To get a better understanding of the required "outputs" that the current travel distribution system produces, we will step thru a simple transaction (business trip). This business trip is described to the agent as follows:


Note:  It is important to remember, that before, during, and after this transaction (basically all the time), a dialog is occurring between the CRS/GDS and the Vendor systems to keep the CRS/GDS databases up to date.
Current Distribution System (CRS/GDS Data Base Updates)

The transaction (trip) processing from a communication and "output" perspective:

 
Employee calls the Agency
 
Agent interacts with the CRS/GDS (usually with "catalog" and "free-sell space")
 
Agent "Ends" PNR, CRS/GDS interacts with Vendor systems. On-line Vendors create Reservations
 
Agent calls SouthWest (not On-Line), checks "space" with SouthWest. Is available, so creates SouthWest Reservation
 
Employee - Agent call "ended". Agent "issues" Ticket and Invoice/Itinerary command. Ticket, Invoice/Itinerary, and B/O (Back Office) data sent to the Agency
 
Ticket and Invoice/Itinerary delivered to Employee
 
Some time later (usually weeks), Corporate Report generated from B/O (Back Office) data
 
Corporate Report delivered to "Companies". At this point all the important "output" has been created!

The important "outputs" generated by the Current Travel Distribution System are:

Note: The first four are absolutely critical to the system! The "Corporate Reports" are desired by many corporations (since they pay most of the bills, they sometimes get what they want), are therefor not really optional. The "B/O (Back Office) Data" is used in three primary ways. These are: Agency Negotiation & Internal Reports, Agency Accounting, and producing the "Corporate Reports". Therefor, for all intents and purposes, this "output", is not really optional either!


With these six (6) important "outputs" in mind, how would some of the "players" in the travel distribution industry like to see it evolve?

Agency Centric CRS/GDS Centric Vendor Centric

Each of these "views" of a "properly" evolved travel distribution industry has some major flaws!

The "Agency Centric" travel distribution model's primary flaw is that there is NO WAY the Vendors will allow the Agency community to get this powerful!

The "CRS/GDS Centric" travel distribution model is actually the easiest to visualize coming about. This is due to how close the CRS/GDS are now. However, the current Vendors utilizing the CRS/GDS have already begun to complain about the costs of CRS/GDS participation. Given that the DOT has labeled the CRS/GDSs as an "Oligopoly" with all its attendant monopolistic practices, it is unlikely that the Vendors want to encourage greater utilization of the CRS/GDS. In addition, the economics of the Vendor/CRS relationship severely limit the CRS/GDSs from lowering their charges to the Vendors to attract the remaining "off-line" Vendors. Given the costs of the CRS/GDS infrastructure (the networks, the mainframes, and the small army of TPF developers), it is unlikely that any CRS/GDS can substantially lower their costs. If a CRS/GDS can not lower its costs, dramatically lowering its charges (to attract the "rest" of the Vendors) is highly unlikely! (Note: I believe that most of the largest Vendors utilizing the CRS/GDS have "best price" clauses in their CRS/GDS contracts. This means that any price reduction for "new, small" Vendors would automatically have a LARGE negative impact on the CRS/GDS revenues!)

The "Vendor Centric" travel distribution model is compelling! If for no other reason than the "Golden Rule" ("He with the Gold, Makes the Rules")! Quite a few Vendors believe that this model is possible with the Internet. However, the Internet, as it now exists, has a number of flaws. Foremost among them is: "Without some intermediary, comparison shopping (from Web site to Web site) is so cumbersome as to be virtually impossible!" In addition, where would the PNR "live", and what would it "point/reference" to? And, what of the "Corporate Reports"?


With all of the above in mind, what would the "ultimate" (least expensive for all parties) intermediary (for the "Vendor Centric" travel distribution model) look like?

Some sort of "bridge" between the Agencies, CRS/GDS, Employees/Consumers, and the Vendors!

Future Distribution System (Travel Exchange)

The "Travel Exchange", MUST produce the important "outputs" generated by the Current Travel Distribution System:

and to accomplish this, must replace the Critical CRS/GDS Value Adds: Given that the Internet provides: The "Travel Exchange" must provide (or facilitate):

If one assumed that an appropriate "EDI Travel Related Protocol" existed, and that all (or a large percentage) of Vendors supported it on Servers attached to the Internet, then "On-Line Comparison Shopping" would be nothing more than collating query responses from the appropriate Vendors!

This leaves the "Travel Exchange" nothing more to do than the maintenance, and distribution of:


"Travel Exchange" production of "Outputs" required by the Customers/Vendors

We will now step thru the same simple transaction (business trip) described above. But this time utilizing the "Travel Exchange".


Note:  It is important to remember, that before, during, and after this transaction (basically all the time), a dialog is occurring between the "Travel Exchange" and the Vendor systems to keep the "Travel Exchange" databases up to date.
Future Distribution System ("Travel Exchange" Data Base Updates)

The transaction (trip) processing from a communication and "output" perspective:

 
Employee system "links" to the "Travel Exchange" fetching "deltas" of Data Base changes (in the background)
Note: the "delta" fetching above will occur (in the background) as long as there are "deltas" to fetch, and the Employee/Consumer is "running" the "Travel Exchange" Client software (probably written in Java).
 
Employee selects "acceptable" Vendors to "shop"
Note: the Employee would do the above for each of the seven "markets" of this trip (3 Cities/Hotels, and 4 Air Segments). After the Employee has selected "Vendors to Shop" for the first market (in whichever order "they" choose), while they are selecting "Vendors to Shop" for other markets, in the background, the Client software is querying the previous Vendors for pricing on the requested product.
 
"Book" messages are sent to the "DESIRED" Vendors, Vendor Reservations are created, and PNR is created

 
There are a number of options for the generation and delivery of the Tickets, Invoice/Itinerary, and B/O (Back Office) data. Three are:
Near Term Mid Term Long Term
Agency using CRS passive Segs produces Ticket & Docs & B/O Data Vendors produce Tickets, Agency does the Rest Vendor / Internet Direct
 

 
Some time later (usually weeks), Corporate Report generated from B/O (Back Office) data
 
Corporate Report delivered to "Companies". At this point all the important "outputs" have been created!

Again, the important "outputs" are:


"Travel Exchange" systems and revenue opportunities

There are eight (8) systems and/or revenue opportunities that make up the "Travel Exchange". They are:


 
Vendor Based Internet Servers
 
Central Catalog and Routing Server
 
Employee/Consumer Client
 
Legacy CRS/GDS Bridge
 
Agency Bridge
 
Company Bridge
 
24 Hour Service Center
 
Advertising Revenue

Once the "Travel Exchange" starts to garner the support of a significant number of travel vendors, with its low costs, I believe that there will be a kind of "snow ball" effect. This will result in, not only, a dramatic growth of the "Travel Exchange", but a corresponding "shrinkage" of the CRS/GDS. This combined "Travel Exchange" growth, and corresponding accelerating "shrinkage" of the CRS/GDS will lead to their complete collapse!
"Travel Exchange" Eliminates CRS/GDS

Along with this dramatic growth of the "Travel Exchange" will come increasing Employee/Consumer (and Companies) confidence in it. This increasing confidence will lead to a dramatic shift away from using the Travel Agencies!
"Shrinkage" of Travel Agencies

The final question is: At the moment, there seems to be four (4) entities that could build it. They are:

I would like to thank Skip Cavanaugh (of IBM/ISSC) for starting me to think about this idea. On a chance flight to Seattle, we were sitting across from each other, we started talking, and he told me a little about a project IBM/ISSC was working on. A project about the Internet, Dis-intermediation, and Wood Products - a "Lumber Exchange"! Facilitating a commodity market on the Internet!
If you have any further questions, please feel free to contact me thru my home page at http://www.SNS.to
P.S. The protocol issue: The American Hotel and Motel Association has formed a committee to create Web based booking and reservation protocols. In addition, American Express is sponsoring the "Internet Purchasing Roundtable" to create OBI-1 (Open Buying on the Internet). These developments are very promising. One might say: