In the 'Lock-in & Repetition' settings choose when your user will be able to cancel/change their bookings.
When these settings are changed the new policy will only apply to new bookings created from that point in time. Skedda won't change the lock-in policy of existing bookings. This is intentional because Skedda communicates this lock-in information to the booking holder e.g. the confirmation email when the booking is made, so they would expect this to remain the same.
The end-early and cancellation lock-in policy does not apply to System users. These users can create/cancel anyone's bookings at any time.
Open: change/cancel up to a certain number of hours after the booking ends, and end early
This is the first and most liberal option. If you select this option, regular users can self-serve edit, or cancel their bookings up to a certain number of hours after the booking ends (including any time leading up to this point), and also choose to end them whilst they're happening (which helps to free up space for others if they leave early).
The end-early option shortens the booking by changing its end time to the current venue time (rounded up based on your venue's time granularity).
You're able to specify the number of hours after a booking's end time a regular user can self-serve change or cancel their booking. For example, if you enter '24', users can change or cancel their bookings up to 24 hours after they end, but cannot change or cancel them after that point in time.
Bear in mind that the openness of this rule will allow your users to reset their quota limits if they cancel their booking even after they've used the space! You should consider the likelihood of this occurrence for your user base before making use of this rule.
Flexible: change/cancel anytime before and end early
The second option means that regular users can self-serve edit, or cancel their bookings at any time before they begin, and also can choose to end them whilst they're happening (which helps to free up space for others if they leave early).
The end-early option shortens the booking by changing its end time to the current venue time (rounded up based on your venue's time granularity).
If a booking with a non-zero price is ended early by its holder, the price of the booking remains unchanged. If the venue has notifications enabled, the venue email address is notified of end-early actions, so a System user can adjust pricing at this point if required.
Moderate: change/cancel only before the booking starts
The third option allows Regular users to edit or cancel their bookings any time before they begin, but they can't do change them after that (i.e. can't end early).
This allows for last-minute cancellations and changes.
Strict: change/cancel a certain amount of time before the booking starts
The fourth and final option allows you to specify the time until when Regular users can edit or cancel their bookings. For example, if you enter '24', users can change or cancel their bookings up to 24 hours before they begin, but cannot cancel them after that point in time.
Please note that users will be informed of the lock-in and cancellation policy when they create the booking, and also in the booking confirmation email.
For example, if you set the lock-in margin to 5 hours, then the holder of a booking for Wednesday at 6 pm can self-service cancel it up to 1 pm on the same day at the latest.
Example of the cancellation and change info in the booking window:
Example of the edit and cancellation prompt for users in the day view:
Lock-in policy and payments
When online payments are enabled, the cancellation/lock-in policy determines when you can charge bookings in some cases.
Book now, Pay later Approach
With the BNPL approach, a booking cannot be charged until its holder is no longer able to edit or cancel it. In other words, the holder is free to cancel or change their booking online, up until the cancellation/lock-in time, without having to worry about being charged.
Upfront Approach
With the Upfront approach, payment is taken upfront (unless exempt from online payments) and users cannot cancel or change their booking online, even if you have set a cancellation lock-in. However, if a System user creates a booking on behalf of a user, the payment is not taken upfront and the booking can again only be charged after the holder is not able to cancel.
Here's an example of a chargeable booking with a cancellation lock-in policy:
A booking in the Paid state can never be self-service changed or canceled by its holder. A System user can however change or cancel the booking after attending to the question of payment (e.g. processing a refund for the cancellation case).
Lock-in policy and repeat bookings
If you have bookings that were created with the repeat function, and you've set a specific lock-in window (let's say, users are locked in 24 hours before booking starts), then each occurrence in a repeat series will be locked in according to your lock-in policy.
So, if there's a weekly booking that repeats once a week for 4 weeks, and the first occurrence of the series is inside your 24-hour lock-in, the user will not be able to cancel that first occurrence but will be allowed to cancel any other occurrences in the series. This is what it might look like from their List view:
This is if they haven't paid online using the Upfront payment method, which would have locked in the entire series.