The Pooled availability algorithm

The logic behind our Pooled availability algorithm is based on the longest idle time concept
 
The logic behind the longest idle time is:
  • To track the amount of time that has passed, for each Booking page, since a booking was last created. Note: The meeting time does not matter.
  • To assign the next booking to the Booking page with the longest idle time (i.e. the Booking page for which the the longest time has passed since a booking was last made).
  • If there are a number of Booking pages with the same idle time, then we will randomly pick one.

Booking are therefore assigned according to this logic:
  1. Firstly, all Booking pages with availability at the Customer's select time slot are selected.
  2. Secondly, within the selected pool (outlined in step 1), Booking pages with the highest priority are picked (if applicable).
  3. Finally, the booking is assigned to the Booking page with the longest idle time.
 
Fundamental assumptions: 
  • The idle time is tracked per Master page AND per Event type combination. This means that if a User receives bookings from more than one Master page, he will have two separate idle time counts. Also, if a user receives bookings from more than one Event type in a single Master page, he will have two separate counts.
  • The idle time is not considered if a Booking page has been deleted, disabled or has connection errors.
  • New Booking pages added to a Master page set up (as soon as save is pressed) are considered to have the longest idle time. Therefore, an idle time of zero (i.e. no bookings created yet) is considered as the longest idle time. 

Rate this article