WO2018044226A1

WO2018044226A1 - Booking system

Info

Publication number: WO2018044226A1
Application number: PCT/SG2016/000014
Authority: WO
Inventors: Soo Jin Chua
Original assignee: Soo Jin Chua
Priority date: 2016-08-31
Filing date: 2016-08-31
Publication date: 2018-03-08
Also published as: TW201826173A

Abstract

An activity booking system including at least one processing device that receives a booking enquiry from a user client device via a communications network, determines an availability of one or more activity time slots using an activity schedule, provides a booking availability indication to the client device, the booking availability indication being indicative of at least one available time slot, the client device being responsive to the booking availability indication to display an indication of the at least one available time slot determine user selection of at least one available time slot in accordance with user input commands and generate a booking request indicative of a selected available time slot, the processing device receiving the booking request from the user client device and selectively modifying the activity schedule in accordance with the booking request to thereby book the time slot for the user.

Description

BOOKING SYSTEM

Background of the Invention

[0001] The present invention relates to a booking system and method and in one particular example to a booking system and method for booking skydives in an indoor skydiving venue. Description of the Prior Art

[0002] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

[0003] Indoor skydiving is performed in a venue having a flight chamber including a vertical wind tunnel which acts to simulate a skydiving experience. Typically such venues operate by having a number of individuals booked to use the wind tunnel in a given time slot, with each individual purchasing packages of skydives for use during the time slot, with each individual dive typically lasting for approximately 45 to 90 seconds.

[0004] As the number of individuals that are able to use the flight chamber at any one time is limited, it is important that bookings are made in order to ensure the flight chamber will be available for use. As use of the flight chamber also typically requires the presence of an instructor, it is important to ensure that when a booking is made, an appropriately skilled instructor is available. Currently bookings are typically made by having a user contact a venue, confirm both availability of flight chamber and that appropriate instructors will be present, before a booking is made. At this time, the customer can buy a number of skydives, with these being credited into the customer account for their own usage and booking.

[0005] However, this approach suffers from a number of drawbacks. [0006] Firstly, it is typical for groups of users to want to book concurrently, either for social purposes, or to allow members of a group to fly together at the same time. As part of this users may wish to share their numbers of skydives purchased which they will contribute towards the shared session to fly together. Currently, they have to coordinate among themselves to book the timeslots individually via their own respective accounts. Sometimes, even though they have coordinated among themselves over the phone or emails, by the time they book, there may be no more slots to book for them to fly together in that particular session. For example, four members may want to fly together between 4pm to 4:30pm and agree to put in two skydives each. Two members book successfully first, however, when the other members attempt to book, the timeslot between 4pm to 4:30pm is now full and they cannot book, meaning they cannot fly together as intended.

[0007] In addition to the issue above, a further problem for users wanting a group booking is that they have to contact each other first via email or phone call. Most of the time, the members of the indoor skydiving venue will not know all the members as there can be hundreds of individuals involved. Thus, it can be hard to organize an event and will take a long time to do so through phone and email communications. Even if the organizer manages to get every member to agree, they still have to coordinate the booking, which may result in issues similar to those outlined above. [0008] A further problem for group flying activities is the different level of expertise of different members of the group. For example, it is hard for the organizer to know what skill level the members have, whilst it is important for venue operators to know what skill level the members have before they are allowed to fly together for safety reasons. Currently, time is wasted checking on the skill level of different members before they can fly together. [0009] A related problem is that instructors have different levels of ratings to suit different customers' training needs and requirements. Currently, instructor scheduling is done manually using a spreadsheet. The rating level of the instructor is not shown on the spreadsheet as there will be too much information for a monthly calendar schedule. Due to the manual planning, customer will have to call in to check on the instructor's schedule before they can book their skydive. The customer service staff will have to check the instructor's rating and his schedule before replying and booking for the customer.

[0010] A further problem with existing booking systems is that indoor skydiving package bookings are limited to fixed price packages and venue operators cannot easily change the package pricing to react to the usage rate of the business. For example, business owners can't change their pricing last minute to either gain more yield by increasing its pricing due to high usage or to lower the price due to low usage. This is especially so when customer books the package online where no staff can make the decision to lower or increase the price according to usage rate.

