Travel Tours Booking System on Salesforce Platform

FUNCTIONAL REQUIREMENTS

High Level Requirements

• The platform will be built on Salesforce.

• The platform will support three types of users: Traveler, Travel Agent, Admin.
• The platform will allow Travelers and Agents to register online.
• The platform will allow a Traveler or Agent to log in and view available bookings. The
available bookings will be for pre-scheduled weekly tours, which means that each tour
leaves on a set day of the week and has a set itinerary and duration. For instance, Tour 1
always starts on a Tuesday and runs for 9 days, while Tour 2 always starts on a Wednesday
and runs 11 days.
• The platform will allow the Traveler or Agent to make a booking for a travel group comprising
one or more travelers.
• The platform allow the Admin to generate an invoice out of the system that is sent to the
Traveler or Agent, and the platform will allow the Traveler or Agent to make payments on the
platform.
• Travelers and Agents will have a dashboard where they can see all their bookings, and their
status, and move their bookings farther along in the booking process.
• Travelers/Agents can send a message to the Back Office and those messages will be sent
via email as well as be stored on the system. In addition, any party can respond to an email
and the message gets added to the message trail available on the platform. In other words,
it will act exactly like the Messages work in the Upwork platform.
• The bookings can be made by a Traveler, by an Agent, or by an Admin (in the case where
our back office person is making the booking on behalf of the customer).
• There will be an Admin interface that will allow an Admin to manage bookings, tours,
payments, users and other settings.

Phased Delivery Approach

To facilitate testing, the functionality should be delivered in weekly testable code drops. We will
leave it up to the web developer to come up with the most efficient timeline. Time is of the
essence, as we require completion of the initial project within 3-4 weeks.

Maintenance and Warranty

• Towards the end of the testing period, the web developer will set up a new, clean production
instance of the platform for go-live, with its own copy of the code and database. The original
instance will be retained for support purposes and for staging/testing of future
enhancements that we will contract with the web developer.
• Warranty: there will be a 6-month warranty period, starting from when the testing is
concluded and all logged defects are resolved, during which the web developer will address
any newly-discovered bugs that were missed earlier.

Detailed Requirements – Overall Look and Feel

• The web developer may go with any of the following options, whichever will result in fastest
delivery:
o Follow the look and feel of www.tokenya.com
o Follow the look and feel of www.tourconnector.com
o Create a new look and feel that is quick, clean, professional
• All users, whether logged in or not, will always see a top banner with the menu options
“Tours”, “Tour Brochure”, “FAQ”, a contact phone number and email address, and a
“Inquire” button to initiate the inquiry/reservation flow.
• Logged-in Agents and Travelers will also see additional options. Their banner will show the
menu options “Tours”, “My Trips”, “Tour Brochure”, a contact phone number and email
address, an “Inquire” button, and a way to access the user’s Profile and to Log Out.
• The “Tour Brochure” menu option will link to the Landing Page, described below. Note also
that we expect the Landing Page to be the point of entry for most visitors to the website.
• Times shown on the platform will default to the timezone of the user browser.
• Currencies shown on the platform will clearly be designated as “USD”.
• The platform will be responsive and able to render properly on a computer screen, tablet or
mobile device.

NOTE: In this document, screenshots shown are pulled from websites of various tour
companies and are displayed for sample purposes only, to show general format. Actual colors
and fonts will follow the look and feel of our existing website.

Process Flow
Here is the process flow a user making a reservation will go through. This flow is the same
whether the user is a Traveler (end user) or an Agent. It is also the same for an Admin that is
processing the booking for the Traveler/Agent.

