Abstract:
A businessman walks in to a travel agent and requests a flight to Los Angeles via New York. But that's not all. A seven-night stay at a certain hotel, a train ticket to Washington and his return flight with stops in Chicago and Manchester. Of course, rental cars must be available on-the-spot at all his destinations. Any travel agent without a decent connection to airlines, hotels, car rental companies etc would call this businessman mad. Since most of us take this complex coordination between travel services for granted, this article will try to show what's happening (or should be happening) when the travel agent types away at his keyboard.

1 General Descriptions
To start with, we have to recognize the requirements of any reservation system Since such systems already exist, a general overview can be obtained by investigating one of the. The most well-known distributed systems are Sabre, Galileo and Amadeus. They all more-or-less offer the same facilities, but for the purposes of this article Sabre [1] will be taken into consideration.

The main thing we have to keep in mind is that these systems deal with people, with varying choices and tastes. Therefore the main link between the agent's reservation system and customer should be the customer's details. From here we can now start to build up the customer's itinerary, which can be a simple one-way or return trip, or even one with multiple segments, including various modes of travel and places of stay.

We'll also have to discuss what other facilities can be offered, such as weather information, visa and health requirements, tourist attractions etc.

This article will deal with and briefly describe the most common of these facilities and services, but will not delve into the depths of data structures, relational database entries and other technical descriptions, since this would deviate from our main cause.



2 System Basics
Although it was said that technical details would not be discussed, some notes should be made on the general operation of such a system. To start with, any information given to or taken from the system should be up to date. Nobody cares what tomorrow's flight availability was like last week, so all data should be kept up-to-date, by one means or another. Although, as the lucky few who have used it before will know, Sabre is a bad example, the user interface should be made as concise and friendly as possible. However, since the systems have been used by trained personnel so far (travel agents, tour operators etc), this point can be overlooked.

Sooner or later though, these systems will be made accessible to the general public, where the interface in such a system must have a user-friendly interface, since nobody will want to read a 300-page manual just to book a journey from A to B! And since most people (whether trained personnel or not) are impatient by nature, the system should be responsive. After all, the travel agent may have all day, but the businessman won't be very pleased if he has to wait for an hour just to get some information on a flight, let alone book seats on it.



3 Main Facilities of Reservation Systems
All reservation systems have some basic facilities and properties, and they shall be discussed here. Remember that any examples shown are taken from a Sabre-based system, but keep in mind that since all major distributed reservation systems cooperate with each other, they will have a lot in common as far as input/output information is concerned.


3.1 Passenger Records
As was mentioned above, the most important set of data used in any reservation system is customer details. After all, without customers (ie travelers), there would be no need to write this article in the first place! Systems keep Passenger Name Records (PNR), whose main aim is to store such details. The obvious (and mandatory) fields would be:

• Name
• Contact number
• Ticket or Reservation Type (more on this below)

Other fields would include:

• Address
• Remarks
• Historical remarks
• Agency address
• Fax No

As far as the ticket or reservation type, the best way to describe this field is by quoting some examples from Sabre:

• Fragile baggage
• First available flight
• Group seat request
• Medical case
• Meal details (baby, vegetarian, religion-based etc)
• Disabilities (wheelchair, blind, deaf etc)
• Smoking or non-smoking seat

The above are just a small excerpt of available entries using Sabre , but hopefully they have given a good example of the depth of information stored on a customer. For group travel, multiple PNRs can be created and linked under one main record, making both the agency and overall system more efficient.


3.2 Where Do We Go Now?
Now that the agent knows who the customer is, the next obvious step would be to actually book all travel details required. Availability is the main concern on both the customer's and agent's head, so any reservation system should allow the user to check for availability of travel seats (could be by air, land or sea... and we can leave our options open for space travel too!). Obviously, any traveler has at least one point of departure and one point of arrival. More complex itineraries can be built from the simple origin-destination city pair model, so we shall only deal with this in detail, and mention briefly how this can be adjusted to conform with more demanding travelers.

Using airline reservations as a model, here are the most obvious entries required by any system to give results:

• Departure city
• Arrival city
• Date required for travel

These should be enough for the system to list all flights between the city pair. From here, the agent can select what fare class is required, and availability can be displayed. However, just the above information is not enough to make a complete booking, so some further input on behalf of the agent is required. This would include:

• Choice of carrier
• Direct or flight with connecting city
• One-way or return booking

