The Intranet part of phase 1 will be used to monitor holiday booking requests and to view any registrations. The data stored will be made up of the following tables:
Contact
Enquiry
Location
Staff

The object of the Intranet is to have the system responsible for booking actions rather than relying on individual staff members to 'remember' what needs to be done with each Enquiry or Booking.

The Intranet would become the paperless system for quotes leading the the extinction of the infamous travel agency 'Booking Card'.

The Contact database will be the store of all types of contact for the Agency. Initially this will be Client data. This database will have future abilty to also store Agents and Suppliers data for future use beyond phase 1 but will NOT BE programmed at phase 1 for the Agency.

The data will be pre-populated when clients complete a holiday booking request online. The database will also have the ability to be automatically updated for all online forms completed on the Agency website.

The Agency will be required to display a privacy policy on their website to advise clients that their information will be used to communicate with them. This statement should also advise that they will have the opportunity to opt-out when they receive electronic marketing. The Client database can then be used for online marketing.

It is strongly recommended that the Agency complete an online request / intranet request also for their call centre enquiries to maximise on the use of client data.

The Enquiry database will be the store on all holiday requests. This will link to the Client DB and also store the details of the holiday request / booking. The holiday request will contain all the information on the location, party size, dates of travel, accommodation required and all necessary details of the booking / request.

The Agency will have the ability to define the 'Status' setting of a booking. These settings may be listings such as New Enquiry, Pending Supplier Confirmation, Pending Quote, Pending Payment, Pending Availability Check, Completed, Will Not Book, Quoted Client, Follow Up Client, and so on. The Enquiry will have a status and users will have the ability to amend an enquiry status, subject to rights.

The Agency will have the ability to review the Enquiry DB based on status and set action dates. For example, a Client quoted on a Monday might be flagged for a follow up call on Wednesday.

A holiday request based on a charter flight from Airscan and accommodation from the Tripper bedbank may well have the status set to Pending Availability Check. A simple text based notepad would then be utilized. A staff member would then be able to add comments like ' flights avl, waiting on hotel to confirm avl'. The comment would be tagged with the date, time and staff id. Other users would then be able to see the Status clearly for a booking request. The system could be set to warn a user of bookings of a certain status type that were more than 'x' days old. So in our example here, a staff member could receive a warning on all enquiries where the Status has been Pending Availability Check for 1 day.

The Location database will need to store tables on at least the following:
Airport
City
Country

There will also need to be additional location nodes for example:
City Region: An area witihin a City such as Kensington London, Midtown Manhattan, Zone 1 Paris.
Country Region: An area witihn a Country such as a Canadian Province, a US State, a UK County.
Continental Region: A geographical area larger than a Country. the Caribbean, the Americas, Europe.

There are issues with areas such a Orange County which is a Country Region and Florida which would also be a Country Region. The Agency will also need to clarify where they want Resorts to fit into the Location structure. Areas such as Playa de las Americas in Tenerife and Los Cristianos. They are known as 2 separate resorts but are actually next to each other and serviced by the same airport. Definition needs to be clarified on whether a Resort is always a City Region, always a Country Region or is another Location Category required.

The Staff members would be listed in the Staff table. The agency will be able to define teams and team leaders. Staff will required to log onto the Intranet. The system will then automatically know which user id to assign to comments such as the Status of an Enquiry.

A security flag could be introduced to control which Staff can amend the status of an Enquiry.

A team leader could receive warnings on the Enquiry Status of Staff who they are responsible for. As in our example above, Staff A might be responsible for Staff B. If Staff B was waiting for Supplier Availability Check and was not in the office the next working day, the system could advise Staff A to maintain continuity in the booking process.

Note for future:
A staff member may switch teams. A report needs to reflect the teams at the time of the booking/request so an enquiry should store the user id and team id. Reports can then still be based on a team or a user and the team mode would not be affected due to the staff member switch.