1. Traveler/Agent sees a link about our tour offerings (via search, an ad, an affiliate
website, etc) and clicks on it.
2. The link brings them to the Landing Page where they can browse the Wetu-hosted
online brochure/itinerary
3. Traveler/Agent clicks the “Inquire” button at the top. That brings them to the Tour Dates
page for that particular tour. There should also be a way for them to see other tours that
we offer.
4. Traveler/Agent scrolls down to the date they want and expands it.
5. Traveler/Agent clicks the “Inquire Now” button. This pops up a window where the user
enters basic info and submits it. They can optionally create a login while doing this.
6. Our back office receives the info and reaches out to the Traveler/Agent. During those
conversations, the Traveler/Agent creates a login or has the Admin (back office) create
one for them.
7. Traveler/Agent logs into the platform and sees their current booking(s). The booking will
have two tabs: Basic Information and Traveler Details. The user can enter this
information, or perhaps the Admin entered it for them.
8. At some point, Admin goes into the booking and clicks the “Send Invoice” button.
9. Traveler/Agent receives an email with the invoice and a link to log into the application.
When they log in, they can access their same reservation, except that there are now two
new tabs: one for “Payment” and one for “Confirmation”. The platform will bring them to
the Payment tab. Note that the Payment tab is not available until the Invoice is sent.
 10. Traveler/Agent enters payment details and the platform processes their online payment.
Or the Admin enters the payment details for them and process the payment.
11. If the Payment entered is a partial payment, the booking will continue to come to the
Payment page as the “current” step, until the payment is made in full.
12. The Confirmation tab will show that the booking is confirmed, once the Admin goes in
and sets that booking as Confirmed. Note that bookings can be confirmed even when
not yet paid in full. So the Confirmation tab will reflect the status of Confirmed (or not) as
well as the amount paid and balance still due.

Landing Page

• The landing page will typically be the entry point for a visitor to the site. It will be a page that
shows the details of our tour offering in the form of an online brochure. This brochure will be
displayed by the platform wetu.com. We already have a sample itinerary at this URL that
can be used for development purposes.
• The landing page will have a top banner with our contact number, contact email address, a
“Log In” link and an “Inquire” button.
• Below the top banner the landing page will display the content from the wetu.com URL
above.
• When the user clicks the “Inquire” button they will be brought to the Tours Page on our
website, described below, and they can start the booking inquiry process. They can do that
as a guest (i.e. they do not need to log in).
• If the user clicks the Login button they will be brought to the login page for our website,
where they can sign in or register. Once they log in they will be brought to their Dashboard
page.

Dashboard Page

• A logged in user will be brought to a Dashboard page where they have access to view their
existing reservations (in whatever status they are) or to initiate a new inquiry/reservation.
• If they have an existing in-progress reservation, that reservation should be featured
prominently on the dashboard. By clicking on that reservation they will be taken to the
reservation details, which will be displayed in the form of a wizard showing the various steps
of the reservation process as different tabs, with the current tab being the one that reflects
the current status of the reservation. The steps for the reservation are:
o Basic Information
o Traveler Details
o Payment
o Confirmed
• If they don’t have an existing reservation, then the Dashboard will list available tours where
they can see the different tours and pick one.
• When they click on a Tour, they will be brought to the Tour Dates Page (see below) which
shows them the future departure dates for the tour and the availability on each of those
dates.
• Note that a Traveler, an Agent and an Admin will all see the same booking wizard layout.
For instance, if a Traveler wants to finish their booking over the phone, the Admin can log in,
access the booking (which will take them to the tab reflecting the current status of the
booking) and they can enter the required information to move that booking forward just like
the end-user Traveler would.
Tour Dates Page

• This is the page that shows the available tours and allows a user (Traveler or Agent) to
initiate a booking.
• Note that they do not need to be logged in yet as they could have come there from the
Landing Page. If they choose to book a tour we will have them optionally create a user id
and password as part of the booking process.
• Clicking the “Tours” option in the Top menu will always bring the user to this Tours Page.
• The system will support multiple tour offerings, but for initial roll-out we intend to start with a
single weekly tour offering. See the wetu.com itinerary above for a sample of what this tour
may look like. Tours will be configurable via the “Manage Tours” admin section.
• User will select from the available tours, and then will see the list of available dates for that
tour. If there is only one tour configured in the system, the Tours Page will directly show the
available tour dates for that single tour.
• When displaying available dates for a tour, the page will display trips available for the next
year, so there will be 52 tours showing up on the page. The trips are designated by Start
Date and End Date, such as below:

• Each departure will show one of three statuses: Available, “Call for Availability”, or “SOLD
OUT”.
• Above the list will be the message “Air fare from NYC to Nairobi included! Seats are pre-
booked and guaranteed.”
• Next to the above message will be a “More Info” link which pops up a window with the
following additional informational text:
All tours start with a direct flight from JFK Airport to Nairobi, with a flight departure time
of 12:25 PM.
Once you complete your reservation, including any required deposit, we will send you
your flight confirmation number within 24 hrs.
• At the top and bottom of the list will be a method to page forward to one more year of tours,
and to page back to the initial page.
• Clicking on a tour will expand the tour details:
• However, note that the screenshot above is from a different tour company, just to show the
basic format. The fields that we want to display on our platform are Adult Price, Single
Supplement, Child Price, Deposit and Availability.
o Adult Price, Single Supplement, Child Price and Deposit will be determined by the
travel season that the departure date falls in (see “Manage Pricing Seasons” in the
Admin section)
o Under the prices, in italics (similar to above screenshot) will be the message “Air fare
from US to Africa included”.
• If the booking availability is “Call for Availability” when the departure date is expanded as
shown below, it will display four columns of information (Adult Price, Single Supplement,
Child Price and Deposit) and an “Inquire by Phone” button. We will not have the “Availability”
column shown below.

• If the booking availability is “Available” when the departure date is expanded as shown
below, it will display five columns of information (Adult Price, Single Supplement, Child
Price, Deposit and Availability). The “Availability” column will display the number of seats
available e.g. “4 seats available”. There will also be two buttons instead of the “Request
Booking” button in the below screenshot:
o “Inquire Online” button
o “Inquire By Phone” button
In addition, we will not have the question about the number of people. That information will
be requested as part of the reservation flow after the user clicks the “Inquire Online” button.
 •

• The Tour Dates page will allow more than one tour date to be expanded, so that the user
can compare availability, pricing, etc.
• When the user clicks the “Inquire By Phone” button (either for an “Available” booking or a
“Call for Availability” booking) a window will pop up. It will display our phone number for
them to call, or give them the option to enter their phone number to receive a call back. If the
user submits a number to be called back on, it will be sent to the “Back Office Notification
List” email address (see Admin section).
• When the user clicks the “Inquire Online” button they will be brought to the Basic Information
tab of the booking workflow, described next.

Tab 1 of Booking Wizard: Basic Information

• This page will be clearly shown to be the first tab of a multi-step booking wizard.
• The input fields required on this tab will be just the basic information we need to be able to
follow up with the potential customer. Those fields are:
o Tour Name (pre-populated by system and non-editable)
o Tour Dates (pre-populated by system and non-editable; shows the start/end dates for
this particular tour departure)
o Number of Adults
o Number of Children
o The Number of Children field should have a question-mark icon (help icon) next to it;
when clicked a pop-up is displayed that says “A traveler qualifies for the child rate if
he/she will be 12 yrs of age or below on the day the trip returns”.
o Next will be a section called “Booking Contact Information” with the following fields:
▪ First Name
▪ Last Name
▪ Email Address
▪ Confirm Email Address
▪ Phone Number (either email address or phone number must be provided)
▪ Preferred Contact Method (radio button with the values “Email” and
“Phone”). Default will be “Email”, unless the Phone Number was the only
contact information provided.
o Special Requests
▪ The “Special Requests” field will be a 3-line text area where the user can
enter any other details they want.
• Below these fields will be note that says, “Flight seats are pre-booked with the airline;
traveler details for all passengers are not needed at this point but will be required at least
one month before departure.”
• Under the above fields will be a section that says “(Optional) Create User ID:” with the
following non-mandatory fields:
o Checkbox (unchecked) that says “I am a Travel Agent”
o User ID
o Password
o Confirm Password
• If the user chooses to create a user id, the system will display the id as available (with a
green tick-mark and text that says “This user id is available”) or unavailable (with a red X
and red text that says “User id already taken, please select a different one”).
• If the user checks the checkbox for “I am a Travel Agent” then the system will display the
“Travel Agent Information” section under the Confirm Password field, with the four fields
shown below. They are all optional, as indicated.

• Under the four Travel Agent Information fields add this text: “Your Agent login will be active
within 1 business day. You are still able to proceed with this booking.”
• Of all the fields on this Basic Information tab, the only data that is required is that the user
must enter either an email address or a phone number. All other fields are optional.
• Once the user enters Basic Information and submits it, the platform will update the
Availability for that departure date. Here are the two scenarios:
o If the date already showed “Call for Availability”, that is what it will remain as.
o Of the date previously showed “Available”, it will now be switched to “Call for
Availability”
Regarding availability, also note that:
o Admin can explicitly set an Availability number, e.g. “4”, in which case the tour date
goes back to “Available”.
o Only the Admin can set a tour date to “SOLD OUT”; the platform will not
automatically do that.

