| SURPRISE '97 - Intelligent Agent Technology in Travel Reservation Systems |
| Imperial College of Science Technology and Medicine
Departments of Computing and Electronic Engineering |
| May 22 1997 |
Travel Reservation Systems
A General Overview
Alexis R D Michaelides ( ardm@doc.ic.ac.uk
)
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:
Other fields would include:
As far as the ticket or reservation type, the best way to describe this
field is by quoting some examples from Sabre:
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:
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:
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:
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.
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:
| 1 | An Introduction to Sabre With Windows | |||||||||||
| Sabre Europe | ||||||||||||
|
||||||||||||
|
||||||||||||
| Content : Operating Manual for Sabre With Windows | ||||||||||||
| Obtained From : Demstar Leisure Ltd, Cyprus |
| 2 | Intelligent Agents: A Technology and Business Application Analysis | |||||||||||
| Kathryn Heilmann, 1995 | ||||||||||||
|
||||||||||||
|
||||||||||||
| Content : Information on Intelligent Travel Agents | ||||||||||||
| On-Line : http://haas.berkeley.edu/~heilmann/agents/#exsum | ||||||||||||
| Obtained From : WEB |
| 3 | Travelocity Website | |||||||||||
| Travelocity, 1997 | ||||||||||||
|
||||||||||||
|
||||||||||||
| Content : An on-line travel reservation system | ||||||||||||
| On-Line : http://www.travelocity.com | ||||||||||||
| Obtained From : WEB |
| 5 | Software Agents: An Overview | |||||||||||
| Hyacinth S. Nwana, 1996 | ||||||||||||
| Knowledge Engineering Review vol. 11:3, 205-244 | ||||||||||||
|
||||||||||||
|
||||||||||||
| Content : Paper investigating possibilities for the classification and typology of software agents | ||||||||||||
| On-Line : http://www.cs.umbc.edu/agents/introduction/ao/ | ||||||||||||
| Obtained From : WWW, I.C. Central Library |