A segment is defined as each origin-destination city pair (connecting cities are considered as a separate segment). By adding more segments, the system can be used to create more complex travel plans, such as outgoing and return flights with different connecting cities and stops or even round-the-world tours (if the customer can afford it!).


3.3 Other Basic Features
The full functionality of any travel reservation system can only be obtained when more than one varied services can be merged into a single system. A travel agent's life can be made very complicated if he has to use separate unrelated systems to book flight tickets, make hotel arrangements and arrange for car-rental agreements. Thankfully, most systems, including Sabre, interrelate these services, thus making everything more efficient and reliable.

Unfortunately, unlike airlines where there is a strict 'regime' to follow concerning reservations, hotels and car-rental companies have a much less formal approach to such systems. This means that unless all (or at least, the majority of) hotels and car-hire companies agree to use similar or compatible systems, there will still be major loopholes in the existing reservation systems. Another problem is the vast number of hotels and car-hire companies, in relation to airlines.

That said, for hotels which are connected to such systems, the main (and obvious) entries required would be:

• Hotel name
• In date
• Out date
• Room type

Very similar entries are also used for car-rental agreements. Again, the assumption has to be made that companies keep up-to-date information on their status, so anybody using the system can be sure of whatever type of travel reservations they make.


3.4 More Facilities.... or Just Gimmicks?
The above sections discussed the main features required to make any reservation system work properly and satisfactorily to meet most customer's demands. However, as more and more up to date information can be obtained on-line, these systems can integrate more facilities allowing one to access this material. Some of these facilities are discussed briefly below.

• Currency
  Until the whole world can use a single currency, there is always the problem of ever-changing exchange rates, and trying to keep up to date. Since a ticket from London to Zurich can be purchased anywhere in the world, the reservation system should be able to calculate the fare in local currency, or at least, have the ability to access the current exchange rates, using one method or another.
  
  
• Visa and Health Information
  Another important issue when travelling is visa and health requirements. Although these can be obtained from the country's embassy or consulate, it would be much easier if the traveller was made aware of any such requirements by the agent. Reservation systems can access information on visa and health requirements, thus making travel plans easier for all.
  
  
• Weather
  Information on weather can also prove helpful, especially when planning on what to pack! Of course, due to our limited accuracy on foreseeing the weather in the distant future, forecast information for the following week or so can be obtained via reservation systems connected to such sources.
  
  
• Tourist Attractions
  Although all countries have some form of brochure or other informing tourists of any attractions, it would be a hard task for a travel agent to keep copies of them locally. So, reservation systems come in to save tha day once again. Up-to-date information on tourist sights and attractions of various countries can be kept in a database and accessed when required.

4 Some Hidden Details
When one is connected to a reservation system, some data may indeed be out of date, or even not accounted for at all. Thus the ability to directly connect to an airline's computer systems and retrieve data from there should be available. This can be either done by direct access methods, where the agent can actually dial-up the airline's server and request information, or a neater method would be via the reservation system being used. Sabre allows for such access methods, where the travel agent can connect to an airline's database and retrieve up-to-date or more information as required.

It is hard to have continuous access from all reservation systems to all airlines, or to all their databases. So a form of message queuing should also be made available, where a travel reservation can be made using current data, a message can be sent to the required company, and a confirmation then retrieved when available.





5 Conclusions
Have these reservation systems matured? In a way, yes. However, there is still much to be done in the way of user-interfaces, especially if they are to be made available to the general public via on-line services. A very good example of such an effort is Travelocity, a company who is now providing their services via the web [3] (See [4] for an article discussing the methods used to implement these services).

In this article, we didn't discuss the actual UI used, but it can be said that since these systems are not yet available to the public, not much has been done to improve the interface to the levels found in other programs.

As far as functionality is concerned, the systems used by most companies provide for almost all contingencies, and since the major systems are inter-accessible, the overall result is a broader range of facilities for the users. There is still much improvement left to be done on the side of hotel, car-rental and sea travel reservations, since the original development of these systems took into account the increasing demand in air travel only, with some extra facilities allowed for other services as well.

However, keeping in mind that all the reservations made are automatically linked by the system to the PNR ( section 3.1 ) of the customer, these can be extended to provide for any type of travel service. Therefore as more and more travel service companies link up with existing systems, new system designs will have to be thought out and developed.



List of References: