WO2017185126A1

WO2017185126A1 - System and method for booking resources

Info

Publication number: WO2017185126A1
Application number: PCT/AU2017/050313
Authority: WO
Inventors: David Norman NEIL
Original assignee: Quicker Support Pty Ltd
Priority date: 2016-04-29
Filing date: 2017-04-10
Publication date: 2017-11-02

Abstract

Disclosed herein are a booking system and method for booking resources, such as labour hire personnel. The system comprises a server that includes a database, a memory, and a processor. The database stores information relating to a set of registered staff members, wherein each staff member has an associated staff profile, each staff profile including staff skills, staff location, and staff availability. The memory stores computer code instructions that when executed on the processor perform the method steps of: receiving a booking request from a client, said booking request including booking information, wherein said booking information includes a booking location, booking time, number of staff, and required skill level; identifying a first set of prospective staff members from said registered staff members, based on said booking information and a predefined set of criteria, said predefined set of criteria including staff skill, staff availability, and staff location; transmitting a shift message to said first set of prospective staff members, wherein said shift message is based on said booking information; receiving an acceptance message from at least one of said first set of prospective staff members; and recording the staff members associated with the acceptance messages in said booking information.

Description

SYSTEM AND METHOD FOR BOOKI NG RESOURCES

Related Application

[0001 ] The present application is related to Australian Provisional Patent Application No. 2016901583 titled "System and method for booking resources" and filed on 29 April 2016 in the name of David Neil, the entire content of which is incorporated by reference as if fully set forth herein.

Technical Field

[0002] The present disclosure relates to a system and method for booking resources. I n particular, the present disclosure relates to a system and method for connecting customers to resources, such as labour hire personnel.

Background

[0003] I t is often necessary for a customer or client to hire resources for a project. Such projects take many forms and may include, for example, conferences, product launches and promotions, parties, seminars, and other such events. The resources may include physical objects and infrastructure, such as booths, advertising screens, marketing props, and the like. The resources may also include staff, collectively referred to in this application as labour hire personnel.

[0004] I n addition to hiring labour hire personnel for a project, such as those described above, it is common for customers to hire additional labour hire personnel to address temporary staffing shortages due to staff absences, an increase in workload, or short-term projects. Further, some businesses factor labour hire into their day-to-day operations, wherein a core skeleton staff is supplemented by bulk labour when implementing their operations. Labour hire personnel span all industries, including, but not limited to, entertainment, construction, mining, retail, health, education, information technology (I T) , manufacturing, finance, agriculture, tourism , media, transport, legal, and logistics.

[0005] Customers requiring the services of casual personnel typically either advertise the available position or engage the services of a recruitment agent. I n each case, the customer provides a brief description of the role, the start and end times for the contract, and a list of requisite skills. I t is then up to the customer or the recruitment agent to interview potential candidates in order to engage the required staff. Advertising for casual personnel in this way is typically a lengthy process and is often not suitable for identifying and engaging suitable casual personnel for short term projects or at short notice.

[0006] Alternatively, the customer approaches a Labour Hire Company (LHC) , which typically has a set of registered personnel on their books. However, the customer may not know or be easily able to identify which LHC best services a particular area or skillset. I t is typically necessary for the customer to register with each LHC, which can be a lengthy process involving many forms. Further, most LHCs are open only during standard business hours. Further still, a particular LHC with which a customer is registered may not be able to meet the customer's demands, in relation to number of staff and/or skillset, especially in peak periods. This can cause frustration, delays, and additional costs for the customer in having to source additional labour hire personnel from other sources.

[0007] Thus, a need exists to provide an improved system and method that enable a customer to book resources, such as labour hire personnel, for a project.

Summary

[0008] The present disclosure relates to a system and method for booking resources.

[0009] A first aspect of the present disclosure provides a booking system comprising: a server including :

a database storing information relating to a set of registered staff members, wherein each staff member has an associated staff profile, each staff profile including staff skills, staff location, and staff availability;

a processor; and

a memory for storing computer code instructions that when executed on the processor perform the method steps of :

receiving a booking request from a client, said booking request including booking information, wherein said booking information includes a booking location, booking time, number of staff, and required skill level; identifying a first set of prospective staff members from said registered staff members, based on said booking information and a predefined set of criteria, said predefined set of criteria including staff skill, staff availability, and staff location; transm itting a request message to said first set of prospective staff members, wherein said request message is based on said booking information ;

receiving an acceptance message from at least one of said first set of prospective staff members; and

recording the staff members associated with the acceptance messages in said booking information.

[001 0] I n one arrangement , the acceptance messages are each generated in response to each of said at least one of said first set of prospective staff members clicking an Accept Job button on a display screen of a computing device.

[001 1 ] A second aspect of the present disclosure provides a method for booking personnel, comprising the steps of :

storing a staff profile associated with each of a plurality of staff members, wherein the staff profile includes staff skills, staff location, and staff availability for each respective staff member;

receiving a booking request from a customer, wherein the booking request includes booking information , said booking information including a booking location , booking time, number of staff , and required skill level;

identifying a first set of prospective staff members from said registered staff members, based on said booking information and a predefined set of criteria, said predefined set of criteria including staff skill, staff availability, and staff location ;

transm itting a request message to said first set of prospective staff members, wherein said request message is based on said booking information ;

receiving an acceptance message from at least one of said first set of prospective staff members;

recording the staff members associated with the acceptance messages in said booking information ; and

transm itting an acceptance notification to said customer.

[001 2] I n one arrangement , the acceptance messages are each generated in response to each of said at least one of said first set of prospective staff members clicking an Accept Job button on a display screen of a computing device.

[0013] According to another aspect , the present disclosure provides an apparatus for implementing any one of the aforementioned methods. [0014] According to another aspect, the present disclosure provides a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.

[0015] Other aspects of the present disclosure are also provided. Brief Description of the Drawings

[0016] One or more embodiments of the present disclosure will now be described by way of specific example(s) with reference to the accompanying drawings, in which:

[0017] Fig. 1 a is a schematic block diagram representation of a booking system in accordance with the present disclosure;

[0018] Fig. 1 b illustrates logical communication flows between the server and computing devices of the booking system of Fig. 1 a;

[0019] Fig. 1 c shows communication flows between each of the participants in the booking system of Fig. 1 a;

[0020] Fig. 2 is a schematic block diagram representation of logical communication flows in the database 164 of Fig. 1 a;

[0021 ] Fig. 3 is a schematic block diagram representation of a system that includes a general purpose computer on which one or more embodiments of the present disclosure may be practised;

[0022] Fig. 4 is a schematic block diagram representation of a system that includes a general smartphone on which one or more embodiments of the present disclosure may be practised ;

[0023] Fig. 5 is a screenshot of a home screen of a Cascading Request Until Verification Application (CRUVA app) ;

[0024] Fig. 6 is a screenshot of a jobs location screen of the CRUVA app; [0025] Fig. 7 is a screenshot of an alternative home screen of the CRUVA app; [0026] Fig. 8 is a screenshot of a select skills screen of the CRUVA app; [0027] Fig. 9 is a screenshot of an extra skills screen of the CRUVA app; [0028] Fig. 10 is a screenshot of a second extra skills screen of the CRUVA app; [0029] Fig. 1 1 is a screenshot of a further skills screen of the CRUVA app; [0030] Fig. 12 is a screenshot of a further skills screen of the CRUVA app;

[0031 ] Fig. 13 is a screenshot of a further skills screen of the CRUVA app;

[0032] Fig. 14 is a screenshot of a further skills screen of the CRUVA app;

[0033] Fig. 15 is a screenshot of a quote screen of the CRUVA app;

[0034] Fig. 16 is a screenshot of a confirmation screen of the CRUVA app;

[0035] Fig. 17 is a screenshot of an extra details screen of the CRUVA app;

[0036] Fig. 18 is a screenshot of an onsite contact screen of the CRUVA app;

[0037] Fig. 19 is a screenshot of a second onsite contact screen of the CRUVA app;

[0038] Fig. 20 is a screenshot of an extra details screen of the CRUVA app;

[0039] Fig. 21 is a screenshot of a meeting place screen of the CRUVA app;

[0040] Fig. 22 is a screenshot of a location positioning screen of the CRUVA app;

[0041 ] Fig. 23 is a screenshot of an extra details screen of the CRUVA app;

[0042] Fig. 24 is a screenshot of a view booking screen of the CRUVA app;

[0043] Fig. 25 is a screenshot of an inductions screen of the CRUVA app;

[0044] Fig. 26 is a screenshot of a qualifications screen of the CRUVA app;

[0045] Fig. 27 is a screenshot of a notes screen of the CRUVA app;

[0046] Fig. 28 is a screenshot of an open booking screen of the CRUVA app;

[0047] Fig. 29 is a screenshot of a second open booking screen of the CRUVA app;

[0048] Fig. 30 is a screenshot of a resend quote screen of the CRUVA app;

[0049] Fig. 31 is a screenshot of a view staff screen of the CRUVA app;

[0050] Fig. 32 is a screenshot of an edit rebooking screen of the CRUVA app;

[0051 ] Fig. 33 is a screenshot of a copy booking screen of the CRUVA app;

[0052] Fig. 34 is a screenshot of a settings screen of the CRUVA app;

[0053] Fig. 35 is a screenshot of a timesheet map screen of the CRUVA app;

[0054] Fig. 36 is a screenshot of a timesheet screen of the CRUVA app;

[0055] Fig. 37 is a flow diagram of a crew app job polling ; [0056] Figs 38a and b show a flow diagram of the CRUVA app;

[0057] Figs 39a and b show a screenshot of an Admin login page within the CRUVA app;

[0058] Fig. 40 is a screenshot of a Crew home screen of the CRUVA app;

[0059] Fig. 41 is a screenshot of a Crew accept/decline screen of the CRUVA app;

[0060] Fig. 42 is a screenshot of a Crew confirmed screen of the CRUVA app;

[0061 ] Fig. 43 shows a screenshot of a customer app of the CRUVA app during a Peak Activity period;

[0062] Fig. 44 is a schematic representation illustrating functionality associated with a CRUVA administrator;

[0063] Fig. 45 is a schematic representation illustrating functionality associated with a CRUVA application;

[0064] Fig. 46 is a schematic block diagram representation of a system architecture for implementing a CRUVA online booking system ;

[0065] Fig. 47 is a flow diagram illustrating a method for implementing a customer app associated with an online booking system ;

[0066] Fig. 48 is a flow diagram illustrating a method for implementing a supervisor app associated with an online booking system ;

[0067] Fig. 49 is a flow diagram illustrating a method for implementing a staff app associated with an online booking system ;

[0068] Figs 50a-d are screenshots illustrating a graphical user interface of an online booking system ;

[0069] Figs 51 a-c are interfaces associated with an online booking system ; and [0070] Figs 52a and 52b illustrate creation of a job quote. Detailed Description

[0071 ] Method steps or features in the accompanying drawings that have the same reference numerals are to be considered to have the same function(s) or operation(s) , unless the contrary intention is expressed or implied.