Summary of the Present Invention

[0011] In one broad form the present invention seeks to provide an activity booking system including at least one processing device that:

a) receives a booking enquiry from a user client device via a communications network;

b) determines an availability of one or more activity time slots using an activity schedule;

c) provides a booking availability indication to the client device, the booking availability indication being indicative of at least one available time slot, the client device being responsive to the booking availability indication to:

i) display an indication of the at least one available time slot;

ii) determine user selection of at least one available time slot in accordance with user input commands; and,

iii) generate a booking request indicative of a selected available time slot; d) receives the booking request from the user client device; and,

e) selectively modifies the activity schedule in accordance with the booking request to thereby book the time slot for the user.

[0012] Typically the user is a customer and the booking system is for booking user participation in the activity.

[0013] Typically the booking availability indication is indicative of:

a) available time slots; and

b) instructors assigned to each available time slot, thereby allowing the user to select a time slot at least in part in accordance with the respective instructor assigned to that time slot.

[0014] Typically the at least one processing device:

a) receives booking parameters;

b) determines pricing parameters; and,

c) determines a booking cost in accordance with the booking parameters and the pricing parameters.

[0015] Typically the at least one processing device:

a) provides a booking cost indication to the user client device, the user client device being responsive to the booking cost indication to:

i) display an indication of the booking cost;

ii) determine user acceptance of the booking cost in accordance with user input commands; and,

iii) generate a booking acceptance in response to user acceptance;

b) receives the booking acceptance; and,

c) modifies the activity schedule in accordance with the booking acceptance.

[0016] Typically the user client device:

a) determines booking parameters in accordance with user input commands; and, b) generates at least one of the booking request and booking enquiry in accordance with the booking parameters.

[0017] Typically the booking parameters define at least one of:

a) a number of packages requested;

b) a number of users;

c) a level of skill of users;

d) a booking date;

e) a booking time; and,

f) a booking duration.

[0018] Typically the pricing parameters define a respective price for each time slot and for each of a number of different booking parameters.

[0019] Typically the at least one processing device causes an account of the user to be charged in accordance with the booking request.

[0020] Typically the at least one electronic processing device:

a) receives a group booking request indicative of a group booking, the group booking request including an indication of other users to be included in the booking; b) provides an invitation to the user client device of each other user, the user client device being responsive to the invitation to:

i) display an indication of the invitation;

ii) determine user acceptance of the invitation in accordance with user input commands; and,

iii) generate an invitation acceptance in response to user acceptance; c) receives the invitation acceptance; and,

d) selectively modifies the activity schedule in accordance with the invitation acceptances to thereby complete a group booking.

Typically the at least one electronic processing device:

a) provisionally books the group booking in accordance with the group booking request, the provisional booking being valid for a defined time period;

b) provides the invitations; and,

c) completes the booldng if the invitation acceptances are received in the defined time period. [0022] Typically the group booking request is indicative of group booking parameters and wherein the at least one electronic processing device books the group booking in accordance with the group booking parameters.

[0023] Typically at least one processing device:

a) retrieves instructor data indicative of an instructor profile for each instructor; and,

b) generates the booking availability indication in accordance with instructor data for each of the available instructors.

[0024] Typically the instructor profile is indicative of at least one of:

a) an instructor identity; and

b) an instructor rating.

[0025] Typically the user is an instructor and the booking system is for booking instructor working hours.

[0026] Typically the booking enquiry is an instructor booking enquiry and the booking request is an instructor booking request indicative of a time slot the instructor wishes to work. [0027] Typically the at least one processing device:

a) generates a provisional instructor schedule;

b) provides provisional instructor schedule indication to a manager client device, the manager client device being responsive to the provisional schedule to:

i) display an indication of the provisional schedule;

ii) determine modification of the provisional schedule in accordance with manager input commands; and,

iii) generate a schedule approval in accordance with any modifications; c) receives the schedule approval; and,

d) stores the instructor schedule based on the schedule approval.

[0028] In one broad form the present invention seeks to provide an activity booking method including, using at least one processing device, to:

