Reschedule & cancel policies
Booking policies determine whether a customer can cancel or reschedule, when the cutoff applies, and whether your team must review the request. Create them under Bookings → Setup → Booking policies.
An organization-default policy is the fallback. A service-specific policy overrides it for that service.
Choose a mode for each action
Cancellation and rescheduling are configured separately:
| Mode | Customer experience |
|---|---|
| Customer allowed | An eligible customer action is applied immediately after policy and capacity checks. |
| Request only | The customer submits a request for merchant review. |
| Merchant only | Customer self-service is unavailable; your team handles the change. |
Set each cutoff in minutes before the booking starts. Inside the cutoff, the customer action is unavailable even if the booking otherwise qualifies.
The customer can reach these actions from their signed-in account or a scoped booking-management link. The API returns the action's current availability and reason; the storefront should display that result rather than recreating the policy.
Review customer requests
A pending cancellation or reschedule request appears on the booking detail page. You can:
- approve a cancellation, which releases capacity;
- approve a reschedule, which rechecks and claims the requested period before changing the booking; or
- decline the request without changing the booking.
Only one pending booking-change request can be active at a time.
Refund posture is not an automatic refund
The policy records your intended refund posture: full, partial, none, or manual. At launch, booking deposits and refunds remain manual Sales/payment decisions. Approving a cancellation does not move money automatically.
Review the linked Sales record, then issue or record the exact refund there.
Merchant exceptions
The policy also controls two high-risk merchant paths:
- Date-policy override can either disallow overrides or require the booking operation permission for changes outside hours, blackouts, lead time, or maximum advance.
- Controlled shortage is off by default. When enabled, it still requires both Bookings operations and Bookings override, an audited reason, and follow-up resolution. Exact serialized-unit conflicts cannot be overridden.
Use ordinary strict capacity checks whenever possible. A controlled shortage keeps the unresolved capacity visible; it does not make the missing resource exist.