Tab 2 of Booking Wizard: Traveler Details

• This page will be clearly shown to be the second tab of the booking wizard.
• The top of the tab will display the following message:
Please supply the traveler details which will allow us to reserve both your plane ticket
and your tour.
• Based on the number of adult/children travelers in the Basic Information tab, this Traveler
Details tab will have sections titled “First Adult Traveler”, Second Adult Traveler”, First Child
Traveler”, etc.
• Again, the fields here are not mandatory, so the user can enter as much or as little
information as they prefer. We can follow up with them directly for additional information and
the
• Above the section for “First Adult Traveler” will be a message that says, “Enter as much
information as you would like to provide at this point. We will contact you for the rest of the
required traveler information.”
• For each traveler the fields are:
o Title
o First Name (as per passport / travel document)
o Middle Name (as per passport)
o Last Name (as per passport)
o Gender
o Date of Birth
o Needs Single Room (checkbox, unchecked by default)
o Nationality (as per passport)
o Travel Document Type (dropdown with following options): Passenger passport,
Passport card, Identity card, Identity card (special), Identity card (green card), Crew
member certificate, Approved non-standard identity document
o Travel Document Number
o Travel Document Issuing Country
o Travel Document Expiration Date
o Frequent Flyer Airline
o Frequent Flyer Number
o Special Requests For This Traveler
▪ The “Special Requests field will be a 3-line text area where the user can
enter any details they want. Within the text field will be the following
greyed-out tip:
“Enter aisle/window seat preferences, special meal requirements, special
assistance requirements, extra baggage, sports equipment, etc.”

• Below all the traveler information fields will be the following two fields:
o Emergency Contact Name
o Emergency Contact Phone Number
▪ Under that will be two checkboxes, both checked by default:
o Receive notifications from the airline for flight changes via text message
o Receive notifications from the airline for flight changes via email

Tour Invoicing

• The Traveler/Agent will not immediately be asked to make a payment. They will receive a
payment when an Admin pulls up the tour and clicks a “Generate Invoice” button which is
available only to Admins.
• After clicking the button, the system will show the Admin a page with all the payment details.
Those fields will be editable, allowing the Admin to override some fields e.g. to offer some
negotiated discount.
• One of the fields that the Admin will edit is the due date for the invoice.
• After viewing that page, the Admin clicks the “Send Invoice Now” button.
• Clicking that button will send an email to the email address entered on the Basic Information
tab. That email will display a breakdown of the cost plus a link to log into the platform. When
 the user logs in using that link, they should be directed straight to the Payment tab of the
booking wizard (3rd tab in the reservation workflow).

Calculating Tour Payment Amount

• The “Needs Single Room” checkbox for each traveler is important for pricing that will appear
on the Payment Page (described next). Tour prices assume two people sharing a room, and
any traveler that is in a room by themselves is charged the “Single Supplement” in addition
to the regular price. So, assuming a tour costs $4,000 with a Single Supplement of $1,000,
here are some pricing scenarios:
o Two travelers sharing a room: $8,000 total
o Three travelers, two of which will share a room: $12,000 + $1,000
o Three travelers, who each want their own room: $12,000 + $3,0000
o Note that if there is a non-even number of travelers, at least one must pay for the
Single Supplement
• Before an invoice can be generated the birthdates of all travelers need to be entered. The
platform will check the age of each traveler and use it to determine the price. Travelers who
will be 12 years of age or under on the day the trip returns qualify for the child price.
• When the Admin clicks the “Generate Invoice” button, it will display an error message if the
following conditions are present:
o Some required information is missing, e.g. birthdates.
o The number of Single Supplements does not make sense. For instance, if there are
5 travelers, at least one of them has to have the Single Supplement. But if two of
them have the Single Supplement, then that forces a third one to also get a single
room because the remaining three travelers cannot share a single room.

Tab 3 of Booking Wizard: Payment