a) receive a booking enquiry from a user client device via a communications network;

b) determine an availability of one or more activity time slots using an activity schedule;

c) provide a booking availability indication to the client device, the booking availability indication being indicative of at least one available time slot, the client device being responsive to the booking availability indication to:

i) display an indication of the at least one available time slot;

iii) generate a booking request indicative of a selected available time slot; d) receive the booking request from the user client device; and,

e) selectively modify the activity schedule in accordance with the booking request to thereby book the time slot for the user.

[0029] It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting. Brief Description of the Drawings

[0030] An example of the present invention will now be described with reference to the accompanying drawings, in which: -

[0031] Figure 1 is a flow chart of an example of an activity booking method;

[0032] Figure 2 is a schematic diagram of a distributed computer architecture;

[0033] Figure 3 is a schematic diagram of an example of a processing system of Figure 2;

[0034] Figure 4 is a schematic diagram of an example of a client device of Figure 2;

[0035] Figures 5A and 5B are a flow chart of a specific example of an instructor booking method; and,

[0036] Figures 6A to 6D are a flow chart of a specific example of a customer booking process. Detailed Description of the Preferred Embodiments

[0037] An example of a method for booking an activity will now be described with reference to Figure 1.

[0038] For the purpose of this example, it is assumed that the booking is for an indoor skydiving venue. However, it will be appreciated that the techniques could be applied to other venues and/or activities, particularly those suffering from the difficulties outlined above, in terms of their ability to successfully coordinate bookings by users. As will become apparent from the following description, the term user is intended to refer to any individual participating in the activity, and could include either a customer, or an instructor. Thus, the booking system can be used by customers to book time slots allowing them to participate in skydiving, or for instructors to use the system to book the time slots at which they wish to work.

[0039] For the purpose of illustration, it is assumed that the process is performed at least in part using one or more electronic processing devices forming part of one or more processing systems, such as computer systems or servers, which are in turn connected to one or more client devices, such as mobile phones, portable computers or the like, via a network architecture, as will be described in more detail below.

[0040] In this example, at step 100 the electronic processing device receives a booking enquiry from a user client device via a communications network. The booking enquiry can be of any appropriate form and could involve submitting a request via a webpage, transferring a message such as an email message, or the like. The booking enquiry can include information regarding user requirements to assist with the booking process, including specifying booking parameters, such as an outline of times of interest to the user, restrictions on the booking, such as a number of spaces needed, or the like, as will be described in more detail below. [0041] At step 110 the electronic processing device uses an activity schedule to determine an availability of one or more activity type slots. Thus, an activity schedule will be maintained which lists details of all time slots for the venue, and an indication of a booking status of the time slot, such as whether the time slot is booked, and if so who has made the booking. This can be used by the processing device to identify available time slots that meet any requirements for the user.

[0042] At step 120 the electronic processing device provides a booking availability indication to the client device typically via the communications network, allowing the client device to display an indication of available time slots at step 130. The booking availability can be of any appropriate form and in one example includes a list of available time slots, displayed for example via a suitable webpage, as part of a calendar, or the like.

[0043] At step 140 the client device determines user selection of at least one of the available time slots, for example through user input commands interacting with a user interface or similar. The client device generates a booking request at step 150, with the booking request being indicative of the selected time slot and any other booking parameters that were not previously specified, which is then provided to the processing device. The processing device then selectively modifies the activity schedule in accordance with the booking request, to thereby book the time slot for the user.

[0044] Accordingly, the above described process provides a mechanism to allow users to determine available time slots and subsequently book one of those time slots. The user can be in the form of a customer wishing to purchase participation in the activity and/or could include an instructor that is choosing the time slots for the activity during which to assist the customer in completing the activity. Additionally, by allowing the user to specify booking parameters, this can be used to create group bookings, provide for dynamic pricing or the like, as will be described in more detail below. [0045] In one example, when the user is a customer, the booking availability indication is indicative of available time slots and instructors assigned to each available time slot, thereby allowing the user to select a time slot having an instructor they wish to use. In particular, this can allow users to select time slots which are not only available, but for which there is an appropriate experienced instructor allowing them to get the most benefit out of the particular activity being performed.

