Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
MCRactive, Westminster City Council, and others from #120.
As a Customer of Everyone Active, I want to use a Broker such as MCRactive to book onto a waitlist, either as a guest or via my membership (if authenticated via #120).
Why is this needed?
The current specification does not include any provision for waitlists, except for an example extension that suggests using a separate booking mechanism.
This proposal recommends that waiting list booking make use of the Approval flow, with only minor additions required to facilitate this.
This puts the Booking System in control of the waitlist process, which allows implementation of a range of different waitlist strategies (allocate next in list, first-to-respond, etc). It also allows a Broker to "auto-accept" a waitlist place, assuming they have already authorised the payment.
As will all Open Booking API features, use of this feature will require contractual agreement between the Seller and the Broker, so the Seller always remains in complete control of this.
Additional specification updates required:
From Debbie at Everyone Active:
Currently the waiting lists within Everyone Active don't accept payments before the booking. Also within Gladstone, at the point when someone books on a waiting list, there's no price against the account. Additionally, Gladstone are currently redeveloping their waiting list product with Gladstone 360, and so likely a feature like this will not be available quickly (unless it was simply leveraging Gladstone's existing e-mail notification approach - though this would require direct communication outside of the Broker).
E-mails are currently sent every hour to all waiting list customers for classes on the same day, or 4 times a day for classes in the future, which notifies waitlist customers that there's a space available.The current strategy in use at Everyone Active is first-to-respond a.k.a. fastest finger first. When the customer clicks, the sale is raised.
Waiting lists are a massive issue: 54% of cancellations happen in the last 4 hours before the class is starting, so at that point it becomes a free-for-all.
There's a risk that any third-party waiting list approach will conflict with what Everyone Active are already doing, and they work they are doing to optimise the utilisation. If there's a third party running their own process, the customer using the third party app might have an advantage over anyone using Gladstone's own waiting list solution. E.g. it might be that a third party app notifies a customer more immediately than someone booking direct.
For this viable it would need to follow exactly the same pattern as existing Everyone Active customers.
85% of group exercise classes are currently booking through the app, so push notifications are sometimes better, but again it's consistency between Everyone Active's customers.
In summary: Although achieving equality between customers via brokers, and customers coming direct might be difficult from within the Gladstone software (as will pricing up-front before a custom is added to the waiting list), as long as the opportunities to join the waiting list are presented at the same time across both brokers and direct customers, this would be workable.
Also "auto-accept" is problematic, as Everyone Active use the first-to-respond strategy for direct customers, so "auto-accept" customers would be at an advantage to third party app users.