Last minute travel discount

The biggest share of the German travel market is tour packages. A usual tour package contains the flight to the destination and back, transfers from the airport to the hotel and back, board, and lodging. The market share for individual tours is much smaller than in the United States and other countries. It is common practice to offer tour packages that could not be sold until four weeks before departure as last-minute tours. Usually, a discount is given to the customer for these tour packages. Especially in recent years, the market for last-minute packages has grown by a vast amount, and there are specific properties related to these products:

Property 1: Travel agents struggle with the update problem. As many as 6000 new packages are offered daily by just one of the major German tour providers. Traditionally, tour providers send several dozen sheets of paper to their travel agents every day to inform them about available special offers.

Property 2: The method of informing agents by stacks of papers implies an availability problem. Often, the amount of places that can be booked on a specific offer is highly limited. Hence, when customers decide on one of the offers, there is a high risk that it is no longer available because there is no feedback about offers that have been brought to the market in recent days; that is, it is not clear whether these offers are still available or not.

Property 3: Last-minute offers (as provided by the tour providers) are tour packages. Thus, the customer can accept an offer only as it is; there are no variations to it (except if it is stored as a separate offer). Consequently, there is no negotiation during the sales process.

Property 4: Although there might be a huge number of offers, it is unlikely that the desires of a customer can be fulfilled all at once. Rather, it is often the case that alternative departure dates, neighboring airports, or even other destinations need to be suggested. In contrast to people having planned and prepared their holiday carefully, customers looking for last-minute vacations expect such variations. It seems that electronic commerce would be a good way to sell these travel packages. Some of the tour operators are offering database-driven systems on the web to sell their tour packages.(1) A shortcoming of these applications is that ordinary search requests (usually internally realized with some database query language) are not sufficient enough. Customers usually have a certain idea of what kind of tour they would like to book. They do have a preferred country, departure date, and length of tour. If the customer now specifies the request in detail, then most of the time, a traditional system tells the customer "No hits found!" meaning that no tour package in their database matches the request exactly (no solution situation). The customer then has to widen the request by leaving some of the input fields blank. The result is that the system probably will present the customer with several thousand possible tour packages (1000-solutions situation). These lists are usually not even ranked according to the request of the customer; so, the customer has to look through all the presented offers to find the best-matching tour package. The behavior of these conventional systems does not reflect a sales process at all. A good travel agent would never tell a customer that there is no tour package matching the request and send him/her away. Instead, the travel agent would propose some similar tour packages. Thus, an application was needed that implements a vague matching and ranks the found tour packages according to the customer's request.

Application Description

The last-minute travel application (figure 1) is only one part of a complete VIRTUAL TRAVEL AGENCY. As an electronic-commerce application, it is fully accessible by the web. The customer usually connects to the last-minute travel application by following a link from the web pages of the VIRTUAL TRAVEL AGENCY. The presented web page contains a form where information about the destination, the travel date, the kind of hotel room, and some other data can be entered. Note that all these input fields can also be left blank, which means that the customer does not care about these features. After sending the given information to the web server of the VIRTUAL TRAVEL AGENCY, a common gateway interface (CGI) script is started, the retrieval client. This retrieval client will then contact the retrieval server, which is running in the background. The retrieval server is running 24 hours a day and can handle requests from several CGI scripts at once. The number of simultaneous retrieval clients is only limited by the system hardware. The retrieval is performed using case-based reasoning (CBR) (Lenz et al. 1998) in the server, and the result, a sorted list of tour packages, is sent back to the retrieval client. The offered tour packages are ranked according to how well they fit the customer's request. A template page in HTML format is loaded by the retrieval client, and the features of the retrieved tour packages are inserted into the page before sending it back to the customer's web browser. If exact matches are found, they will be displayed first, followed by tour packages that are most similar. The customer can decide how many offers are presented to him/her. Background information, such as facts about the destination country or a single tour package, are provided by clicking on the appropriate link. If the customer decides to book a tour package, another form has to be filled out, and this information is then sent to the real travel agency by e-mail. The travel agency contacts the customer to verify the booking and information given. No real online payment is implemented yet because of security concerns. The main component of the client-server system is the retrieval server, which implements a case-based system.

[Figure 1 ILLUSTRATION OMITTED]

The tour package data are provided daily by the tour operator as an ASCII file. This file is automatically downloaded by Ftp. The update component is now used to transfer the raw data into a more appropriate structure. Information about the offered tour packages is gathered during the updating process. This information and the tour package data are then loaded by the retrieval server. This updating process is automatically started daily by a "CRONJOB" (a specific kind of batch job that is automatically started and scheduled by the operating system) but can also be triggered manually if needed. The whole system was developed in the UNIX environment and is now running on a LINUX PC. All components have been coded in c++. The entire VIRTUAL TRAVEL AGENCY consists of 20,000 lines of code, including all additional components. A Microsoft web server on a WINDOWS NT PC is used to connect the last-minute travel application to the web. The user interface is completely implemented in HTML, so no plug in or special browser is needed by the customer. The highest possible compatibility was the prime reason for this. To remain flexible with respect to changes in the layout of the various pages and not overload the programs with too much information about the HTML layout, we implemented a strategy in which template HTML pages are provided by the travel agents. These are then used within the system, and the data that correspond to the current session are placed in these templates. Thus, the implementation of customized releases for other partners was reasonably easy.

Uses of AI Technology

In this section, we discuss case-based reasoning, integration, and insights.

Case-Based Reasoning

As already discussed, simple database approaches would not be sufficient for implementing this type of application because they cannot provide intelligent sales support. In particular, the following features are essential:

First, some customers enter very detailed descriptions of their intended tour packages, but others only have a rough idea. Consequently, the system has to be able to deal with vague, as well as highly specific, queries.

Second, because of property 4, the system has to be able to suggest appropriate alternatives if no offer completely fits the customer's requirements. The system has to present the available offers to the customer in a reasonable manner. In particular, it should definitely avoid situations in which no offer is made to the customer (no solution situation) as well as those where the customer is left alone with pages and pages of possible offers (1000-solutions situation).

CBR, in general, is a technology that satisfies at least the last two criteria:

First, alternatives are suggested by considering similar offers where the similarity measure takes into account information about departure dates, geographic locations of departure airports and destinations, climatic conditions, and so on.