[0072] The present disclosure provides a system and method for booking resources, such as labour hire personnel. Labour hire personnel span all industries, including, but not limited to, entertainment, construction, mining, retail, health, education, information technology (I T) , manufacturing, finance, agriculture, tourism , media, transport, legal, and logistics. The system provides an interface among customers, who are clients of the system looking to book staff (also referred to throughout the specification as crew or staff members) . I n a simple arrangement, communication is between a customer (also referred to throughout the specification as a client) and one or more staff members. I n an alternative arrangement, each staff member is registered with a labour hire company (LHC) , whereby the LHC registers with the system. An LHC is referred to as a "partner" in this specification and the terms are used interchangeably throughout.

[0073] The method and system of the present disclosure provide one or more embodiments by which customers are able to access the combined labour pools of one or more Labour Hire Companies in order to broaden the possible choice of suitable staff and to conveniently put bookings through the system , such as through a software application ("app") interface, at any time of the day and night. The method and system provide a single access point to a consolidated list of available staff, with the option of ranking the available staff based on experiences of previous customers.

[0074] I n one embodiment, the booking system includes a server connected to a communications network, such as the I nternet, and a software application ("app") adapted for execution on a computing device. I n one arrangement, a client downloads the app to a computing device accessed by the client and then uses a client interface of the app to book staff . The client interface of the app provides a user-friendly graphical user interface (GUI ) to the client to enable the client to specify booking requirements in relation to staff requirements for a booking. Resource allocation software executing on the server searches one or more databases relating to registered staff and assigns staff to the booking. I n one arrangement, staff are registered directly with the booking system . Alternatively, staff are registered with one or more LHCs, whereby the LHCs are, in turn, registered with the booking system . I n one arrangement, the booking system is able to access databases of registered staff associated with the LHCs. I n an alternative arrangement, the LHCs provide staff information to be recorded on one or more databases associated with the booking system .

[0075] Fig. 1 a is a schematic block diagram representation of a booking system 100 having a server 150 connected to a communications network 1 10. The communications network 1 10 may be implemented using one or more wired or wireless transmission links and may include, for example, a dedicated communications link, a local area

network (LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof .

[0076] The example of Fig. 1 a also includes a first computing device 120 in the form of a desktop or laptop computer, a second computing device 130 in the form of a mobile computing device, and a third computing device 140 in the form of a tablet or phablet computing device. Each of the first computing device 120, the second computing device 130, and the third computing device 140 is also coupled to the communications network 1 10. A client, staff member, or authorised representative of an LHC can use one of the computing devices 120, 130, 140 to communicate with the server 150.

[0077] The server 150 may be implemented using a single computer or an array of computers, which may be co-located with one another or distributed over different physical locations. The server 150 includes a customer module 152, a supervisor module 154, a staff module 156, and a partner module 158. The server 160 also includes an application programming interface (API ) 160, a Cascading Request Until Verification App (CRUVA app) 162 and a database 164.

[0078] The API 160 is a programmable interface for controlling communications into and out of the server 150. The database 164 stores all data in relation to the booking system .

[0079] I n one arrangement, the server 150 includes an optional accounting module (not shown) , whereby the accounting module applies a charge to each booking transaction. I n one arrangement, the accounting module applies a listing charge to the client when providing a booking request. I n one arrangement, the accounting module only applies a charge in relation to a successfully completed booking, wherein staff are successfully booked through the server in response to a booking request, at the completion of their shift/s. [0080] Fig. 1 b illustrates logical communication flows between the server 150 and each of the computing devices 120, 130, 140, via the communications network 1 10. Fig. 1 c shows communication flows between each of the participants in the booking system 100. I n particular, Fig. 1 c shows communication between a client/customer 170 and the database 164, communication between a supervisor 175 and the database 164, communication between a staff member 180 and the database 164, and communication between a partner 185 and the database 164. I t will be appreciated that the

communication paths illustrated in Fig. 1 c are logical communication paths and actual communication with the database 164 occurs via the communications network 1 10 and the API 160 of the server 150.

[0081 ] Fig. 46 is a schematic block diagram representation of a system

architecture 4600 for implementing a CRUVA booking system in accordance with the present disclosure. A backend system 4610 includes a web service 4612, a CRUVA database 4614, a partner website 4616, and a CRUVA admin website 4618. Participants of the system 4600 include a customer 4620 who utilises the CRUVA booking system via a customer CRUVA app executing on a customer computing device 4625, a staff member 4630 who utilises the CRUVA booking system via a staff CRUVA app executing on a staff computing device 4635, and a supervisor 4640 who utilises the CRUVA booking system via a supervisor CRUVA app executing on a supervisor computing device 4645.

[0082] As noted above in relation to Fig. 1 , one embodiment of the system of the present disclosure is the CRUVA app 162. The CRUVA app 162 provides different functionality to each of the different participants shown in Fig. 1 c, that is, the

client/customer 170, the supervisor 175, the staff member 180, and the partner 185. I n one arrangement, the CRUVA app 162 is implemented as a single application delivering different subsets of functionality to the respective participants. I n an alternative implementation, different variations of the CRUVA app 162 are provided to each of the respective participants, with the different variations being constructed to deliver the functionality to the respective participants. Thus, in such an arrangement the CRUVA app 162 may be implemented as a client CRUVA app, a supervisor CRUVA app, a staff CRUVA app, and a partner CRUVA app.

[0083] Each different instance of the CRUVA app may be implemented as an app executing on a processor of a computing device accessed by a participant. Alternatively, each instance of the CRUVA app may be implemented as an app executing on a central server and accessible via a communications network, such as the I nternet, via a browser executing on a processor of a computing device accessed by a participant. Consequently, participants are able to utilise the CRUVA app using any suitable computing device with a communications link to the server 150. Thus, the CRUVA app is a flexible platform available to all participants at all hours.

[0084] Fig. 2 is a schematic block diagram representation of logical communication flows in the database 164. I n the example of Fig. 2, the database 164 includes a client data module 210, a staff data module 220, and a bookings data module 230. A client 202 registers with the booking system by using a web browser to access a website associated with the server 150 or by executing an app associated with the server 150 on a computing device 120, 130, 140 accessed by that client 202. The client 202 provides data that is stored in the client data module 210. I n one implementation, each client has an associated client profile, wherein each client profile includes a set of client attributes for that particular client. Such client attributes may include, for example, but are not limited to, the client name, client contact details, client financial information, and client transaction history.

[0085] A staff member 204 registers with the system by using a web browser to access a website associated with the server 150 or by executing an app associated with the server 150 on a computing device 120, 130, 140 accessed by that staff member. The staff member provides relevant information, such as staff name, staff financial information, staff transactions history, staff availability, staff rating, staff earnings to date, staff taxation data, and staff banking details, each of which is stored in the staff module 220 of the database 164 in a staff profile associated with that particular staff member 204.

[0086] A LHC registered with the system is able to add and remove staff from the system using a partner login page or by using their own rostering database if connected to CRUVA via an API . An individual staff member can act as an LHC, provided that they satisfy the relevant criteria for an LCH, which may vary from one jurisdiction to another. Such criteria may include, for example, being an incorporated company, having workers compensation insurance, public liability insurance, and the like. I n one arrangement, LHCs registered with the system are able to bid to recruit independently registered staff members. [0087] When making a booking 206, a client uses a web browser to access a website associated with the server 1 50 or by executing an app associated with the server 1 50 on a computing device 1 20, 130, 140 to provide booking data. The database 1 64 stores the booking data in the booking module 230, wherein such booking data may include, for example, but is not limited to, booking data, booking time, booking rates, booking history, and staff allocation. On receiving a booking request , the CRUVA app 1 62 processes the booking data to identify suitably qualified staff that are available for the booking time, thus facilitating connection between a client and available labour hire personnel.

[0088] I n one embodiment , the CRUVA app 1 62 identifies suitably qualified staff based on a set of criteria. I n one implementation , the set of criteria includes the following mandatory attributes, which ensure that the staff are suitably qualified for the particular booking, available for the booking time, and are in the same geographic area as the booking :

1 . Skill (Skill Qualifications/ I nductions) ;

2. Availability for the required time frame (Staff has set their availability within the required time frame for the Job) ; and

3. Location (Staff has the Job Location within their selected Preferred Work Area/s) .

[0089] Alternative embodiments optionally extend the set of criteria to include one or more other attributes, such as:

4. Rating - Staff are rated by customer feedback (e.g . , out of 5 Stars) ;

5. Urgency - "On Call" Staff ready and waiting for immediate work;

6. Transport - Staff member has own vehicle;

7. Experience - Years/ Months of experience Staff has in the role

(vetted by Partner) ;

8. Appearance - Presentability of Staff Member

(customer feedback and Partner input) ;

9. Proxim ity - Proximity to Job Location ;

1 0. Acceptance - Percentage of Shifts accepted by Staff ;

1 1 . Longevity - Total number of Jobs already worked in the CRUVA booking system ;

1 2. Punctuality - Record of being early/on time for Shifts;

13. Accuracy - Record of accuracy of previous times logged ; 14. History - Total number of hours already worked for the Customer; and

15. Rapidity - Rapidity of prior Shift acceptance

[0090] I n one implementation, the CRUVA app 162 executes on a processor of the server 150 and communicates via the communications network 1 10 with one or more external databases associated with one or more LHCs to identify and allocate available staff based on the set of criteria.

[0091 ] One arrangement applies a weighting to one or more of the attributes. For example, weightings may be based on the booking data, time of day, time remaining until the booking time starts, client preferences, or any combination thereof. I n one implementation, weightings applied to the different attributes in the set of criteria are such that the sum of the scores for the attributes is 100.

[0092] As noted above, the server 150 includes an optional accounting module for managing charges associated with bookings made through the booking server 150. I n one arrangement, an administrator of the server 150 applies a fee in the range of 5% to 20% for every booking transaction. The accounting module receives payment from the client associated with a booking, such as by credit card payment at the end of the booking time. I n the scenario in which the engaged labour hire personnel are registered with a LHC, in contrast to being registered directly with the booking server 150, the accounting module then arranges appropriate payment to the registered LHC (e.g. , once invoiced by the LHC) .

[0093] Clients are able to access the booking server 150 easily using a web browser or app executing on a local computing device to book staff with minimal effort in a consistent manner through the graphical user interface. The CRUVA app 162, in response to receiving a booking request from a client, provides the client with a real-time or near real-time quotation for the transaction. I n one implementation, the CRUVA app 162 provides such a quotation as the final step of the booking process. When the client accepts the displayed quotation, the client confirms the booking, such as by clicking a "Submit" button or the like, whereupon the CRUVA app 162 generates a booking confirmation for the client in relation to the new booking. The booking confirmation may be, for example, an SMS text message, email, push notification, or other alert message displayed to a device or within a browser window or app accessed by the client.

[0094] The CRUVA app 162 searches the database 164 and/or external databases associated with LHCs to identify and book the best available staff members, based on a predefined set of criteria. The CRUVA app 162 thus provides the client with access not to only one LHC, but to all LHCs registered with the server 150 and with independent staff members individually registered with the server 150. As the staff members and LHC know that bookings are allocated preferentially to labour hire personnel based on the set of criteria, there is an incentive for the labour hire personnel to perform in accordance with the criteria.

[0095] As labour hire personnel are able to register and accept bookings through an app executing on a mobile computing device, such as a smartphone 130 or tablet computing device 140, the app is able to use geo-location information derived from the mobile computing device to inform the client of the position of the respective labour hire personnel, ensuring that the labour hire personnel are on site during the duration of a booked shift. Clients see staff on the map during shift times and staff can opt in to be viewable 15 mins prior. The apps accessed by the client and labour hire personnel are configurable to send reminders at either predefined intervals relative to a booking or at customised time periods. For example, one implementation of the app sends a staff member booked for an event a reminder notification the day before a booked event, with a follow up reminder 1 hour before the booking, to ensure that the staff member is aware of the booking and presents for the booking on time. This, in turn, assists the staff member in achieving a higher punctuality score, which may lead to further bookings for which punctuality is an attribute in the set of criteria. Depending on the implementation, the reminder notifications may be implemented using in-app messages, SMS text messages, emails, push notifications, or any combination thereof .

[0096] Staff members of participating LHCs gain exposure to a large amount of potential work opportunities. Each staff member is able to use a web browser or app executing on a computing device to access the server 150 and configure their own respective availability. This provides staff members with great flexibility in being able to choose their own work hours in a dynamic way.

[0097] Staff members are also able to nominate preferred working locations. For example, staff members can choose working locations based on a geographical area, radius from a point of interest or address (by distance, travel time, or other measure) , listing of suburbs, councils or other geographical boundaries. Such flexibility enables staff with the ability to travel to obtain work in different locations. The app or web browser associated with the server 150 enables each staff member to readily change location preferences and settings. I n one implementation, the graphical user interface of the app or web browser provides the following functionality: o Accept/ decline Shifts with one button or decline/ add unavailability for the time period of the Shift; o Accept/ Decline Shifts with SMS text message (optional for Partners, Partner pays for SMS, improves attendance rate for staff) ;

o Sign off finish/break times with ease, optionally using geo-positioning and manual time entry, approved by supervisors; .

o Google map navigation to Job Location, ability to view other staff on the same job for car-pooling ; o See all upcoming jobs (rather than have to call an office) ; o View pay details online (staff can budget and query mistakes before being paid) ; and o Upload any certificates or licences (saves having to go to an office, creates a repository for files that can be accessed onsite) .

[0098] The CRUVA App 162 optionally enables staff members to use a camera, such as a webcam or phone camera, to photograph and upload documents. Once approved by an associated partner, the documents are stored in the staff data module 220 of the database 164 and are available for viewing through the server 150. Such documents may be important, for example, to validate qualifications held by a staff member, such as a Responsible Service of Alcohol (RSA) certificate for bar staff or security training credentials for security staff .

[0099] The booking server 150 connects LHCs to potential bookings from many different clients, thus improving the chances of finding work for staff members registered with those LHCs. Further, the booking system 150 optionally handles administrative functions, such as payroll, timesheets, rostering, and invoicing, thus relieving the registered LHCs of such administrative tasks. The booking server 150 enables LHCs to attract labour hire personnel from other areas, facilitating expansion of each LHCs activities into new territories.

[00100] The booking system of the present disclosure may be practised using a computing device, such as a general purpose computer or computer server. Fig. 3 is a schematic block diagram of a system 300 that includes a general purpose computer 310, which may be used to implement one or more of the server 150 or the desktop computer 120. The general purpose computer 310 includes a plurality of components, including : a processor 312, a memory 314, a storage medium 316, input/output (I/O) interfaces 320, and input/output (I/O) ports 322. Components of the general purpose computer 310 generally communicate using one or more buses 348.

[00101 ] The memory 314 may be implemented using Random Access Memory (RAM) , Read Only Memory (ROM) , or a combination thereof . The storage medium 316 may be implemented as one or more of a hard disk drive, a solid state "flash" drive, an optical disk drive, or other storage means. The storage medium 316 may be utilised to store one or more computer programs, including an operating system, software applications, and data. I n one mode of operation, instructions from one or more computer programs stored in the storage medium 316 are loaded into the memory 314 via the bus 348.

I nstructions loaded into the memory 314 are then made available via the bus 348 or other means for execution by the processor 312 to implement a mode of operation in accordance with the executed instructions.

[001 02] One or more peripheral devices may be coupled to the general purpose computer 310 via the I/O ports 322. I n the example of Fig. 3, the general purpose computer 310 is coupled to each of a speaker 324, a camera 326, a display device 330, an input device 332, a printer 334, and an external storage medium 336. The

speaker 324 may be implemented using one or more speakers, such as in a stereo or surround sound system . I n the example in which the general purpose computer 310 is utilised to implement booking system server 150, one or more peripheral devices may relate to additional hard drives connected to the I/O ports 322 for effecting an external implementation of the database 164. I n the example in which the general purpose computer 310 is utilised to implement the desktop computer 120, one or more peripheral devices may relate to a keyboard, touchscreen, mouse, webcam, or printer, for example, connected to the I/O ports 322.

[00103] The camera 326 may be a webcam , or other still or video digital camera, and may download and upload information to and from the general purpose computer 310 via the I/O ports 322, dependent upon the particular implementation. For example, images recorded by the camera 326 may be uploaded to the storage medium 316 of the general purpose computer 310. Similarly, images stored on the storage medium 316 may be downloaded to a memory or storage medium of the camera 326. The camera 326 may include a lens system, a sensor unit, and a recording medium.

[00104] The display device 330 may be a computer monitor, such as a cathode ray tube screen, plasma screen, or liquid crystal display (LCD) screen. The display 330 may receive information from the computer 310 in a conventional manner, wherein the information is presented on the display device 330 for viewing by a user. The display device 330 may optionally be implemented using a touch screen to enable a user to provide input to the general purpose computer 310. The touch screen may be, for example, a capacitive touch screen, a resistive touchscreen, a surface acoustic wave touchscreen, or the like.

[00105] The input device 332 may be a keyboard, a mouse, a stylus, drawing tablet, or any combination thereof , for receiving input from a user, such as client data, staff data, booking data, and the like. The external storage medium 336 may include an external hard disk drive (HDD) , an optical drive, a floppy disk drive, a flash drive, or any combination thereof and may be implemented as a single instance or multiple instances of any one or more of those devices. For example, the external storage medium 336 may be implemented as an array of hard disk drives. I n relation to Fig. 1 a, the external storage medium 336 may be used to implement all or part of the database 164.

[00106] The I/O interfaces 320 facilitate the exchange of information between the general purpose computing device 310 and other computing devices. The I/O interfaces may be implemented using an internal or external modem, an Ethernet connection, or the like, to enable coupling to a transmission medium. I n the example of Fig. 3, the I/O interfaces 322 are coupled to a communications network 338 and directly to a computing device 342. The computing device 342 is shown as a personal computer, but may be equally be practised using a smartphone, laptop, or a tablet device. Direct

communication between the general purpose computer 310 and the computing device 342 may be implemented using a wireless or wired transmission link.

[00107] The communications network 338 may be implemented using one or more wired or wireless transmission links and may include, for example, a dedicated communications link, a local area network (LAN) , a wide area network (WAN) , the I nternet, a

telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN) , a mobile telephone cellular network, a short message service (SMS) network, or any combination thereof . The general purpose computer 310 is able to communicate via the communications network 338 to other computing devices connected to the communications network 338, such as the mobile telephone handset 344, the touchscreen smartphone 346, the personal computer 340, and the computing device 342.