• After the invoice has been sent, when Traveler/Agent (or Admin) views the Booking thye will
now have the Payment tab available as the 3rd step in the wizard.
• We use Authorize.Net as our payment processor.
• The payment page will have the following radio buttons at the top:
o Pay In Full ($AAA) - $BBB per traveler, plus 2 single supplements of $CCC each
o Pay Deposit ($DDD) - $EEE per traveler
• The “Pay In Full” option will be the one preselected; the user can select the “Pay Deposit”
option instead
• The Pay in Full price ($AAA) is calculated based on number of travelers and number of
Single Supplements
• The $DDD total deposit is the required deposit per traveler multiplied by the number of
travelers
• The Deposit per traveler($EEE) is configured by the Admin.

• On the Payment Page will also have the following radio buttons for method of payment:
o Credit or Debit Card
o Pay Later

• If the user selects “Credit or Debit Card”, they will then be presented with radio buttons for
Visa, MasterCard or American Express. Once they select one of the options, the standard
 fields for credit card payment (Credit Card Number, Expiry, Security Code, and Address
fields) will be displayed. You can assume American-style addresses.
• In addition, depending on the type of card, the appropriate security logo will be displayed. It
will either be “Verified by Visa”, “MasterCard SecureCode”, or “American Express SafeKey”.

• I they select “Pay Later”, a popup window will appear with some information about payment
deadlines. This text will be provided.
• Regardless of the option they pick, they will be required to sign off on terms and conditions.
At the bottom of the payment panel will be an unchecked checkbox with the following
statement:
Yes, I have read and accept the Baggage Policy, Fare Conditions, the e-VISA
conditions, the conditions of carriage, the children conditions, and the purchase
conditions.
• Each of the above policies will be a link; clicking the link will open the appropriate policy in a
new browser tab. Content for each of those policies will be provided. See “Other Static
Pages” section below.
• Under the terms and condition will be this note:
PLEASE NOTE: If you are paying by card for a flight, for security check purposes you
are required to bring the card used at the time of booking when traveling. If the card
holder is not traveling then the passenger must bring a copy of credit card, a signed
authorization note from the card holder and a copy of the card holder's passport.
• Note that even though a payment is processed, the availability of inventory (seats) is not
automatically decremented. Inventory is updated when users submit their Basic Information
data as described above, or updated manually by the Admin.
• Every booking that is made is saved to the system and given a unique booking ID. Booking
ID is made up of the following format:
o Day and Month the booking was made (4 digits)
o Day and Month of tour departure (4 digits)
o First three letters of last name of primary traveler (first adult), all caps
o First 3 letters of Agency name, all caps, if booked by an Agent
o Examples are:
▪ 05181202SMIOBR (booked May 18th, departs Dec 2nd, traveler is Gary Smith,
booking made by O’Brien Travel Agency)
▪ 11020806MAC (booked Nov 2nd, departs Aug 6th, traveler is Joan MacLean,
no agent used)
o If the required booking ID is already used, add an incrementing number at the end.
For example:
▪ 05181202SMIOBR
▪ 05181202SMIOBR-1
▪ 05181202SMIOBR-2

• Every booking will have a Payment Status which will be one of these five options:
• Not Invoiced: This is still a new booking, invoice has not been sent
• Invoiced: Invoice has been sent
• Pay Later: User clicked “Pay Later” and no payments have been received yet
• Paid In Full: Full payment has been received
• Partially Paid: Some monies received, but there is still a balance
My Trips

• This will either be a separate page or a section on the Dashboard; web developer can
determine which works better.
• On this page the Traveler will see a listing of the tours they have booked, whether the tour is
in the past or the future. The list display the following columns:
o Tour Name
o Tour Dates (e.g. “Feb 8-16 2018”)
o Number of Travelers
o Price Per Traveler
o Booking Status
o Traveler Details (either “Complete” or “Incomplete”)

• If the user is a Travel Agent:

o The My Trips page, and the link in the top menu, will say “My Bookings” instead of
“My Trips”
o The list of trips will include all trips the Agent has booked for their clients
o If the user is a Travel Agent, the My Trips page will display the column “Traveler
Name” instead of “Tour Name”. The Traveler Name will be the First and Last Name
of the primary traveler (i.e. first adult entered).
o The Travel Agent can click on a booking and a pop-up will display all relevant details
for that booking including the contact information and traveler names. The Agent
cannot edit this information.

