Waitlist bookings

[nickevansuk]

Proposer

MCRactive, Westminster City Council, and others from https://github.com/openactive/open-booking-api/issues/120.

Use Case

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 https://github.com/openactive/open-booking-api/issues/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.

Proposal

This proposal recommends that waiting list booking make use of the Approval flow, with only minor additions required to facilitate this.

If waitlistAvailable: true and remainingAttendeeCapacity is 0 on an Event the Broker must follow Approval flow as per the existing specification.

As OrderProposals are atomic and are approved in an all-or-nothing fashion, a Broker would need to split multiple waitlist OrderItem's into multiple Orders if they desire for them to be approved independently. For example if 2 friends want to be waitlisted together, they submit a single OrderProposal, and only get notified if 2 spaces become available. If non-waitlisted items are bundled with waitlisted OrderItems, no long-term lease is applied, and the OrderProposal is only successful if there is still space in the other non-waitlisted OrderItems when the Customer confirms their waitlist space.

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:

• A property waitlistAvailable of type Boolean added to schema:Event.
• An additional SellerAcceptedPendingCustomerConfirmation state is required, that does not affect the status flow https://www.openactive.io/open-booking-api/#orderproposal-statuses, but requires confirmation of customer at that SellerAccepted stage.
• An additional arrow on 5.5.5 OrderProposal statuses from SellerAccepted back to AwaitingSellerConfirmation so that the leasing invariant still holds (i.e. anything approved must always be bookable).
• Clarify the use of orderSellerNote to be updated at each stage of the waitlist (including the very beginning of the flow), for example:
  1. orderSellerNote at AwaitingSellerConfirmation: "You are currently on the waiting list. We’ll notify you if a space becomes available." initially
  2. orderSellerNote at SellerAcceptedPendingCustomerConfirmation: “A space is available first-come-first-served, please approve your space soon”.
  3. orderSellerNote at AwaitingSellerConfirmation: "You are currently on the waiting list. We’ll notify you if a space becomes available." if the space got taken.

[nickevansuk]

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 customer 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.