[00108] One or more instances of the general purpose computer 310 may be utilised to implement a server acting as a booking server to implement a booking system in accordance with the present disclosure. I n such an embodiment, the memory 314 and storage 316 are utilised to store data relating to client data, staff data, partner data, and the CRUVA app. Software for implementing the booking system , including the CRUVA app, is stored in one or both of the memory 314 and storage 316 for execution on the processor 312. The software includes computer program code for implementing method steps in accordance with the method of booking resources described herein.

[00109] Fig. 4 is a schematic block diagram of a system 400 on which one or more aspects of a booking method and system of the present disclosure may be practised. The system 400 includes a portable computing device in the form of a smartphone 410, which may be used to implement, for example, the mobile smartphone 130 or tablet computing device 140 used by a registered client, staff member, or partner in relation to the booking system 100 in Fig. 1 a. The smartphone 410 includes a plurality of components, including : a processor 412, a memory 414, a storage medium 416, a battery 418, an antenna 420, a radio frequency (RF) transmitter and receiver 422, a subscriber identity module (SI M) card 424, a speaker 426, an input device 428, a camera 430, a display 432, and a wireless transmitter and receiver 434. Components of the smartphone 410 generally communicate using one or more bus connections 448 or other connections therebetween. The smartphone 410 also includes a wired connection 445 for coupling to a power outlet to recharge the battery 418 or for connection to a computing device, such as the general purpose computer 310 of Fig. 3. The wired connection 445 may include one or more connectors and may be adapted to enable uploading and downloading of content from and to the memory 414 and SI M card 424.

[001 10] The smartphone 410 may include many other functional components, such as an audio digital-to-analogue and analogue-to-digital converter and an amplifier, but those components are omitted for the purpose of clarity. However, such components would be readily known and understood by a person skilled in the relevant art. [001 1 1 ] The memory 414 may include Random Access Memory (RAM) , Read Only Memory (ROM) , or a combination thereof . The storage medium 416 may be implemented as one or more of a solid state "flash" drive, a removable storage medium , such as a Secure Digital (SD) or microSD card, or other storage means. The storage medium 416 may be utilised to store one or more computer programs, including an operating system, software applications, and data. I n one mode of operation, instructions from one or more computer programs stored in the storage medium 416 are loaded into the memory 414 via the bus 448. I nstructions loaded into the memory 414 are then made available via the bus 448 or other means for execution by the processor 412 to implement a mode of operation in accordance with the executed instructions.

[001 12] The smartphone 410 also includes an application programming interface (API ) module 436, which enables programmers to write software applications to execute on the processor 412. Such applications include a plurality of instructions that may be pre-installed in the memory 414 or downloaded to the memory 414 from an external source, via the RF transmitter and receiver 422 operating in association with the antenna 420 or via the wired connection 445.

[001 13] The smartphone 410 further includes a Global Positioning System (GPS) location module 438. The GPS location module 438 is used to determine a geographical position of the smartphone 410, based on GPS satellites, cellular telephone tower triangulation, or a combination thereof . The determined geographical position may then be made available to one or more programs or applications running on the processor 412.

[001 14] The wireless transmitter and receiver 434 may be utilised to communicate wirelessly with external peripheral devices via Bluetooth, infrared, or other wireless protocol. I n the example of Fig. 4, the smartphone 410 is coupled to each of a printer 440, an external storage medium 444, and a computing device 442. The computing device 442 may be implemented, for example, using the general purpose computer 310 of Fig. 3.