Messages

• From their dashboard a Traveler/Agent can access a Message section. From there they can
send a message to the Back Office and those messages will be sent via email as well as be
stored on the system. In addition, any party can respond to an email and the message gets
added to the message trail available on the platform. In other words, it will act exactly like
the Messages work in the Upwork platform.

Login Page

• Registered users can also our login page and sign in there.
• The login page will also provide an option to register.
• The login page will also provide a “Forgot Password” link that will pop up a message saying
“Please call (XXX) YYY-ZZZZ and we will help you reset your password”. The phone
number in the message is the Customer Service Phone Number configured by the Admin
(described below).

Registration Page

• This page is where users register. They will be asked for the following information:
o First Name
o Last Name
o Preferred Contact Method (this will be a radio button with 3 options [Email, Mobile
Phone, Home Phone] with the option for Email pre-selected)
o Email
 o Confirm Email
o Mobile phone
o Home phone
o Checkbox (unchecked) that says “I am a Travel Agent”
o User ID
o Password
o Confirm Password

• If the user checks the checkbox for “I am a Travel Agent” then the system will display the
“Travel Agent Information” section under the Confirm Password field, with the same 4 fields
as on the Booking Details page. On the registration page these fields are required (not
optional) for Agents.
• Under the four Travel Agent Information fields add this text: “Your Agent login will be active
within 1 business day.”
• Note that if the user creates the user id and password on the Booking Details Page as part
of the tour booking process they will not be brought to the registration page as their
registration will happen behind the scenes.
• The registration process will follow all the security protocols that are standard today,
including:
o sending of a confirmation email to the user’s provided email address before the login
is activated
o use of a CAPTCHA mechanism to ensure it is a real user (this CAPTCHA is not used
in the scenario where the user registers during the tour booking flow)
o standard error checking e.g. the behavior described for the Booking Details page to
ensure the selected user id is not already in use

Profile Page

• Registered users (Travelers, Agents and Admins) have access to a Profile page where they
can change their password and change any of the information entered during registration
(other than user id).
• Admin users are not required to enter contact information so they will only have the option of
changing their password.

Admin Pages

• When the Admin logs in they will see a page with the following links:
o Mange Bookings
o Manage Tours
o Manage Payments
o Manage Users
o Manage Pricing Seasons
o Manage Tour Settings

Below is a description of each section.

• Manage Bookings
o Displays list of all bookings in the system
o At top is a way to filter the list by Payment Status. By default all bookings are shown.
 o Admin can also filter the list for bookings for which the basic information is
