Dynamic Resource Blocking
Purpose: Dynamic Resource Blocking (DRB) was developed as a workaround for a major limitation of virtual rostering, namely that given Y overlapping games but only X available staff, there is no way to make all Y games available and then automatically block the remainder once X games have been booked, unless X = 1.
Function: DRB allows you to choose staffing levels on a slot-by-slot basis from within the booking system. By assigning a game to a resource that ends in the identifier “DRB#” — where “#” is a single digit 1-9 — you will “tell” the app how many staff you have available during a particular time period. When those staff are claimed at any given instant, all other bookings that overlap that instant are then blocked.
Mechanism: The app “listens” for information on new, updated, and deleted bookings, and when an event occurs that might trigger the DRB threshold at a particular time, it analyzes the time period around that event to determine whether any new blocks need to be placed. To work around limitations in the information the booking system provides about bookings in the past, the app also maintains a rolling 6-hour database of your booked DRB games; this ensures that bookings that have already begun are factored into calculations on whether upcoming games might need to be blocked.
DRB does not work in reverse. If you delete or move a booking, freeing up new staff for a time slot with DRB blocks in it, you may want to un-block those games so that customers can book them again.
DRB does not attempt to interpret your blocks. The app has no way of knowing why you blocked a game, so if a game is fully blocked (0 bookings and 0 availability), it will be ignored. For example, let’s say you have 4 games scheduled for 12:00, and you’ve chosen a DRB number of 2 for all of those games but blocked one of them, leaving 3 games remaining. DRB will trigger once two of those games have been booked, blocking the third and final remaining game.
DRB does not compensate for user error. If you’ve been inconsistent with how many staff you are “telling” the app are available at a particular time, DRB can’t fix that. E.g., if you have three games available at 12:00, and you’ve assigned two of them a DRB number of 2 while the third is assigned a DRB number of 1, the app will treat each of these games according to the DRB number assigned to it: any booking in either of the first two games will block the third game, but a booking in the third game will not by itself block either of the first two games.
DRB operates under three major assumptions: 1) no two instances of the same game start at the same time; 2) game “start” and “end” times correspond directly to staff utilization, and 3) no game is longer than 3 hours. If these assumptions don’t hold for you, please contact me (e-mail in the beta signup form below).
DRB is fairly “resource”-intensive. I mean that in the sense of the booking system’s definition of resources — for DRB to work, you will need to assign one resource per anticipated staffing level per game. I realize that this might seem like a resource hog given that the “Standard” plan that many of us are on only provides a maximum of 20 resources, and when resources are deleted, so too is information about prior bookings. However, using resources has the major advantage of allowing you to change DRB staffing levels dynamically from within the booking system. If you are interested in trying DRB but the level of resource utilization is untenable for you, I recommend that you do still sign up for the beta, and contact me via the e-mail provided in the Google form — I’m interested in your setup and I may be able to provide some tips on how to cut down on extraneous resources. (We recently did this for our own account. There will never be a better time for a spring cleaning!)
DRB only “hears” about changes in bookings, not changes in event details. What this means is that if you change the start time or resource of a scheduled game without changing anything about the bookings inside it, DRB is not guaranteed to find out about it sooner than 3 hours from now. If you’re changing a game that already has bookings in it, you can “ping” the app by changing any detail about any booking in the game — e.g., create a promo code for 0% called “Absolutely Nothing” and change the booking to use that promo code. (Uncheck “notify customer,” of course.) If you’re changing the details of an event with no bookings, you shouldn’t need to do anything, since DRB doesn’t need to know about it until it becomes relevant.
Beware meddling with the past! Actually, you can do whatever you want with bookings for games that have already started, but because of the booking system’s limitations, changing a past event’s information will unfortunately not affect the app’s DRB calculations for any upcoming games it might overlap with.
You get what you pay for! I’ve done my best to make this tool robust and reliable, and we’ve been using it at our three venues for the past year, but I’m not a professional programmer. I’m providing this tool with no warrantee express or implied, etc.; use at your own risk!
Very occasionally, this workaround will fail to create blocks quickly enough. This is due to the nature of the API: the booking system’s notifications of new/updated bookings come to our server in the form of asynchronous webhooks, and the delay between when a booking is actually made and when the API tells us about it can vary greatly, between 3 seconds and 5 minutes. This means that occasionally (in our experience, about 1% of the time), the DRB workaround will fail for one of two reasons:
A) A customer booked multiple games quickly in succession and surpassed the DRB threshold before DRB had a chance to create its blocks.
B) A customer starts to book Game #1, then changes their mind and books Game #2. DRB sees that Game #1 is already blocked (temporary block for “customer booking in process”), so it does not take any action even if it ordinarily would/should.