[001 15] The camera 426 may include one or more still or video digital cameras adapted to capture and record to the memory 414 or the SI M card 424 still images or video images, or a combination thereof. The camera 426 may include a lens system, a sensor unit, and a recording medium . A user of the smartphone 410 may upload the recorded images to another computer device or peripheral device using the wireless transmitter and receiver 434, the RF transmitter and receiver 422, or the wired connection 445. [001 16] I n one example, the display device 432 is implemented using a liquid crystal display (LCD) screen. The display 432 is used to display content to a user of the smartphone 410. The display 432 may optionally be implemented using a touch screen, such as a capacitive touch screen or resistive touchscreen, to enable a user to provide input to the smartphone 410.

[001 17] The input device 428 may be a keyboard, a stylus, or microphone, for example, for receiving input from a user. I n the case in which the input device 428 is a keyboard, the keyboard may be implemented as an arrangement of physical keys located on the smartphone 610. Alternatively, the keyboard may be a virtual keyboard displayed on the display device 432.

[001 18] The SI M card 424 is utilised to store an I nternational Mobile Subscriber Identity (I MSI ) and a related key used to identify and authenticate the user on a cellular network to which the user has subscribed. The SI M card 424 is generally a removable card that can be used interchangeably on different smartphone or cellular telephone devices. The SI M card 424 can be used to store contacts associated with the user, including names and telephone numbers. The SI M card 424 can also provide storage for pictures and videos. Alternatively, contacts can be stored on the memory 414.

[001 19] The RF transmitter and receiver 422, in association with the antenna 420, enable the exchange of information between the smartphone 410 and other computing devices via a communications network 490. I n the example of Fig. 4, RF transmitter and receiver 422 enable the smartphone 410 to communicate via the communications network 490 with a cellular telephone handset 450, a smartphone or tablet device 452, a computing device 454 and the computing device 442. The computing devices 454 and 442 are shown as personal computers, but each may be equally be practised using a smartphone, laptop, or a tablet device.

[00120] The communications network 490 may be implemented using one or more wired or wireless transmission links and may include, for example, a cellular telephony network, a dedicated communications link, a local area network (LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN) , a cellular (mobile) telephone cellular network, a short message service (SMS) network, or any combination thereof . [001 21 ] Fig. 44 is a schematic representation 4400 illustrating functionality associated with a CRUVA administrator ("admin") portal. The adm in portal (or panel) is the actual website or app that Administrators of the Software use to tweak the settings of the entire platform that dictate how the processes of the CRUVA application , shown in Fig. 45, are to operate. The settings of the platform affect the Customer " Bookings" Website, the Partner Portal Website, the Customer "Bookings" App, the Supervisor App, and the Staff App. The functionality includes: add/edit/delete activity level ; enter potential staff result ; enter shift multiple; enter request rate value; enter notice time; add sociable hour; add sociability factor; and edit non-sociable (NS) peak time.

[001 22] Add/ Edit Delete Activity Level - The administrator has the ability to create Activity Levels that indicate how busy staff are, how many staff are working and , therefore, how many staff remain available for work. I n one arrangement, Activity Levels come in two forms: (i) Mild Activity Levels; and (ii) Peak Activity Levels. Peak Activity means the staff are busy and there are less available staff from which to choose. I n these circumstances, the CRUVA system needs to step up request messages to get staff booked in time. Request messages may be sent out at faster intervals (request Rate) and more messages at a time (Shift Multiple) per shift.

[001 23] Enter Potential Staff Result - Activity Levels are calculated as a percentage of Potential Staff to Unfilled Shifts for a Job Location. Potential Staff is the total number of staff with the mandatory attributes of skill, availability and location to make those staff eligible to work on a particular shift/shift unit. For example, for an 8: 00am shift at 420 George St, Sydney on 01 -01 -201 6 for Client X, there are 200 Potential Staff and 50 Unfilled Shifts making a Potential Staff Percentage of 400% . Divide this by 1 0 to get a Potential Staff Result of 40.

[001 24] Enter Shift Multiple - This attribute defines how many request messages are sent out to staff per shift. For example, for 2 vacant shifts, if 2 request messages are sent out to to one staff each (two staff total) , then that would be a Shift Multiple of 1 , because 1 request message was sent per shift. For 2 vacant shifts, if 4 request messages are sent out to one staff each (4 staff total) , then that would be a Shift Multiple of 2, because 2 request messages were sent per shift .

[ 001 25] Enter Request Rate Value - Request rate is the speed at which request messages are sent out, measured in minutes or seconds. I f messages are sent out every 90 seconds, the Request Rate is 90 seconds. [00126] Enter Notice Time - Notice Time is the time until Shift/Shift Unit Start time.

CRUVA automatically inputs Notice Time based upon Activity Levels. Notice Time can be manually entered by an administrator to override default values and can be reset to a predefined default value.

[00127] Table 1 shows examples of different Activity Levels and the associated Request Rates and Notice Times.

Table 1

[00128] Add Sociable Hour - Sociable hours are normal working hours in the daytime on weekdays. These are relatively easy times to get people to work when they are most available. Non-Sociable Hours are hours outside of Sociable Hours.

[00129] Add Sociability Factor - Sociability Factor is the estimated amount Non-Sociable Hours will reduce Potential Staff Results. For example, if the peak Non Sociable Peak Time is 2am and the Sociability Factor has been added by Admin as 2, then the Potential staff result will be halved at 2.00am. As the time moves from 2am , either before or after, the Sociability Factor will reduce and Potential Staff Results will improve. I f Non-Sociable Hours are 18: 00 to 07: 00 Monday to Friday (outside of Sociable Hours) , then at 22: 00 (exactly half way between 18: 00 and Non-Sociable Peak Time - NS Peak Time - of 02: 00) , the Sociability Factor will be 1 .5.

[00130] Edit NS Peak Time - Non Sociable Peak Time is the worst time of the day to find workers, when the least number of workers are available, because of the non sociable time of day (e.g., 2.00am) . The administrator adds Sociable Hours and a Sociability Factor in Administrator Login. CRUVA Calculates Non-Sociable Hours and sets a central NS Peak Time. The administrator can edit/override NS Peak Time. The Shift Sociability Factor scales down from NS Peak Time until Sociable Hours start/end. The Shift

Sociability Factor is the Admin Sociability Factor divided by the time between NS Peak and Sociable Hours Start/End multiplied by the time between NS Peak and Shift Start Time. Potential Staff Result is multiplied by Shift Sociability Factor to create a new Potential Staff Result (and corresponding Activity Level) .

[00131 ] I n one example, sociable hours are defined as Monday to Friday, from 07:00 - 18:00. The NS Peak time is set to be 00:30, which is the mid-point- between 18:00 and 07:00. The administrator in this example sets the NS Peak time as 02:00 and a Sociability Factor of 2. For a Shift at 23: 00, Shift Sociability Factor is 0.75 (Sociable Hours end at 18:00 and Peak NS Time is 02:00, 8 hours difference. Shift Start Time is 23:00 and Peak NS Time is 02:00, 3 hours difference. Therefore, the Sociability Factor for this Shift is 2 ÷ 8 x 3 = 0.75) . Multiply the Potential Staff Result by the Shift Sociability Factor to create a new Potential Staff Result. A Potential Staff Result of 50 (Peak Activity Level 3) multiplied by the Shift Sociability Factor of 0.75 makes a new Potential Staff Result of 37.5 (Peak Activity Level 4) .

[00132] Table 2 shows an example of administrator settings for Sociable Hours, with the administrator-entered values shown in bold.

Table 2

[00133] Fig. 45 is a schematic representation illustrating functionality associated with a CRUVA application 4500, based on the parameter values entered by the administrator in Fig. 44, described above. The functionality includes: default potential staff result value; default shift multiple default request rate; input automatic notice time; central non- sociable (NS) peak time; calculation of non-sociable hours; and sending request messages. [00134] Figs 38a and b show a flow diagram of a method 3800 for implementing the CRUVA app 162. The method 3800 begins at a start step 3801 and proceeds to step 3802, in which a registered client of the booking system 100 uses the CRUVA app executing on a processor of a computing device 120, 130, 140 to create a client job booking. The client job booking includes the number of staff required, the skills required, booking date and time, and the booking location. Control passes to step 3804, in which the CRUVA app generates a unique identifier associated with that client job booking and stores that unique identifier within the database 164.

[00135] Control passes from step 3804 to step 3806, in which the booking information input by the client is stored in the database 164 of the server 150. I n a next step 3808, the server 150 generates and transmits a booking confirmation message to the client. The confirmation message may be implemented in one or more ways, including an SMS text message, email, push notification, or notification within the CRUVA app. Control passes to step 3810, which builds a default shift message, 'Request Message' which will be sent to prospective staff members, and then passes to step 3812, which determines the time remaining until the nominated start time of the booking.

[00136] I f there is greater than a predefined period of time 'Notice Time', in this example "X hours", before the start time of the booking, 'Advance Notice', control passes to decision step 3860, which determines whether Peak Activity has been triggered. I f 'Peak Activity' has been triggered, then control passes to decision step 3814, which determines whether flow in the method is the first time through the loop. I f it is not the first time, No, control passes to step 3822. However, if it is the first time, Yes, control passes from step 3814 to step 3816, which selects eligible staff from one or more databases of staff, based on a set of criteria. I n this example, the set of criteria includes 'Order of Priority - Advance Notice'. The method then sorts the eligible staff candidates, based on rating. Control passes to step 3818, which runs the selection on the database. The method builds the select statement, runs the statement on the database, and stores the results in RAM and control then passes to step 3820, which stores a staff list in memory, such as RAM. Control then passes to step 3822, which retrieves the next group (Y) of matching staff from RAM.

[00137] Returning to step 3860, if the Peak Activity has not been triggered, No, control passes to decision step 3862, which determines whether it is the first time through this loop. I f it is the first time, Yes, control passes to step 3864, which selects based on the algorithm called Order of Priority - Advance Notice. Control then passes to step 381 8 to run the selection on the database. However, if at step 3862 it is not the first time through the loop, No, control passes directly to step 3822, which as described above retrieves the next group (Y) of matching staff from RAM.

[00138] Step 3824 offers shifts, via request messages, corresponding to the client booking to the identified Y number of eligible staff. Offers of the shifts may be sent by any suitable means, including SMS text message, email, push notification, notification within the CRUVA app, or the like. A staff member logged into the system receives the shift message 'Request Message', which optionally contains geographical information regarding the location of the shift . The system optionally displays the distance and travel time to the booking location , based on either a current position of the staff member or a registered address associated with that staff member. The system presents the staff member with the option of accepting or declining the shift . I f multiple jobs are available for a given staff member, the system progressively passes to each job site in sequence.

[00139] At step 3826, the method then waits a predefined period of time (Z) 'Request Rate' before proceeding to decision step 3828, which determines whether all of the available shifts associated with the client booking have been filled . I f all of the available shifts have been filled , Yes, control passes to step 3830, which sends a successful booking notification to the client , confirm ing that the staffing requirements of the booking request have been fulfilled . Control passes to step 3832, which displays identification information of staff who have accepted the shifts associated with the booking . Such identification information may include, for example, the first name, last initial, and a photo of each staff member. Depending on the role to be performed, other information , such as evidence of qualifications, may also be provided . Control passes from step 3832 to stop step 3890 and the method 3800 terminates.

