The Ticket Screen

The Ticket Screen comprises of three sections; the first for entering the client’s details and booking information; the second for entering the units being booked, and the third for recording payment.

Section 1

The top section of the ticket screen can appear quite daunting at first look, with many blank text-entry boxes. An important thing to be aware of is that you will not need to complete every field for the majority of bookings. Only a couple of fields - the ‘Time Scheduled’ and ‘Surname’ are required fields, with everything else provided as additional information fields to help the operator, the client, or the agent. 

The ticket header is always ‘{Agency Name} Ticket’ - in this example, the agency is ‘DemoAccom’:

For ‘On Call’ bookings, immediately below this is a banner reminding the agent that they need to call to make the reservation.  

Most of the next few fields are automatically completed by the system, including the Operator and Activity; the Date Scheduled and the Operator’s Contact numbers.

If you have selected a scheduled departure, the trip time will appear in the ‘Time Scheduled’ field, whereas if you are booking an ‘On Demand’ activity, this field will be blank and will need to be completed before you can save the booking.

This top section also includes any Directions that have been entered in to the system for the particular activity; to help the agent explain where the client will need to go.

Reschedule Booking

The ‘Reschedule Booking’ button next to the activity name allows the user to switch to a different departure, or even a different activity provided by the same operator, without having to exit the ticket and therefore lose any client information already entered.

This function assists the agent particularly when making an ‘On Call’ booking for a busy activity with several daily departures, such as skydiving or bungy jumping. Generally, the agent will ask the client of their preferred departure time, and fill in the ticket with all the relevant client information for this departure before calling the operator. If they then speak to the operator to make the booking and are told that the preferred departure is full; the agent can use this button to switch to an available departure, and retain all the client information on the ticket.

To demonstrate the function using the example of NZone Skydiving, the client has chosen to jump at 11.30am on April 17th, 2014. The agent selects the departure and fills in the ticket accordingly:

Unfortunately, when the agent gets on the phone, they are told that all the departures are fully booked until the next day. The client is happy to reschedule, and decides on the 12.30pm departure on the 18th instead.

The agent clicks ‘Reschedule Booking’, and chooses the new date and departure:

On return to the ticket screen, the time and date has changed, but the client information remains intact: 

Text Fields

The main text entry boxes start with the client’s given Name and Surname (required), and then a Contact Phone number for the client, which some operators will ask for. Even if the operator doesn’t directly request a contact number, it’s often a useful thing to note on the ticket, just in case you need to get hold of the client at a later time.

The Contact Email line is used in conjunction with a tick box beside it which generates an email of the ticket and sends it to the address specified. 

The Reference field is for used for ‘On Call’ bookings, and can be anything the operator provides as confirmation of the booking - usually a booking number, reservation code or a PNR. In the absence of any the above, the agent may opt to enter the name of the person they spoke to on the phone as verification that the booking was conveyed.

The reference field should be left blank when booking ‘live’ activities, as the reservation is sent directly to the operator as soon it is saved by the agent. If there ever was a dispute over a ‘live’ booking; the copy of the ticket that is automatically saved in the agent user’s TMO history would provide clear proof of the exact reservation that was made.

The Webuser Name is the name of the user agent; typically their family name.

The Room Number can be useful, much like the phone number, if the agent or operator needs to reach the client - for example if they fail to show up at their pre-arranged departure time.

The Booking ID is a system-generated alphanumeric reference code, which the agent should give to the operator when calling through ‘On Call’ bookings. Sometimes referred to as an ‘Agent reference’ or ‘Voucher number’, this unique identifier will often be the primary reference used by both the operators’ and agents’ accounting teams throughout the invoicing process. For ‘Live’ bookings, the Booking ID is automatically saved with the booking in the operator’s system.

Next to the Booking ID is a speech bubble icon. If you click on this, the Booking ID will be written out according to the phonetic alphabet, to make it easier to communicate the ID over the phone to the operator:

The Pickup Time will often differ from the ‘scheduled time’ of the activity, because an operator can only allocate one scheduled time for each of their set departures, but might offer various pickup times at different locations around town, or have a significant ‘check in’ period before the trip departs.

The last two fields are simply for entering any additional information that might be of use to either the client or operator (such as “Don’t forget swimming togs and a towel” or “Experience - Intermediate; Weight - 53kgs”).

Section 2 - Units

The second section of the booking form is for entering the units required for the reservation.

If the price in system is incorrect; the user can override it on the ticket to ensure they take the correct payment and are invoiced accordingly. When an agent overrides a price, the system requires that they enter a reason for the price change so that the system administrators can be made aware of the issue. 

If the unit type being booked is not listed, it can be created for that ticket by selecting the ‘Can’t find price’ link and entering the missing price description, along with the unit price and number of units required. The system will again require a reason for the new price:

For more info on the ‘Can’t find price?’ function, see Troubleshooting: Incorrect or Missing Prices.

Section 3 - Payments

The bottom section of the ticket is for recording payment information.

If multiple payments are made; the ‘Add Payment’ button creates additional entry lines, and the ‘Delete Payment’ button can be used to remove any payment lines not required.

By default, the system will assume that the payment is most likely to come in one payment, so the total booking value will be entered in the first payment line:

To instead record that the booking was paid half in cash and half by eftpos; enter the first Payment Method and the amount paid, then click the ‘Add Payment’ button:

When taking multiple payments; the line above the payments table will help the agent keep track of the amount paid and the outstanding balance.

NOTE: It is possible (although not recommended) to save a ticket with an outstanding balance, or without having taken any payment - but the system will warn the user with an ‘Are you sure? The booking has an amount remaining unpaid’ prompt. To save a booking without taking any payment, the agent will need to delete all payment lines, as the system will not allow a ticket to be saved if there are incomplete transaction lines showing. For more information, see Making a Booking without Taking Payment.

Once the full payment amount has been entered, the ‘Balance of Booking Value Unpaid’ will show as zero, and the ‘Book Now’ button can be clicked to finalise the details:

Terms and Conditions

Right at the bottom of the ticket screen are displayed the Operator's Terms and Conditions for the booking. These will either be terms and conditions specific to the particular activity, for the operator as a whole, or if neither of these have been recorded; standard RTBS terms and conditions.

The terms and conditions will also print onto the client’s ticket, with a signature line so that the agent can ask the client to sign their acceptance of the stated policies.

Printing tickets

It is recommended to print RTBS tickets onto A4 paper. The ticket format does not fit Thermal Roll printers; and smaller paper sizes may make the information hard to read.