[0046] In one example, the processing device receives booking parameters, for example as part of the booking enquiry or booking request. The booking parameters can include any information regarding the booking, such as a number of individual packages requested, the number of users forming part of a group booking, a level of experience or skill of the user, a booking date, a booking time, a booking duration, or the like. Thus, in the context of skydiving, this could include specifying a number of skydives to be performed by the user within the requested time slot, the number of users to be involved, the identity of the users, the respective level of skill or experience of the users, or the like. The booking parameters are typically provided by the user client device, by having the user client device determine booking parameters in accordance with user input commands and then generate either the booking request or booking enquiry in accordance with the booking parameters, allowing the processing device to determine the booking parameters using the booking request or booking enquiry. [0047] The processing device can then determine pricing parameters, which define the price of a respective time slot for each of a number of different booking parameters, and optionally depending on other criteria, such as a current capacity, predicted booking levels or the like. The pricing parameters can be stored in and retrieved from a database, and may be adjusted as required, depending on the preferred implementation. The processing device then determines a booking cost in accordance with the booking parameters and the pricing parameters.

[0048] The process of determining pricing parameters and basing the booking cost on both the pricing and booking parameters allows the pricing to be performed dynamically so that pricing can be readily and easily adjusted depending on current requirements of the business. For example, pricing parameters may define that a price varies depending on the number of packages requested, or users involved, so that the price per package is adjusted if the user requests more packages, or if more users are to be present. Additionally, the pricing parameters can be adjusted based on a range of factors such as a time of day, day of the week, current levels of booking, or the like, to take into account relative popularity of the booked time slot. It will be appreciated from this that prices may decrease shortly before a time slot is due to encourage empty time slots to be utilised. This can be provide load balancing ensuring that the venue operator has a relatively constant level of customers whilst maximising pricing when possible.

[0049] Typically, in this example when dynamic costing is performed, the processing device provides a booking cost indication to the user client device once the booking parameters have been determined, with the user client device being responsive to the booking cost indication to display an indication of the booking cost, determine user acceptance of the booldng cost in accordance with user input commands and generate a booking acceptance in response to user acceptance. The booking acceptance is provided to the processing device which modifies the activity schedule in accordance with the booking acceptance, thereby reflecting that the booking is accepted. It will be appreciated that this could be performed in conjunction with other parts of the process, for example by having the booking cost provided as part of the booking availability indication and have the booking request act as the booking acceptance. Alternatively these could be performed as separate steps, depending on the preferred implementation. [0050] In one example, the processing device can cause an account of the user to be charged in accordance with the booking request. Thus, users can be pre-charged prior to attending the event, to thereby make the process of performing the activity smoother and avoiding the need to take the payment during the process.

[0051] In one example, the booking system can also be utilised in order to perform group bookings. Group bookings are particularly problematic as it requires an individual to coordinate a number of different users with available time slots. Accordingly, it has traditionally been necessary for the user making the booldng to contact each of the attendees and ensure they are available in line with a given available time slot. However, the time taken to perform this task can result in the desired time slot being booked by other parties. [0052] In order to accommodate group bookings, the processing device receives a group booking request indicative of a group booking. The group booking request includes an indication of other users to be included in the booking, typically including the number and details of the other users. The group booking request can be generated by having the user select an appropriate input option when selecting an available time slot, for example by selecting that the time slot is to be used for a group booking. [0053] Following this, the processing device provides an invitation to a user client device of each of the users included in the group booking, with each user's client device displaying an indication of the invitation and allowing the user acceptance of the invitation to be performed using user input commands, for example by selecting a link or other response option in the invitation. Following the user acceptance, an invitation acceptance is generated and transferred to the processing device allowing this to modify the activity schedule in accordance with the invitation acceptances to thereby complete a group booking.