[ 00140] Returning to step 3828, if all of the shifts associated with the booking have not yet been filled, No, control returns to step 381 2. I f at step 381 2 the client has cancelled the booking, control passes to step 3832, which creates a cancellation message, and then passes to step 3836, which sends the cancellation message to affected parties, such as the client , staff, and partners. Control passes from step 3836 to the stop step 3890 and the method 3800 term inates.

[ 00141 ] Returning to step 381 2, if there is less than the predefined period of time (Notice Time) (X hours) remaining before the start time of the booking, (Short Notice) , control passes to decision step 3840, which determ ines whether it is the first time through this loop. I f it is not the first time through this loop, No, control passes to step 3842, which determ ines whether any surge pricing criteria has been met . Peak pricing may be used to inflate or deflate remuneration offered in relation to a booking. I f all shifts have not been filled as a booking start time approaches, peak pricing may operate to increase the remuneration in an attempt to attract staff to accept the remaining shifts.

[00142] I n one implementation, the criteria for peak pricing includes a determ ination of whether there is less than a predefined number of hours (T) before the scheduled start time of the booking. I f any peak pricing criteria has not been satisfied , No, control passes to step 3822. However, if the peak pricing criteria has been satisfied, Yes, control passes to step 3844, which resets a position of staff selection to the start of the staff list stored in memory. Control then passes to step 3846, which offers price incentives to eligible staff in an attempt to fill the remaining shifts associated with the booking . As noted above, such price incentives may relate to an increase in rem uneration or improvement of other conditions associated with the booking. Control passes to step 3822. Once peak pricing has been activated , the system optionally modifies the time delay (Request Rate) Z in step 3826 between sending shift messages to the next set of matching staff members. The number of staff Y (Shift Multiple) to which the shift message may also be increased, as the system attempts to fill the available shift(s) with more urgency. I n another implementation, the criteria for peak pricing includes a determination of whether the hours to be worked are Sociable Hours. Non-Sociable Hours may affect the Activity Level of a Booking or Shift/s within a Booking and Peak Pricing may kick in.

[00143] Returning to step 3840, if it is the first time through this loop, control passes to step 3848, which selects staff based on the set of criteria and orders the selected eligible staff based on at least one of Order of Priority - skill/qualifications/inductions, availability, location , rating, whether a Staff is "On Call" , experience in the role, appearance, GPS proximity to the booking location, prior acceptance- rate of bookings, time served working with the CRUVA, punctuality, accuracy of logging times, time served with the client and speed of accepting bookings rating , or any combination thereof .

[ 00144] Control passes to step 3850, which runs the selection on the database, and then to step 3852, which stores staff selection in memory, such as RAM. Control then passes to step 3842. [00145] Returning to step 3812, if the booking start time has already passed, control passes to step 3838, which generates a message to the client advising that it has not been possible to find staff to fill all of the shifts associated with the booking. The message indicates how many shifts have been filled. Control passes to step 3832 and then to step 3890 and the method 3800 terminates.

[00146] Fig. 37 is a flow diagram of a method 3700 for crew app job polling. The method 3700 begins at a start step 3702 and proceeds to step 3704, in which a staff member accesses a "crew app" version of CRUVA on a computing device and the crew app polls the server 150 for available jobs. Decision step 3706 determines whether there are any jobs available. I f there are jobs available, Yes, control passes to step 3708, which displays the set of available jobs to the staff member. Control passes to decision step 3710, in which the staff member decides whether or not to accept one of the available jobs.

[00147] I f the staff member accepts one of the available jobs, Yes, control passes to step 3712, which writes the staff member's acceptance to the server database 164.

Control passes from step 3712 to step 3714, which polls the server 150, and step 3716 determines whether or not the job has been allocated. I f the job has been allocated, Yes, control passes to step 3718, which displays a notification, such as a push notification advising of the job allocation. Control passes to step 3750 and the method 3700 terminates. Returning to step 3716, if the job has not been allocated, No, control returns to step 3714, which loops through step 3716 until the job has been allocated.

[00148] Returning to step 3710, if the staff member decides not to accept one of the available jobs, No, control passes to step 3720, which writes the response to the database 164 and control then passes to step 2750 and the method 3700 terminates.

[00149] Returning to step 3706, if there are no jobs available, No, control passes to step 3750 and the method 3700 terminates.

[00150] I n order to use the CRUVA app to access the booking system 100, a client accesses a computing device 120, 130, 140 and downloads the CRUVA app from the server 150. Figs 5 to 36 are screenshots of a graphical user interface of the CRUVA app presented to a user during various stages of the booking process. The client then enters relevant client details, such as client contact details and banking (e.g., credit card) details. I n one implementation, the app transmits the client details to the server 150, which generates an email with an embedded link to validate the client as a registered user. Once the system validates the client, the app displays a home page to the client, such as the home page screen shown in Fig. 5. I n the example of Fig. 5, the client is able to select a job location for a new booking by entering an address in a dialog box. I n one implementation, the dialog box is prepopulated with the last booking made by the client. I n another implementation, the client is able to store one or more favourite locations to be used for recurring bookings. I n one implementation, the home page booking screen shows a map to assist the client in identifying a job location. Fig. 6 shows a client entering " Hilto" into the dialog box, whereupon the system provides suggestions of likely places.

[00151 ] The client selects a job location and then provides criteria relating to the labour hire personnel (staff/crew) that are required, as shown in Fig. 7. The client enters the required skills for the booking in the interface screen shown in Fig. 8. The skills may be selected from radio buttons or drop down boxes relating to predefined sets of skills. Alternatively, the client types the required skills into a dialog box. The system optionally prompts the client with suggestions for skill matches. I n one arrangement, any new skills that are to be added to the predefined sets of skills must be approved by a system administrator. Once the client has entered skills required of the staff , the app confirms either Skill Available I n Your Area or Skill Unavailable in Your Area. I f the required skill is available, the client locks it in and proceeds to the next step. Alternatively, if the client receives the message Skill Unavailable in Your Area - Select Alternative Skill, then the client must choose a different skill.

[00152] The client identifies how many staff are required for the selected skill. The client can optionally choose to request further staff having different skills. For example, the client may require one foreman and two fork lift drivers. I n another example, the client may require two chefs and six waitstaff. The app provides further input screens that enable the client to select different skillsets. Fig. 9 shows a screen interface relating to an extra skills screen that allows a client to enter a break period for a job.

[00153] Fig. 10 is a screenshot of a second extra skills screen of the CRUVA app. Once a first break has been entered, the screen provides an option to enter a second break period. Similarly, once a second break period has been entered, the screen automatically provides an option to enter a third break period. Once a skill has been entered by the client, the screen automatically provides an option to enter a new skill. The new skill box defaults to the same settings as the previous skill settings, such as those relating to date, time on, time off. I n one arrangement , the screen is adapted to scroll to accom modate further information, if a single screen is insufficient to display all of the relevant information . I n one arrangement , each break time period has a default time period of 30 minutes.

[001 54] Fig. 1 1 is a screenshot of an extra skills user interface, presenting a list of extra skills that may be selected . I n one arrangement , the user interface does not allow a user to add any additional skills to the list of extra skills. I n an alternative arrangement , the user interface allows the user to add additional skills to the list of extra skills.

[001 55] The server 1 50 generates an instant quote, such as that shown in Fig. 1 5, which is presented to the client. The quote includes the total cost for the booking . The client verifies information in the quote and chooses whether or not to proceed . When the client proceeds, the server 1 50 generates and transm its a confirmation message to the client, as described above with reference to step 3808 of Fig . 38a and shown in Fig. 1 6. I n one arrangement, each quote is valid for a predefined time. As the predefined time nears expiry, the server 1 50 optionally sends a reminder message to the client . The client is optionally able to edit the quote, to add or delete staff, modify booking information, change skills, and the like. Expired quotes can be renewed and regenerated . Clients can also create new quotes based on past bookings.

[001 56] Fig. 22 is a screenshot of a location positioning screen of the CRUVA app. I n a map region of the positioning screen , a user can move a pin to an exact meeting place on the map. The meeting place can then be saved for future bookings.

[001 57] Fig. 31 is a screenshot of a view staff screen of the CRUVA app. I f a booking is edited, the app sends an email to the customer and partner. Staff are notified by a push notification on the app that the booking has changed . Staff can then either accept or decline the change. I f the staff declines the change, then CRUVA rebooks staff for the shift . The partner is emailed whenever their staff are booked on shifts or if there are changes to their staff's shifts.

[001 58] Fig . 35 is a screenshot of a timesheet map screen of the CRUVA app. Staff are able to clock on for a shift using proxim ity to a customer supervisor, using GPS positioning or other geolocation information derived from a computing device accessed by the staff member. When the staff member is within a predefined range of the customer supervisor within a predefined period of time prior to a shift start time, the staff member is recorded as starting the shift . The app optionally sends push notifications to keep the client informed of staff movements. I n the example of Fig. 35, Peter B arrived at 8: 24am and Nguyen V is running approximately 3 minutes late. Fig. 36 is a screenshot of a timesheet screen of the CRUVA app. I n this example, the same staff movements are shown as for Fig. 35, with the addition that Jeffrey K is being replaced.

[00159] Fig. 47 is a flow diagram illustrating a method 4700 for implementing a customer app associated with an online booking system. The method 4700 begins at a Start step 4702 and proceeds to step 4704 to register. Control then passes to step 4706, in which the customer logs in to the system . As shown in Fig. 47, the customer may go directly to the log in screen, even if not registered, in which case control passes to decision step 4708. I f the customer is not registered, control passes to step 4704 for the customer to register with the online booking system. I f the customer is registered, control returns to step 4706 for the user to log in. An optional step 4799 may be called from login step 4706 if the user needs to recover authorisation information, such as a forgotten or lost username and/or password. From step 4706, the customer has the option to change a password 4710 or proceed to the home page 4712.

[00160] From the home page 4712, the customer can see jobs on a calendar view 4714 or access a list view job 4716, or go to a menu 4718. From the menu 4718, the customer can navigate to create a new job 4720, by selecting a data and duration 4722, selecting a location 4724, selecting skills 4726, performing a job preview 4728, generating a quote 4730, and confirming the quote in step 4732. From step 4732, the customer optionally chooses one or both of a supervisor 4736 and an induction plan 4734.

[00161 ] Alternatively, from the menu step 4718, the customer can view existing jobs 4740 or save jobs 4742, which can be filtered based on location 4744. The customer can also access alerts 4746, and identify where and to what the alerts relate 4748. The customer can also access payments 4750 and payment history 4752. Further, the customer can access and review terms and conditions 4754, a customer profile 4756, including viewing and/or editing a full profile 4758, and accessing supervisors 4760. From the supervisor module 4760, the customer can manage supervisor 4762 and add/update supervisor 4764.