incomplete, or the traveler details are incomplete.
o At the top is also a field where the user can type in a booking id or first name or last
name of primary traveler, or agency name, or any portion of these criteria, and click
“Search” and the list will be filtered to only bookings that meet the search criteria.
▪ For example, for the booking ID 05181202SMIOBR (booked May 18th,
departs Dec 2nd, Traveler is Gary Smith, booked by O’Brien Travel Agency)
any of the following would return this booking within the search results:
o 0518: booking date and month (portion of Booking ID)
o 1202: departure date and month (portion of Booking ID)
o SMI, Smi, smi, Smith, smith: Traveler last name, or portion of it, case
insensitive
o Gary, GARY, Gar: Traveler first name, or portion of it, case insensitive
o OBR, Obr, O’Brien, O’Brien Travel Agency: Agency name, or portion
of it, or agency name portion of booking ID, case insensitive
o List columns are:
▪ Booking ID: Unique booking ID
▪ Booking Date: Date the booking was made
▪ Departure Date: Date the tour starts
▪ Payment Status
▪ Traveler Information (“Complete” or “Incomplete”)
▪ Traveler Name (First and Last)
▪ Agency Name (if applicable)
▪ Balance Due Date (if applicable))
▪ Balance Due Amount (if applicable
o Admin can click a column header to sort by that column or to reverse the sort if it is
already the sort column. Default sort order is by Booking Date with most recent at the
top.
o List limits each page to 50 items, and provides page back/forward buttons if list
exceeds that size
o Admin can perform the following actions on a booking:
▪ Edit the details
▪ Add/edit Traveler Details
▪ Apply a payment -- admin enters payment amount, and the Balance Due
Amount is adjusted automatically, although admin can also edit that Balance
Due Amount field
▪ Change the status
▪ Toggle the “Traveler Details Complete” between Yes and No
▪ Delete a booking
o Once the Balance Due Amount reaches zero the status of the booking automatically
changes to “Confirmed - Paid In Full”.
o Dates and amounts of all payments are saved and displayed when viewing the
booking

• Manage Tours List

o Displays list of all different tours in the system, and allows the Admin to
create/delete/edit tour offerings.
o Admin can set/edit the following fields for the tour:
▪ Tour Name: E.g. “Amazing Tour”
▪ Departure Day of Week: dropdown of Monday to Sunday
▪ Tour Duration: input field where we can put “9” for number of days
 ▪ Default Maximum Tour Size: by default, set to 12
▪ Pricing
o Admin can disable a tour, which hides it completely from the offerings viewed by
Travelers/Agents.
o Admin can set the pricing seasons for a tour (described below).
o Admin can manage the data associated with particular departure dates for the tour
(e.g. availability) as described in the “Manage Tour Dates” section below.

• Manage Tour Dates

o Allows the admin to edit the details of a particular tour departure date
o Displays list of all different departure dates for the tour, and allows the
o At top is radio buttons to filter the list: All, Future. The option for “Future” is selected
by default.
o List columns are:
▪ Departure Date
▪ Tour Size
▪ Seats Sold
▪ Unsold Seats
o Note that for future tours, the Departure Dates and Tour Size are prepopulated by
default from the tour admin settings of “Departure Day of Week” and “Default
Maximum Tour Size”.
o Admin can click a column header to sort by that column or to reverse the sort if it is
already the sort column. Default sort order is by Departure Date with the earliest
ones first.
o List limits each page to 50 items, and provides page back/forward buttons if list
exceeds that size. This means that an Admin can edit a tour
o Admin can perform the following actions on a Tour:
▪ Edit the details for future tours:
• Departure Date
• Return Date
• Tour Size
• Seats Sold
• Seats Available
• Payments Received (system auto-calculates this non-editable field)
• Payments Pending (system auto-calculates this non-editable field)
• Call for Availability (checkbox that the Admin can set so that the Tours
Page shows the tour as “Call for Availability”.
▪ View the details for past tours:
• Departure Date
• Return Date
• Tour Size
• Seats Sold
• Unsold Seats
• Payments Received (system auto-calculates this non-editable field)

▪ Disable the tour, which removes it from the Tours Page where users make
their bookings
o Admins manage inventory by updating the Seats Sold and Seats Available fields of a
future tour, to reflect bookings that are made or canceled. Inventory is not auto-
updated by the system.
• Manage Payments
o Displays list of payments applied, and totals of the displayed payments.
o Admin can filter the list of payments based on the following filter criteria:
▪ Payment Date (admin chooses a date range, and any payments applied
within that date range are displayed)
▪ Booking Date (admin chooses a date range, and any payments associated
with bookings made within that date range are displayed)
▪ Tour Date (admin chooses a date range, and any payments associated with
tours departing within that date range are displayed)
▪ Booking ID / Name (admin enters a booking id, or section thereof, or traveler
last name, or section thereof, similar to the search logic for Manage
Bookings), and any payments associated with bookings that match that
search criteria are displayed
o Page displays two amounts above the list of payments (or below the list if it prevents
two trips to the database), totaled up for the bookings that meet the search criteria
and are displayed on the page:
▪ Total Payments Received
▪ Total Payments Pending
o The list of payments displays the following columns:
▪ Date
▪ Amount Paid
▪ Balance Remaining (for the booking the payment was made against)
▪ Booking ID
▪ Booking Name (First and Last)
▪ Tour Departure Date
▪ Agency Name (if applicable)
o Admin can click a column header to sort by that column or to reverse the sort if it is
already the sort column. Default sort order is by payment date with oldest on top.

• Manage Users
o Displays list of all users in the system.
o At the top is radio buttons to filter the list: All, Agents, Travelers. “All” selected by
default.
o At the top is also a Search field where the user can type in a user id or first name or
last name, or portion of any of these three criteria, and click “Search” and the list will
be filtered to only users that meet the search criteria.
o The list of users shows the following columns:
▪ User ID
▪ User Type – Traveler, Agent or Admin
▪ User Status – Active, Pending, Disabled
• Pending users are Agents that the Admin has not yet activated
(activation is done manually after Admin verifies their agency
credentials)
▪ Last Login – date of last login
▪ Tours Booked – number of tours booked by the traveler or agent, regardless
of their status
▪ Total Bookings Price – total amount in dollars of all bookings, all travelers (if
the user is an Agent, this will be the total dollars that could have been brought
in by all bookings they have sold)
 ▪ Total Bookings Revenue – total amount in dollars of money actually received
from all bookings, all travelers (if the user is an Agent, this will be the total
dollars actually brought in by all bookings they have sold)

o Admin can click a column header to sort by that column or to reverse the sort if it is
already the sort column.
o List limits each page to 50 items, and provides page back/forward buttons if list
exceeds that size
o Admin can perform the following actions on a user:
▪ Edit their details
▪ Change user status
▪ Delete a user (requires confirmation)
▪ Reset password (sets a new temporary password and user will need to
change their login when they next log in)
o Admin can Add a new user to the system by entering all the relevant details including
the User Type and a Temporary Password (user will be forced to create a new one
on first login)

• Manage Tour Pricing Seasons:

o Displays list of all pricing seasons in the system for the particular tour, identified by
start/end dates. For instance, “Dec 12 2018 - Jan 5 2019” could be a season that is
named “High Season”
o List displays the following columns:
▪ Season Dates (e.g. “Dec 12 2018 - Jan 5 2019”)
▪ Season Name (e.g. “High Season”)
▪ Adult Price (e.g. “4,885”)
▪ Single Supplement (e.g. “1,221”)
▪ Child Price (e.g. “4,885”)
▪ Deposit (e.g. “500”)
o Note that the year is included in the season definition, as this allows the admin to
specify different pricing for different years. For example, bookings could be already in
progress for the current year’s summer as well as the next year’s summer, but with
different pricing.
o Admin can perform the following actions on a Pricing Season:
▪ Edit the season details
▪ Delete the season
▪ Add a new season
o Note that the season names and prices can be repeated. For instance, there could
be two High Seasons every year.
o The following scenarios will result in an error if the Admin tries to save the page:
▪ A date belongs to more than one season. Error message will say “Date
ranges are not correct. Some dates around Jan 12 2018 fall in more than one
season.”
▪ There are gaps in the seasons. If the Admin enters a new pricing season
covering December of next year, all days between now and that month must
also belong to a pricing season. Error message will say: “Date ranges are not
correct. Please ensure there are no gaps between your defined seasons.”

• General Tour Settings:

o This page will allow the Admin to manage the following settings:
 ▪ Show Sold Out Tours: checkbox, checked by default. If checked, tours that
have zero availability are displayed on the Tours Page as “SOLD OUT”. If
unchecked they are displayed as “Call for Availability”.
▪ Back Office Notification List: comma-separated list of emails to which
notifications will be sent (e.g., On Hold bookings expiring)
▪ Customer Service Phone Number: the number shown in the top banner
▪ Customer Service Email Address: the email shown in the top banner

Notifications

• The following events will trigger an email.

• Emails to the back office are sent via the distribution list configured in the “Back Office
Notification List” setting:
o Online Inquiry Received – entered details are sent to the user (traveler or agent) plus the
back office.
o Phone Callback Requested – clicked “Inquire By Phone” and entered a call back number
o Any response received in a conversation in the Messages section.
• Template text will be provided for each of these emails

Other Static Pages

• The following pages will also be available on the website. Each of these pages will display
static content that the site admins will be able to edit through the CMS provided by the
hosting provider.
• Static pages available via links in the header of the website:
o FAQ
• Static pages available via links in the footer of the website:
o FAQ
o Terms and Conditions
• Static pages available via links on the Payment tab and the FAQ page:
o Baggage Policy
o Fare Conditions
o e-VISA conditions
o Conditions of Carriage
o Children Conditions
o Purchase Conditions
• Dummy placeholder text can be entered for all these pages, and the admins will edit later
through the CMS
• The FAQ page will show the questions, and when a question is clicked that section expands
to display the answer. The sample page will use a few dummy placeholder
questions/answers.