[0054] Accordingly, in this example, the processing device typically provisionally books the group booking in accordance with the group booking request with the provisional booking being valid for a defined time period. The electronic processing device then provides the invitations and completes the booking if the invitation acceptances are received in the defined time period. The group booking request is typically indicative of group booking parameters with the processing device booking the group booking in accordance with the group booking parameters. It will be appreciated this allows dynamic pricing to be applied, for example reducing the cost if more than a certain number of individuals sign up for the group booking. [0055] The booking system can also be used to book instructor working hours. In this example, the booking enquiry is an instructor booking enquiry from an instructor client device, with the processing device providing a booking availability indication indicative of at least one available time slot for the instructor. The instructor client device determines instructor selection of the available time slot and provides a booking request in the form of an instructor booking request indicative of the selected available time slot. The instructor booking request is then provided to the processing device allowing the processing device to book the selected time slot for the instructor.

[0056] As part of this process, a manager would be typically required to have oversight of the bookings. Accordingly, the processing device can generate a provisional instructor schedule, forward the provisional instructor schedule to a manager client device allowing the manager client device to display an indication of the provisional schedule, determine modification of the schedule in accordance with manager input commands and then generate a schedule approval in accordance with any modifications. The schedule approval can be provided to the processing device which can store an instructor schedule based on the scheduled approval. This allows the manager to review, approve or amend the schedule before it is finalised. [0057] As mentioned above, in one example, the process is performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.

[0058] In this example, a number of processing systems 210 are coupled via communications networks 220, such as the Internet, and/or a number of local area networks (LANs), to a number of client devices 230. It will be appreciated that the configuration of the networks 220 are for the purpose of example only, and in practice the processing system 210 and client devices 230 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to- point connections, such as Bluetooth, or the like.

[0059] In one example, each processing system 210 includes one or more processing systems 210, each of which may be coupled to one or more databases 211. The processing system 210 is adapted to be used in managing the booking process and interacting with users via client devices. The client devices 230 are typically adapted to communicate with the processing system 210, allowing available time slots to be determined and booked.

[0060] Whilst the processing system 210 is a shown as a single entity, it will be appreciated that the processing system 210 can be distributed over a number of geographically separate locations, for example by using processing systems 210 and/or databases 211 that are provided as part of a cloud based environment. However, the above described arrangement is not essential and other suitable configurations could be used.

[0061] An example of a suitable processing system 210 is shown in Figure 3. In this example, the processing system 210 includes at least one microprocessor 300, a memory 301, an optional input/output device 302, such as a keyboard and/or display, and an external interface 303, interconnected via a bus 304 as shown. In this example the external interface 303 can be utilised for connecting the processing system 210 to peripheral devices, such as the communications networks 220, databases 211, other storage devices, or the like. Although a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

[0062] In use, the microprocessor 300 executes instructions in the form of applications software stored in the memory 301 to allow the required processes to be performed. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

[0063] Accordingly, it will be appreciated that the processing system 210 may be formed from any suitable processing system, such as a suitably programmed client device, PC, web server, network server, or the like. In one particular example, the processing system 210 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.

[0064] As shown in Figure 4, in one example, the client device 230 includes at least one microprocessor 400, a memory 401, an input/output device 402, such as a keyboard and/or display, and an external interface 403, interconnected via a bus 404 as shown. In this example the external interface 403 can be utilised for connecting the client device 230 to peripheral devices, such as the communications networks 220, databases, other storage devices, or the like. Although a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

[0065] In use, the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow communication with the processing system 210, for example to allow for selection of parameter values and viewing of representations, or the like. [0066] Accordingly, it will be appreciated that the client devices 230 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, or hand-held PC, and in one preferred example is either a tablet, or smart phone, or the like. Thus, in one example, the processing system 210 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the client devices 230 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.

[0067] Examples of the booking processes will now be described in further detail. For the purpose of these examples it is assumed that one or more processing systems 210 acts to display webpages, which are displayed via a browser application or other suitable application residing on the client device 230. The processing system 210 is therefore typically a server, and will hereinafter be referred to as server 210, which communicates with the client device 230 via a communications network, or the like, depending on the particular network infrastructure available.

[0068] To achieve this the server 210 typically executes applications software for hosting webpages, as well as performing other required tasks including storing, searching and processing of data, with actions performed by the server 210 being performed by the processor 300 in accordance with instructions stored as applications software in the memory 301 and/or input commands received from a user via the I/O device 302, or commands received from the client device 230.