[00162] Returning to step 4716, the customer can access job details 4766, setting 4768, and edit a job or booking in step 4770. From the job details 4766, the customer can also view timesheet 4772. From step 4770, the customer can view staff 4774, view a quote or invoice 4776, edit a job 4778, rebook a job 4780, add/edit additional information 4782 or add/edit a qualification 4790.

[00163] Fig. 48 is a flow diagram illustrating a method 4800 for implementing a supervisor app associated with an online booking system . The method 4800 begins at a supervisor app start step 4802 and proceeds to a login step 4804. From the login step 4804, the supervisor can change a password 4806 or recover a lost password 4808.

[00164] The supervisor proceeds from the login page 4804 to a home page 4810, from which the supervisor can view a job on a calendar 4812, list a view job 4844, or access a main menu 4814. From the main menu 4814, the supervisor can log out 4816, view ongoing jobs 4818 or access jobs 4820. When accessing jobs 4820, the supervisor can filter based on location 4822. From the main menu 4814, the supervisor can also access messages 4824, profile 4836, and terms and conditions 4842.

[00165] When viewing messages 4824, the supervisor can access a message list 4826, and access received messages 4828, message details 4830, sent messages 4834 and delete messages 4832. When viewing a profile 4836, the supervisor can change a password 4838 or edit the profile 4840.

[00166] Returning to the main menu 4814, when a supervisor views ongoing jobs 4818, control passes to list view job 4844 and then to job details 4846. Control branches to a settings step 4848 and a view timesheet step 4850. The settings step 4848 enables the supervisor to track staff 4856, create a team 4864, edit a schedule time 4866, send a message 4868, and change a team lead 4870. When tracking staff 4856, the supervisor can track a single staff member 4858m track a staff task completed action 4860, or track a staff timesheet approved 4862. When viewing a timesheet 4850, the supervisor can edit a timesheet 4852, and send an updated timesheet to staff 4854.

[00167] Fig. 49 is a flow diagram illustrating a method 4900 for implementing a staff app associated with an online booking system . The method begins at a Staff start step 4902 and proceeds to a login step 4904. The login step 4904 passes to step 4908 to determine whether or not the staff is registered with the online booking system. I f the staff is not registered, No, control passes from step 4908 to registration step 4910, which then returns control to step 4904. I f the staff is registered, Yes, control returns from step 49087 to step 4904 for the staff to enter the required authorisation information, such as username and password. The login page 4904 also provides the user with the option of changing the password 4906. [001 68] Once the staff has logged in, control passes from the login page 4904 to a home page 4914, from which the staff can perform different functions. The staff can view a job on a calendar 491 6, list view job 491 8, or access a central menu 4920. From the menu 4920, the staff can logout 4922 or view ongoing jobs 4924, from where the staff can list view job 491 8. From the menu 4920, the staff can also view job history 4926, access alerts 4928, view privacy policy 4930, view terms and conditions 4932, and access a staff profile 4934. When accessing a job history 4926, the staff can view a history calendar view 4936 or a history list view 4938.

[001 69] When the staff is accessing the list view job 491 8, the staff can access job details 4940 and then accept a job 4942, make oneself unavailable 4944, or ignore the job 4946.

[001 70] Figs 39a and b show a screenshot of an Admin login page within the CRUVA app. I t will be appreciated that such an Adm in login page may take many forms. I n this example, the login page includes messages sent , messages received, and a set of bookings in various stages. The bookings are optionally highlighted or colour coded to denote one or more of different customers, staff members, shift tim ing , shift completion status, or any combination thereof.

[001 71 ] I n one arrangement , the Admin login page shows a message log of all messages between the booking system and staff , with the most recent messages appearing at the top of the display screen . The message log is searchable by one or more of date range, client, staff member, job number, shift number, and mobile phone number. I n the example shown , the bottom message corresponds to a booking for three shifts to be filled . Three request messages are sent to the top three staff in the order of priority. I n the subsequent messages, it can be seen that Susan Davies accepted the shift, James O'Neill declined the shift , but is available for more shifts in the same time slot . Michael Simpson declined the shift and made himself unavailable for any shifts in the same time slot.

[001 72] Subsequently, Susan Davies is confirmed for the shift , so one shift has been filled and two shift remain unfilled. Two new request messages are sent to staff ranked fourth and fifth in the order of priority. Mary Jones declined the shift, but remains available for more shifts in the same time slot. Nguyen Vanga accepts the shift and is subsequently confirmed for that shift, leaving one shift unfilled. One further request message is sent to staff ranked sixth in the order of priority. Roger Gibbs accepts the shift and is confirmed for that shift, resulting in all shift being filled. [00173] Figs 40 to 42 are screenshots presented to "Crew" or staff members through the CRUVA app. Fig. 40 is a screenshot of a Crew home screen of the CRUVA app. Fig. 41 is a screenshot of a Crew accept/ decline/ make unavailable screen of the CRUVA app. Staff can accept shifts, decline shifts, or make themselves unavailable for the time period of the shift. The staff member will not be offered any shifts during any nominated period of unavailability. Fig. 42 is a screenshot of a Crew confirmed screen of the CRUVA app.

[00174] Fig. 43 shows a screen of an app displayed to a customer on a computing device, such as a smartphone, in relation to Peak Activity. I n this example, the app displays two pricing options to the customer. A first option is at the standard rate, which is

accompanied by a low estimation of success at filling all of the shifts. I n Peak Activity periods, there is a surplus of shifts relative to labour hire personnel suitable for those shifts, so the labour hire personnel can demand higher wages. The second option includes a Peak Pricing weighting, which is accompanied by a higher estimation of success at filling of the shifts. That is, if the customer offers higher wages during Peak Activity period, there is a greater likelihood of being able to fill all of the shifts.

[00175] I n the example of Fig. 16, the client is optionally able to provide further booking information, such as inductions, qualifications, onsite contacts, meeting places, notes for the staff members, notes for a partner (LHC with which the staff is registered) , and the like, as illustrated in Figs 17 to 23. Fig. 24 shows a return to the booking page, which lists active bookings associated with the client. I n one implementation, the booking page includes a Systems Option icon, which enables the client to select options relating to settings, bookings, history, invoices, and the like.

[00176] The CRUVA app then allocates staff to the booking, as described above with reference to Figs 37 and 38. I f a staff member, having accepted a shift, cancels the shift, and that staff member is associated with a partner (i.e. , an LHC) , then it is up to the partner to replace the staff member. I f the partner is unable to do so, or Short Notice has elapsed, or Peak Activity Levels have occurred, then the booking shift becomes open and the CRUVA booking system attempts to fill the available booking shift from other registered staff members. I n some cases, the booking system replaces staff member/s as soon as they cancel shifts.

[00177] The CRUVA app can optionally be used to sign attending staff on and off in terms of attendance and staff breaks, either manually or by using geolocation information derived from a computing device used by the staff member. Alternatively and additionally, the client/supervisor is able to sign staff on and off using the CRUVA app executing on a computing device used by the client. The client is also able to rate each staff member.

[001 78] One implementation applies a sliding scale of cancellation charges that are applied in the event that a client cancels a booking , wherein the sliding scale is based on the amount of time remaining between the time of cancellation and the start time of the booking.

[001 79] I n order to use the CRUVA app to access the booking system 1 00, a staff member registered with a LHC accesses a computing device 1 20, 130, 140 and downloads the CRUVA app from the server 1 50. The app displays a "Crew" Staff page with a location of the staff member and showing the staff member as either active or inactive. During an initial setup phase, the app sets an initial radius a predefined distance from a current location of the staff member. The current location may be determ ined by an address provided by the staff member or by geolocation information derived from the computing device. I n one implementation , the predefined distance is 50km from the current location of the staff member. I n an alternative implementation, the radius from the current location is based on travel time, rather than distance. I t will be appreciated that other measurements may equally be used, either alone or in combination . Further, in one implementation, the staff member can have more than one preferred job location .

[001 80] The staff member is able to change status from active to inactive. I f the staff member accepts a shift for a booking , the staff member becomes active 'On Call'. The app displays a set of available jobs within the predefined distance of the current location of the staff member. The staff member is able to zoom in or out to change the number and location of available jobs. The staff member can also change the current location to change the region in which available bookings are identified. The staff member can store and update multiple addresses and set a different radius for each . The staff member can also view jobs on a chronological list of Available Shifts. The staff member may also view shifts in calendar form and graphical form .

[001 81 ] The app alerts the staff member of available jobs through a notification message sent using one or more of an SMS text message, an email, in-app message, or push notification to the app. The notification message may activate a vibration device, alarm , light, or other alert feature of the computing device accessed by the staff member. [00182] I n one implementation, a notification message shows a map of the available booking location with radiating rays acting as a beacon to summon staff. The staff member is able to view information relating to the available bookings and then accept or decline the bookings.

[00183] One implementation of the CRUVA app provides directions to the booking location. Such directions may be based on a user nominated mode of transport.

Alternatively, the CRUVA app optionally interfaces to a map database and public transport databases to provide available travel times and transport modes.

[00184] The CRUVA app optionally includes a start button and stop button associated with the nominated start and stop times of the booking. This assists with timekeeping and thus invoicing relating to the booking. I f the booking runs past the scheduled finish time, the CRUVA app applies rates/ penalty rates based on the skill of the staff member and adds the additional amount to the bill to be paid by the client. The CRUVA app is also adapted to record breaks by means of the staff member starting and stopping a break function.

[00185] A CRUVA Crew app executes within the CRUVA app executing on a computing device accessed by a staff member. The CRUVA Crew app runs even when the CRUVA app is turned off and periodically polls the server 150 for available jobs.

[00186] When a job is available, the server 150 returns a list of available jobs to the CRUVA Crew app, whereupon the CRUVA Crew app generates an alert notification to the staff member. Depending on the implementation, the alert notification may be an SMS text message, email, push notification within the CRUVA app, vibration, sound, or any combination thereof. On receiving the alert, the staff member accesses the CRUVA app to respond to the available job(s) by accepting or rejecting that job/shift. The server 150 writes the response to the server database 164. The response effectively indicates the availability of that staff member for the available job. The CRUVA app 162 on the server 152 then selects a set of prospective staff members, as described above with reference to Figs 38a and b and then notifies both successful and unsuccessful staff members in relation to the shifts available for a booking.

[00187] The CRUVA app executing on a computing device accessed by a client enables the client to enter bookings, view and edit current bookings, and rebook current and past bookings. I n one arrangement, the CRUVA app provides the client with a graphical user interface that presents one or more forms or templates to the client to ensure that information is captured from the client in a clear and consistent manner. All booking information provided by the client is transmitted to the server 150 via the communications network 1 10 for storage in the database 164. Even if the Client rejects a quote, they can save the booking for future reference. Clients can re-book saved bookings and assign a new start date.

[00188] I n one arrangement, the server includes an accounting module for handling payment transactions, such as credit card, direct deposit, and other electronic payment transactions. Such payment transactions include incoming payments received from clients in relation to bookings and outgoing payments made to staff in relation to completed bookings.

