Scheduling rules, deposits and no-show fees

[nickevansuk]

Proposer

imin / mapping to Google Reserve

Use Case

The following use cases from Google Reserve: which apply to both Event and FacilityUse.

Restrictions for when a slot can be booked and cancelled:

• The duration from when the last booking can be made to when the availability slot starts.
• The duration from when the last booking can be made to when the availability slot ends.
• The minimum advance notice required to cancel a booked appointment online.

An Admission Policy can be specified for whether customers need to arrive in time for the startDate, or can turn up later:

• Customers are required to be present at the start time of the availability slot ("A fitness class from 6pm to 8pm.")
• Customers can arrive at any time between the start and end time of the availability slot to use this booking. ("An afternoon admission to an amusement park that can be used from 12pm to 9pm.")

Fees incurred for no-show (can be specified at both Event/FacilityUse and Offer level):

• A fee that a user may be charged if they have made a booking but do not show up (specified either as a fixed fee or a per-person fee)

Details about a deposit that the user is required to be charged. Note this is framed as a conditionally refundable deposit, rather than a cancellation charge (can be specified at both Event/FacilityUse and Offer level):

• The amount of the deposit (specified either as a fixed amount or a per-person amount)
• The minimum advance cancellation for the deposit to be refunded

Capturing of credit card details as part of booking:

• An property to force the collection of credit card details, regardless of whether they are necessary to complete the booking.
• If not forcibly required, credit card details are only captured if a deposit, no-show fee, or prepayment is set.

Schema.org properties

https://schema.org/advanceBookingRequirement covers the duration from when the last booking can be made to when the availability slot starts, however it is not of type Duration.

Otherwise this looks to require a number of new properties, and hence requires a broad discussion with a number of system providers.

[peter-dolkens]

https://schema.org/advanceBookingRequirement covers the duration from when the last booking can be made to when the availability slot starts, however it is not of type Duration.

I think QuantativeValue is actually a better type than Duration

This allows us to specify "bookings must be made 24 hours in advance. bookings cannot be made more than 2 weeks in advance"

A Duration would only allow us to specify "bookings must be made 24 hours in advance"

I know Clubspark at least operates with both restrictions in place.

As such, I think it's a good fit for advanceBookingRequirement though personally I would have named it advanceBookingWindow or advanceBookingRestrictions - I guess it's too late for that now.

Cancellation and Refund windows could use a similar approach, though it may become more complicated due to the potential need to incorporate the booking duration into the value.

Examples:

• You can cancel up to 24 hours prior to your booking
• You can cancel at any time before the end of your booking
• You can apply for refund up to 24 hours after your booking
• You can cancel up to 15 minutes after the start of your session

If we don't support the last scenario, we could explicitly define positive and negative values to be post and pre-booking respectively. If we wish to support times within the booking however, we will need to evaluate alternate options.