[0069] It will also be assumed that the user interacts with the server 210 via a GUI (Graphical User Interface), or the like presented on the client device 230, and in one particular example via a browser application that displays webpages hosted by the server 210, or an application that displays data supplied by the server 210. Actions performed by the client device 230 are performed by the microprocessor 400 in accordance with instructions stored as applications software in the memory 401 and/or input commands received from a user via the I/O device 402. [0070] However, it will be appreciated that the above described configuration assumed for the purpose of the following examples is not essential, and numerous other configurations may be used. It will also be appreciated that the partitioning of functionality between the client devices 230, and the server 210 may vary, depending on the particular implementation. [0071] The following examples describe how the system can be used both by the instructors for their scheduling and by the customer to making a booking for a specific time and instructor. Examples will be described separately for the purpose of ease of illustration, but it will be appreciated that in practice these procedures are ongoing and can be performed in parallel by the system. [0072] A specific example of the process for booking instructor working hours using the above described system will now be described with reference to Figures 5 A and 5B.

[0073] In this example, at step 500 the server 210 receives an instructor's booking enquiry from the instructor client device 230. This can be achieved in any suitable manner, but typically involves having the instructor client device access an appropriate webpage or the like. At step 505 the server 210 retrieves an activity schedule and provides an indication of the schedule availability at step 510, allowing these to be displayed by the instructor client device at step 515. In this regard, the activity schedule will specify activity time slots during which activities can be performed, as well as instructors already assigned to respective time slots and a number of instructors required for each time slot. The time slots can be displayed as a list or calendar, depending on the preferred implementation.

[0074] The user can then select time slots of interest at step 520, with this being used by the instructor client device 230 to transfer a booking request to the server 210 at step 525. This process can be repeated for each of a number of instructors, allowing the server 210 to generate a provisional instructor schedule for multiple instructors at step 530. [0075] The provisional schedule is provided to a manager client device 230 at step 535, for example either by forwarding the schedule or by having a manager access a provisional schedule via an appropriate webpage. At step 540, the provisional schedule is displayed on the manager client device 230 allowing the manager to either accept or modify the schedule at step 545. Any modifications are provided to the server at step 550 allowing the schedule to be updated at step 555 as required. Instructors can then be alerted to the fact that the schedule is finalised, allowing them to view the final schedule and confirm their working hours.

[0076] Accordingly, it will be appreciated that this allows time slots to be booked for instructors, to thereby ensure adequate coverage of instructors at all times, whilst allowing instructors to nominate their preferred working hours. Additionally, once booked, the information regarding the instructors can be used by customers when booking activities.

[0077] An example of the process for performing a group booking using the above described system, and hence the same system and processes as used for scheduling working hours as described above, will now be described in more detail with reference to Figures 6 A to 6D. [0078] In this example, a schedule enquiry is received from a user client device 230 at step 600, for example by having the user client device 230 access a suitable webpage hosted by the server 210. The server 210 retrieves an activity schedule at step 602 and provides a booking availability indication to the user client device 230 at step 604, allowing the client device to display available time slots at step 606. Again, this can involve displaying a list of available time slots, or displaying time slots in a calendar format together with an indication of availability. This will also include information regarding the instructors assigned to the time slots, allowing the user to select a time slot with an appropriate instructor.

[0079] A user selects a time slot at step 608, with the user then being prompted to provide details of booking parameters. In particular, the booking parameters can include information regarding the number of users that are to attend as part of the group booking, the number of packages required by each user. Other information may also be required, such as user contact details for each of the users, information regarding experience or the like, although more typically this is retrieved from pre-existing user data as will be described in more detail below. This process is typically achieved by displaying a webpage including suitable fields, guiding the user regarding the information required.

[0080] The booking parameters are provided as part of a booking request to the server 230 at step 612 causing the server 230 to retrieve pricing parameters are step 614. The pricing parameters define the cost of the booking of any particular time slot and will be calculated dynamically based on factors such as the current venue capacity. Thus, the server 230 can use the booking and pricing parameters to determine a booking cost at step 616 with an indication of the booking cost being provided to the user client device 230 at step 618. The booking cost is displayed to the user at step 620 via the user client device 230, allowing the user to accept the booking cost at step 622.