[00189] Labour hire personnel typically report to a supervisor in relation to a particular booking. The supervisor is often an onsite contact or may be the client itself . One implementation of the CRUVA app provides a supervisory function, wherein the supervisor is able to view a staff location at a predefined period of time before a booking start time. For example, a client creates a booking for 3 labourers for a daytime shift beginning at 7am . The client accesses the CRUVA app executing on a smartphone 130 at 6:45am, whereupon the app displays the staff location of each of the 3 labourers accepted for the booking, based on geolocation data derived from the portable computing devices used by the respective labourers, wherein the portable computing devices will typically be smartphones 130 or tablets 140. This provides the client (or supervisor) with confidence that the labourers will be in position on time at the start of the booking.

[00190] I n one implementation, staff members that are positioned within a predefined distance of the supervisor within a predefined time period of the booking start time are automatically recorded by the app as having a start time corresponding to the booking start time. Similarly, staff members that are positioned within a predefined distance of the supervisor within a predefined time period of the booking end time are automatically recorded by the app as having a finish time corresponding to the booking finish time, unless overridden by the supervisor in the event of overtime.

[00191 ] The supervisor is able to record attendance of the staff members via the app, along with managing breaks, shift variations, and the like. All of the relevant data is transferred back to the server 150, which is then able to generate timesheets, tax invoices, payslips, calculate penalty rates, peak rates, and the like. [00192] As indicated above, it is common for labour hire personnel to be associated with a LHC (partner) . Accordingly, the partner needs to be able to see and manage bookings associated with staff registered with that partner. The booking system 100 provides a partner with access to the server 100 in order to add and edit staff lists. The partner is able to view and browse past and present bookings relating to its staff. Further, the partner is able to allocate staff to available bookings in real-time.

[00193] The server 150 is adapted to send notifications to partners, via any suitable means, to inform the partners of available bookings. The server 150 is also able to display to a computing device accessed by the partner information relating to revenue associated with staff registered to that partner.

[00194] As noted above, the CRUVA app 162 is adapted to identify suitably qualified staff based on a set of criteria. Different criteria and weightings may be applied, depending on the particular circumstances. We will now discuss four different algorithms for identifying staff .

Multiple Request Messages - Short Notice

[00195] For short notice (ASAP) bookings with less than a predefined amount of notice time (say, X minutes) , staff are booked in order of priority with multiple request messages. I n one implementation the order of priority ranks the set of criteria used to select staff as follows:

1 . Skill

2. Availability

3. Location

4. Rating

5. Urgency

6. Transport

7. Experience

8. Appearance

9. Proximity

10. Acceptance

1 1 . Longevity

12. Punctuality

13. Accuracy

14. History 1 5. Rapidity

[001 96] Let us consider an example in which a client makes a booking of 20 shifts in a low activity period. The CRUVA app 1 62 sends out 80 request messages in order of priority. 5 staff accept shifts and the CRUVA app confirms their shifts through confirmation messages. As 1 5 shifts remain unfulfilled after a predefined period of time (say, 2 minutes after the first round of requests) . CRUVA then sends out another 60 request messages in order of priority. This time, a further 9 staff accept shifts and the CRUVA app confirms their shifts through confirmation messages.

[001 97] Now, a further 6 shifts remain unfulfilled and so CRUVA sends out a third batch of request messages; in this example, 24 further request messages are sent in the third round . CRUVA repeats this process, illustrated in Figs 38a and b with reference to items 381 6 - 3828, until all of the shifts have been filled or until all potential staff have received request messages.

Order of Priority - Short Notice/ Peak Activity

[ 001 98] For bookings at short notice or during periods of peak activity, this algorithm requires that the set of criteria includes the following mandatory attributes:

1 . Skill - Staff has the required Skill/ Qualifications/ I nductions

(vetted by Partner)

2. Availability - Staff has set their availability within the required time frame for the Job

3. Location - Staff has the Job Location within their selected Preferred

Work Area/s

[001 99] The set of criteria, in this example, includes further desirable attributes stored in each staff profile:

1 . Rating - Staff are rated by customer feedback out of 5 Stars

2. Urgency - "On Call" Staff ready and waiting for im mediate work

3. Transport - Staff member has own vehicle

4. Experience - Years/ Months of experience Staff has in the role

(vetted by Partner)

5. Appearance - Presentability of Staff Member

(customer feedback and Partner input)

6. Proxim ity - Proximity to Job Location by GPS

7. Acceptance - Percentage of Shifts accepted by Staff 8. Longevity Total number of Jobs already worked in the CRUVA booking system

9. Punctuality Record of being early/on time for Shifts

10. Accuracy Record of accuracy of previous times logged

1 1 . History Total number of hours already worked for the Customer

12. Rapidity Rapidity of prior Shift acceptance

[00200] I n one implementation, the desirable attributes have scores that total 100. An administrator of the server 150 or the client re-orders an attribute by editing its scores. For example, one scheme is configured with the following scores for the desirable attributes:

1 . Rating Score: 20

2. Urgency Score: 10

3. Transport Score: 10

4. Experience Score: 10

5. Appearance Score: 10

6. Proximity Score: 10

7. Acceptance Score: 05

8. Longevity Score: 05

9. Punctuality Score: 05

10. Accuracy Score: 05

1 1 . History Score: 05

12. Rapidity Score: 05

Total : 1 00

[00201 ] The following example shows desirable attributes for a staff member:

1 . Rating Score: 20 16.7

2. Urgency Score: 10 10 (Either 10 or Zero)

3. Transport Score: 10 0 (Either 10 or Zero)

4. Experience Score: 10 7.9

5. Appearance Score: 10 6.2

6. Proximity Score: 10 2.3

7. Acceptance Score: 05 5.0

8. Longevity Score: 05 6.7

9. Punctuality Score: 05 8.1 10. Accuracy Score: 05 4.8

1 1 . History Score: 05 05

12. Rapidity Score: 05 4.2

Total : 1 00 82.9% Quality Score

[00202] The CRUVA app sends request messages to staff members in order of priority determined by the quality scores. Thus, a client can effectively apply weightings to different desirable attributes by adjusting the total score available for any one or more of the desirable attributes. I n a job where punctuality and accuracy are of the utmost importance, then punctuality and accuracy might be allocated maximum scores out of 30, whereas proximity must be allocated a score of only 5.

[00203] I n some implementations, desirable attributes may become mandatory attributes. For example, for a shift for 1 staff member in a remote location, the staff member having their own transport may be a necessity. I n another example, a booking for a corporate client may require a high appearance score as a necessity.

[00204] I n one arrangement, a client can select which attributes are mandatory attributes in the set of criteria for that particular client. The client is further able to select an order in which the mandatory and desirable attributes appear, thus providing different weightings to provide the customer with a customised booking service. I n other words, different customers can have different Orders of Priority of Staff. Clients can set their order of priority permanently in settings or can alternatively set the order of priority for individual bookings, or they can tick what attributes they require.

Single Request Messages - Advance Notice

[00205] For advance bookings received from a client with more than a predefined period of notice time before the booking start time (say, greater than X minutes) , staff are booked in order of priority with single request messages.

[00206] I n one implementation the order of priority ranks the set of criteria used to select staff as follows:

1 . Skill

2. Availability

3. Location

4. Rating

5. Experience

6. Appearance 7. Proxim ity

8. Acceptance

9. Longevity

1 0. Punctuality

1 1 . Accuracy

1 2. History

13. Transport

14. Urgency

1 5. Rapidity

[00207] For a booking of 20 shifts, CRUVA sends out 20 request messages to staff members selected in order of priority. For example, 5 staff accept the shifts, leaving 1 5 shifts remaining 1 minute after the first round of requests. CRUVA then sends out another 1 5 request messages. This time, 9 further staff accept shifts, leaving 6 shifts remaining. CRUVA sends out 6 more request messages and repeats the process until all shifts have been filled or all staff have been notified .

Order of Priority - Advance Notice

[00208] I n this implementation, the set of criteria include skill, availability, location, rating, experience, appearance, proximity, acceptance, longevity, punctuality, accuracy, history, transport, urgency, and rapidity.

[00209] Mandatory attributes are set as:

1 . Skill - Staff has the required Skill/Qualifications/ I nductions (vetted by Partner)

3. Location - Staff has the Job Location within their selected Preferred

Work Area/s

[0021 0] The set of criteria, in this example, includes further desirable attributes stored in each staff profile:

1 . Rating - Staff are rated by customer feedback out of 5 Stars

2. Experience - Years/ Months of experience Staff has in the role

(vetted by Partner)

3. Appearance - Presentability of Staff Member (customer feedback and Partner input)

4. Proximity Proximity to Job Location by GPS

5. Acceptance Percentage of Shifts accepted by Staff

6. Longevity Total number of Jobs already worked in the CRUVA booking system

7. Punctuality Record of being early/on time for Shifts

8. Accuracy Record of accuracy of previous times logged

9. History Total number of hours already worked for the Customer

10. Transport Staff Member has a vehicle

1 1 . Urgency "On Call" Staff ready and waiting for immediate work

12. Rapidity Rapidity of prior Shift acceptance

[0021 1 ] The desirable attributes have scores that total 100. An administrator of the server 150 or the client re-orders an attribute by editing its scores. For example, one scheme is configured with the following scores for the desirable attributes:

1 . Rating Score: 20

2. .Experience Score: 10

3. Appearance Score: 10

4. Proximity Score: 10

5. Acceptance Score: 10

6. Longevity Score: 10

7. Punctuality Score: 05

8. Accuracy Score: 05

9. History Score: 05

10. Transport Score: 05

1 1 . Urgency Score: 05

12. Rapidity Score: 05

Total : 1 00

The following example shows desirable attributes for a staff

1 . Rating Score: 20 16.7

2. .Experience Score: 10 12.3

3. Appearance Score: 10 4.1

4. Proximity Score: 10 07.9

5. Acceptance Score: 10 5.0 6. Longevity Score: 10 02.3

7. Punctuality Score: 10 06.7

8. Accuracy Score: 10 08.1

9. History Score: 10 04.8

10. Transport Score: 05 00 (Either 05 or Zero)

1 1 . Urgency Score: 05 05 (Either 05 or Zero)

12. Rapidity Score: 05 04.2

Total : 1 00 69% Quality Score

[00213] Shifts will be polled to staff members in order of priority determined by their respective quality scores.

Peak Pricing

[00214] I n this implementation, Peak Pricing relates to a Peak Activity period, in which the number of shifts is large relative to the number of staff available to fill those shifts. Accordingly, Peak Pricing applies a multiple of the amount charged/ paid per Shift per Activity Level.

[00215] When a Customer makes a booking, the Quote provided by the system reflects Peak Pricing. I n one example, CRUVA offers the customer two options:

1 Price for no Peak Pricing - Normal Activity Levels; and

2. Peak Pricing at the applicable Activity level.

The Administrator is able to regulate and rename the Peak Pricing, with Admin-entered variables shown in bold below:

Mild Activity Level 1 - Peak Pricing - 0

Mild Activity Level 2 - Peak Pricing - 0