[0081] If it is determined the booking is a group booking at step 624, then at step 626 the server 210 provisionally books the time slot and then generates invitations, which are sent to client devices associated with each of the users identified in the group booking at step 628. In this regard, each invited user will typically already be a member of the venue, and hence have associated user data indicative of the user name, contact details, level of expertise and other appropriate information. The group booking can simply identify the users, with the server 210 then sending invitations to the user in any manner, such as by sending an email, SMS or the like, depending on the form of contact details provided in the respective user data. The invitations are displayed on each user client device at step 630, allowing invitees to respond at step 632, for example by selecting embedded links corresponding to acceptance or rejection of the invitation. [0082] At step 634, server 210 determines if a response has been received and if not determines if a time period has expired. If not, the process returns to step 632 awaiting responses to be provided. Otherwise, if the time limit has expired and responses have not been received, or if the responses are rejections, the booking can be cancelled at step 638. Otherwise once sufficient users have accepted, or if it is not a group booking the booking can be confirmed at step 642. As part of this process, the booking may be reviewed manually, or compared to predetermined booking criteria to ensure the booking is safe, for example to ensure the users are of a similar level of experience. Assuming this to be the case, the server 210 can update the activity schedule with details of the booking, and sending a booking confirmation to the one or more user client devices 230 at step 644. [0083] User accounts may optionally be debited at step 646, either based on the acceptance and/or completion of the activity. Thus, user accounts can be debited based on the indicated numbers of skydives that are to be performed in accordance with the booking request, with additional dives being charged at the time of the activity as required.

[0084] Throughout the above described process the activity schedule is used to maintain a record of which instructors and which users are associated with which time slot. It will be appreciated however that in practice separate activity and instructor schedules can be maintained with these being correlated as required. Additionally, it will be appreciated that processes for the instructor's booking of working hours and customer's booking of activity can be performed in any order depending on the preferred implementation. For example, instructors could book their time slots only after customers have booked a time slot, to make sure the instructor is appropriate for the customers' requirements.

[0085] In any event it will be appreciated that the above described system provides a booking arrangement that can allow booking by instructors and customers, as well as to allow dynamic pricing to be implemented. The ability to book instructor working times and customers via a single common booking system is particularly important in ensuring that customers' needs are met in terms of adequate supervision and training, which is in turn important for the customer experience and safety.

[0086] Accordingly, in one example, the above described system provides an online system that allows members to set up an event with parameters such as timeslots, how many skydive required by members etc, and thereafter able to invite other members in the system for this event. Once the other members receive and accept the invitation, the skydive requirement determined based on the parameters set by the organizer will be automatically populated into the activity schedule for the other members.

[0087] The system also allows members to set up groups by inviting other members into the group. Once the other members have received and accepted the invitation, the required number of skydives based on the parameters set by the organizer will be automatically deposited into a group account. From there, the group can use this account to book sessions when they want to fly together. For those who have flown, they will have credit deducted within the group account.

[0088] For example, if Flyers A, B, C, D, E and F join the group and automatically deposit 10 skydives into the account each from their individual account, the group account will have 60 skydives. Flyer A sends an invite to all the rest of members to fly on a certain date with each contributing 2 skydive from the group account but only Flyer A, B, C and D accepts and flies. Thus, the final group skydive balance will be: 60 skydives minus 2 skydives x 4 flyers = 52 skydive. Within the group, Flyer A, B, C and D will only have 8 skydives left while Flyer E and F have 10 skydives left. With such an input parameter as a number of skydives to be inputted into the group/event account, everyone will be contributing equally whenever they fly. There is no need to check who is contributing or who is not. If the members are flying by themselves, they can book through their own individual accounts.

[0089] The system also allows members to view the skills level of different members before grouping and manifesting them into the flight session. Instructors can view this grouping and skill level through system before the session to confirm the grouping is safe.

[0090] Additionally, the system can apply dynamic pricing to optimise utilisation of the facility. For example, the system can track selling of packages and account for the remaining capacity of the venue, adjusting the pricing dynamically in order to ensure maximum utilisation. For example, if the capacity is at certain % in terms of skydive or % before x days of intended booking date, the price will change according to the parameter set. For example, before 50% booking capacity - $50, between 50% to 80% capacity - $80, and 80% above capacity - $100.

[0091] This arrangement gives venue operators flexibility and allows them to increase yield in real time without the need to manually track or operate the system. The customer will be informed automatically via the system. With such system, it will encourage more sales instead of a flat rate package pricing which give no push to the customer to buy certain timings.

[0092] Furthermore, the system can also allow instructor bookings to be managed. In this case, instructor information, such as name and rating level, are inputted. The scheduling system will be linked to the booking system where customer will be able to see from the booking system which instructor of certain rating is available for his training requirement. The customer can also input his training requirement for the system to recommend which instructor and which timeslot for him to book.

[0093] It will give users such as the customers ease of use of the booking system without the hassle of calling the customer service. In addition, the customer service need not search through spreadsheets and instructor profile to reply and book for the customer. The customer service can just log into the system to check the training requirement, timeslots, and the instructor's rating. Time and effort are saved.

[0094] Throughout this specification and claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

[0095] Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1) An activity booking system including at least one processing device that:

i) display an indication of the at least one available time slot;

2) An activity booking system according to claim 1, wherein the user is a customer and the booking system is for booking user participation in the activity.

3) An activity booking system according to claim 2, wherein the booking availability indication is indicative of:

a) available time slots; and

4) An activity booking system according to claim 2 or claim 3, wherein the at least one processing device:

a) receives booking parameters;

b) determines pricing parameters; and,

c) determines a booking cost in accordance with the booking parameters and the pricing parameters. 5) An activity booking system according to claim 4, wherein the at least one processing device:

i) display an indication of the booking cost;

iii) generate a booking acceptance in response to user acceptance;

b) receives the booking acceptance; and,

c) modifies the activity schedule in accordance with the booking acceptance.

6) An activity booking system according to claim 4 or claim 5, wherein the user client device:

7) An activity booking system according to any one of the claims 4 to 6, wherein the booking parameters define at least one of:

a) a number of packages requested;

b) a number of users;

c) a level of skill of users;

d) a booking date;

e) a booking time; and,

f) a booking duration.

8) An activity booking system according to any one of the claims 4 to 7, wherein the pricing parameters define a respective price for each time slot and for each of a number of different booking parameters.

9) An activity booking system according to any one of the claims 2 to 8, wherein the at least one processing device causes an account of the user to be charged in accordance with the booking request. 10) An activity booking system according to any one of the claims 2 to 9, wherein the at least one electronic processing device:

i) display an indication of the invitation;

11) An activity booking system according to claim 10, wherein the at least one electronic processing device:

b) provides the invitations; and,

c) completes the booking if the invitation acceptances are received in the defined time period.

12) An activity booking system according to claim 10 or claim 11, wherein the group booking request is indicative of group booking parameters and wherein the at least one electronic processing device books the group booking in accordance with the group booking parameters.

13) An activity booking system according to any one of the claims 2 to 12, wherein at least one processing device:

b) generates the booking availability indication in accordance with instructor data for each of the available instructors. 14) An activity booking system according to claim 13, wherein the instructor profile is indicative of at least one of:

a) an instructor identity; and

b) an instructor rating.

15) An activity booking system according to claim 1, wherein the user is an instructor and the booking system is for booking instructor working hours.

16) An activity booking system according to claim 15, wherein the booking enquiry is an instructor booking enquiry and the booking request is an instructor booking request indicative of a time slot the instructor wishes to work.

17) An activity booking system according to claim 16, wherein the at least one processing device:

a) generates a provisional instructor schedule;

i) display an indication of the provisional schedule;

d) stores the instructor schedule based on the schedule approval.

18) An activity booking method including, using at least one processing device, to: a) receive a booking enquiry from a user client device via a communications network;

i) display an indication of the at least one available time slot; ii) determine user selection of at least one available time slot in accordance with user input commands; and,