Mild Activity Level 3 - Peak Pricing - 0

Mild Activity Level 4 - Peak Pricing - 0

Peak Activity Level 1 - Peak Pricing - 1 .1

Peak Activity Level 2 - Peak Pricing - 1 .2

Peak Activity Level 3 - Peak Pricing - 1 .3

Peak Activity Level 4 - Peak Pricing - 1 .4

Peak Activity Level 5 - Peak Pricing - 1 .5

Set to 0 - Zero - to disable. [00216] I n one example, corresponding to that shown in Fig. 43, the CRUVA app displays a " Peak Booking Alert !" to the customer to forewarn them that it will be difficult to engage staff at the normal rates. The app then displays the following two options from which the customer can select :

Total $20345.50

Estimated 35% chance of filling Shifts

Peak Price 1 .4

Estimated 85% chance of filling all Shifts

Sociable Hours

[00217] I n this implementation, Sociable Hours are normal working hours during the day on weekdays. Non-Sociable Hours are hours outside of Sociable Hours. A Sociability Factor is the estimated amount Non-Sociable Hours will reduce Potential Staff Results.

[00218] I n one example, an Administrator adds Sociable Hours and a Sociability Factor in Administrator Login. CRUVA Calculates Non-Sociable Hours and sets a central NS Peak Time. The Administrator can edit/override the NS Peak Time. Shift Sociability Factor scales down from NS Peak Time until Sociable Hours start/end. Shift Sociability Factor is Admin Sociability Factor divided by the time between NS Peak and Sociable Hours Start/End multiplied by the time between NS Peak and Shift Start Time. Potential Staff Result multiples by Shift Sociability Factor to create a new Potential Staff Result (and corresponding Activity Level) .

[00219] I n one example:

Sociable Hours: Mon - Fri are 0700am - 1800pm.

NS Peak time is 0030am, the mid point between 1800pm and 0700am .

Administrator has set the NS Peak time as 0200am .

Administrator has set a Sociability Factor of 2.

For a Shift at 2300pm , Shift Sociability Factor is 0.75 (Sociable Hours end at 1800pm and Peak NS Time is 0200am, 8 hours difference. Shift Start Time is 2300pm and Peak NS Time is 0200am, 3 hours difference. Therefore, the Sociability Factor for this Shift is 2 ÷ 8 x 3 = 0.75) . Multiply the Potential Staff Result by the Shift Sociability Factor to create a new Potential Staff Result. For a Potential Staff Result of 50 (Peak Activity Level 3) multiplied by the Shift Sociability Factor of 0.75 makes a new Potential Staff Result of 37.5 (Peak Activity Level 4) .

[00220] Administrator Settings - Sociable Hours (Admin-entered variables in bold) Mon- Fri 0700 - 1800 - Sociability Factor - 2 - Non-Sociable Hours - 13 - NS Peak - 0030

Sat 0900 - 1 800 - Sociability Factor - 4 - Non-Sociable Hours - 15 - NS Peak - 01 30

Sun 1000 - 1 800 - Sociability Factor - 6 - Non-Sociable Hours - 16 - NS Peak - 0200

Pub Hols 1000 - 1 800 - Sociability Factor - 8 - Non-Sociable Hours - 16 - NS Peak - 0200

Set 0 - Zero - to disable.

[00221 ] Fig. 50a is a screenshot illustrating a graphical user interface (GUI ) 5000 for enabling a participant to edit times associated with a particular job. The GUI 5000 shows a subset of a calendar, such as a week or month, which may be defined by a system administrator or a participant. I n the example of Fig. 50a, the GUI 5000 shows a week in June, with hours associated with various jobs shown as shaded bars covering the relevant hours. The participant is able to confirm dates for a job and define one or more break periods and the length of such break periods. Labour hire personnel are able to select work hours corresponding to hours that they are available for work.

[00222] Many modern computing devices use touch screens. Fig. 50b illustrates how a user is able to edit job parameters shown in the GUI 5000 using one or more gestures. As shown in Fig. 50b, a user can move jobs from one day to another by swiping a job to the left or right. Further, a user can shorten or lengthen hours associated with a job by swiping one end of a job up or down or pinching opposing hours associated with a job. I n one arrangement, a user can apply default parameters to a job, such as hours and breaks, by using one or more predefined gestures. For example, double-tapping a weekday may define a new job with predefined hours, such as 9am to 5pm with a 1 hour lunch break. The user is then able to fine tune parameters associated with the job using one or more input devices, including a mouse, keypad, or touch screen gestures.

[00223] Fig. 50c is an interface 5010 of break hours associated with a particular job. I n this instance, a job has a first break defined between 12:00pm and 12:30pm and a second break defined between 6:00pm and 6: 15pm . For example, after a user selects a job date, that user selects work hours and break times. I n one example, the default work hours are 9:00am to 6:00pm . The user can change the actual work hours and associated breaks. The system updates based on the user input.

[00224] After a user creates a job, the user can preview the created job before the job goes live on the system . The user is also able to add further details to the job; the added details may impact the potential staff and cost. I n one arrangement, the user is able to: change attributes preference, add induction requirements, add qualifications; and add additional information. Fig. 50d is an interface 5020 illustrating a user interface for ordering attributes associated with a job, including mandatory fields and desirable fields. I n the example of Fig. 50d, the mandatory fields include rating, urgency, and transport and the desirable fields include experience, appearance, proximity, acceptance, longevity, punctuality, accuracy, history, and rapidity.

[00225] Fig. 51 a is an interface 5100 illustrating a tracking feature available in the supervisor CRUVA app. The tracking feature uses geolocation functionality from computing devices associated with labour hire personnel to monitor real time locations of those labour hire personnel. I n the example of Fig. 51 a, the interface 5100 includes a first map region 51 10 on which are plotted the locations of all staff associated with a nominated job. A second region provides information regarding the logged hours associated with the labour hire personnel. I n one arrangement, data associated with each labour hire personnel is coded, such as through font colour, shading, or the like, to indicate punctuality of that labour hire personnel. For example, red may indicate that a person is absent, orange may indicate that a person was later within a predefined time period of the stipulated start time associated with a job, and green may indicate that a person was on time.

[00226] While the interface 5100 included a first map region 51 10 plotting the

movements of all staff associated with a job, Fig. 51 b is an interface 5130 of a single staff tracking feature. The interface 5130 includes a map region 5135 for plotting the location and movement of a specified staff member. Thus, the map region 5135 tracks a single staff member. The interface 5130 optionally displays various information associated with that staff member, such as name, skills, address, ongoing job hours, break time(s) , location, and the like. The interface 5130 optionally provides functionality to enable a supervisor to contact the staff member, such as via instant message, SMS, MMS, telephone call, and the like. The interface 5130 further optionally includes functionality to enable the supervisor to approve one or more timesheets associated with that staff member.

[00227] Fig. 51 c is an interface 5140 for tracking completion of a staff task. An individual staff job completion can be tracked, edited, and approved. The interface 5140 optionally displays one or more of the staff name, skills, address, location map, job hours, break hours, and the like. One arrangement optionally colour codes break hours, with any over time highlighted. The interface 5140 includes communication functionality, such as messaging functionality, and the ability for a supervisor to approve timesheets, deductions, and other actions associated with a staff member.

[00228] Figs 52a and 52b illustrate creation of a job quote. After creating a job, a user can generate a quote for the job created. The Generate Quote button on the job preview Screen shown in Fig. 52a displays various prices for normal and peak hourly rates, along with an estimated chance of filling shifts. The chances are provided by the administrator based on data analytics. The user can choose any option that relates to the job details and the user can save a quote for the job to perform the booking, such as that shown in Fig. 52b. Before booking the user can select a supervisor and I nduction for staff if required.

I ndustrial Applicability

[00229] The arrangements described are applicable to the recruitment and labour hire industries, wherein labour hire personnel span all industries, including, but not limited to, entertainment, construction, mining, retail, health, education, information

technology (I T) , manufacturing, finance, agriculture, tourism , media, transport, legal, and logistics.

[00230] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

[00231 ] I n the context of this specification, the word "comprising" and its associated grammatical constructions mean "including principally but not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

[00232] As used throughout this specification, unless otherwise specified, the use of ordinal adjectives "first" , "second", "third" , "fourth" , etc. , to describe common or related objects, indicates that reference is being made to different instances of those common or related objects, and is not intended to imply that the objects so described must be provided or positioned in a given order or sequence, either temporally, spatially, in ranking, or in any other manner.

[00233] Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms.

Claims

We claim :

1 . A booking system comprising :

a server including :

a processor; and

receiving a booking request from a client , said booking request including booking information , wherein said booking information includes a booking location, booking time, number of staff, and required skill level;

transmitting a shift message to said first set of prospective staff members, wherein said shift message is based on said booking information ;

recording the staff members associated with the acceptance messages in said booking information .

2. The system according to claim 1 , wherein said set of criteria further includes at least one of proximity of staff member to the booking location , number of jobs worked by a staff member, staff rating, staff punctuality, time logging, response time, and partner associated with a staff member.

3. The system according to either one of claims 1 and 2, wherein said computer code instructions, when executed on the processor, perform the further method steps of :

determ ining activation of a Peak Activity period ; and

applying a price weighting to salaries of staff members during said Peak Activity period .

4. The system according to any one of claims 1 to 3, wherein said computer code instructions, when executed on the processor, perform the further method step of : applying a weighting to at least one attribute in said set of criteria, based on a predefined Sociable Hours period .

5. The system according to any one of claims 1 to 4, wherein said computer code instructions, when executed on the processor, perform the further method step of :

transmitting a shift confirmation message to said client , in response to said received acceptance message.

6. The system according to any one of claims 1 to 5, wherein said shift message is at least one of an SMS text message, email, push notification, or message displayed to a device or within a browser window or app accessed by the client.

7. The system according to any one of claims 1 to 6, wherein said system is adapted to send a pre-shift notification message to each staff member from which an acceptance message was received .

8. A method for booking personnel, comprising the steps of :

receiving a booking request from a customer, wherein the booking request includes booking information , said booking information including a booking location, booking time, number of staff , and required skill level;

transmitting an acceptance notification to said customer.

9. The method according to claim 8, further comprising the step of :

arranging payment to said staff members from which an acceptance message was received, after completion of the booking.

10. The method according to claim 9, wherein payment is made to a labour hire company associated with at least one staff member after receiving an invoice from said labour hire company.

1 1 . The method according to any one of claims 8 to 10, wherein said set of criteria further includes at least one of proximity of staff member to the booking location, number of jobs worked by a staff member, staff rating, staff punctuality, time logging, response time, partner associated with a staff member, appearance, on call, own transport, acceptance and rate.

12. The method according to any one of claims 8 to 1 1 , wherein said client adjusts weightings to one or more attributes of said set of criteria.

13. The method according to any one of claims 8 to 1 1 , further comprising the step of : applying a weighting to a salary associated with a booking request, during a peak activity period.

14. The method according to any one of claims 8 to 13, further comprising the step of : applying a weighting to a salary associated with a booking request, during a non-sociable hours period.