Rescheduling

When a customer needs to change their booking date or time, Resytech makes rescheduling safe and easy with built-in conflict detection.

Reschedule Modes

The Reschedule tab offers four modes: Automatic (time slot reschedule), Manual, Extension, and Reduction. The first two move the booking; the last two change its length in place.

Activity Voucher bookings

Bookings funded by Activity Vouchers replace these modes with a single reviewed date/time change. Select an available departure and review the existing voucher coverage, prepaid amount and remaining balance before confirming. The purchased voucher terms, including the valid season, weekdays and excluded dates, are rechecked against the new departure. Products, quantities, duration, add-ons, prices and existing payments stay unchanged. This action does not collect a payment or issue a refund.

Only future Confirmed bookings that have not checked in can be moved this way. Restricted vouchers, unavailable inventory, unsupported booking types and invalid scheduling settings need operator review. Product or duration changes are not available; manual rescheduling, extension, reduction and conflict overrides are not offered for voucher bookings. Customers cannot reschedule a voucher booking from the self-service portal.

If the result cannot be confirmed, use the saved-request retry. Resytech resolves the original operation and refreshes the current booking before allowing further edits. Retrying an older reschedule does not move the booking back after a later change.

Time Slot Reschedule

The standard reschedule flow uses available time slots:

1. Open the booking you want to reschedule
2. Navigate to the Reschedule tab
3. Select the new date from the reschedule calendar
4. Choose from available time slots for that date
5. Resytech checks for conflicts automatically
6. Review the changes and confirm

This mode respects the activity's scheduling rules and only offers time slots that are configured and available.

Manual Reschedule

For special situations, you can manually set the exact date and time:

Manual reschedule is useful for bookings that fall outside normal scheduling rules, such as private tours or custom arrangements.

Extension

The Extension mode adds time to the end of a booking without moving its start. Pick a duration from the activity's tiers (chips show the actual price, including any pricing modifiers active during the extension window) or enter a custom number of minutes, then choose how to price it:

For example, with tiers of 60 minutes at $140 and 90 minutes at $210, extending a 60-minute booking by 30 minutes charges $70 under Tier difference (bringing the total to the 90-minute price), while Current rate would charge the standalone 30-minute tier price.

Before committing, use Preview Extension to see the new end time, the extension charge, and the new balance. The preview also checks the extension window for conflicts:

• Inventory conflicts listing every equipment line that would be overcommitted. Only confirmed and pending bookings count against inventory (draft carts hold nothing), and units reserved by a partial equipment blackout are deducted from capacity
• Schedule conflicts covering blackout periods, facilitator double-booking, and the activity's session participant limit

These warnings are advisory: the extension still applies if you confirm, and you resolve the conflict externally. Each extension is recorded as its own line item, so stacked extensions stay auditable, and totals, fees, and taxes are recalculated on the new subtotal. Payment is not collected by the extension itself; the added charge lands on the booking balance for the normal payment flow.

Committing an extension publishes a Booking Extended event, so you can automate follow-ups with a workflow using the booking_extended trigger (variables: minutes, extensionTotal, extendedBy) or subscribe to it via webhooks.

Reduction

The Reduction mode trims time off the end of a booking. It mirrors the extension flow: choose the minutes to remove and the credit basis, preview, then confirm. The removed time is recorded as a negative line item and totals are recalculated.

Reschedule Options

Both reschedule modes support the following options:

Conflict Detection

During rescheduling, Resytech runs a conflict check against the new date and time. Each conflict returned includes:

• Conflict type — the category of conflict (equipment, facilitator, capacity, blackout)
• Conflicting booking — confirmation code, customer name, and time of the overlapping booking
• Activity — the activity involved in the conflict

Specific conflict types:

• Equipment conflicts — the equipment is already booked at the new time
• Facilitator conflicts — the assigned facilitator is unavailable at the new time
• Capacity limits — the new time slot has reached its participant capacity
• Blackout periods — the new date is blocked by an activity or location blackout

If conflicts are found, they are displayed before you confirm. You can choose a different time, resolve the conflict, or use Force reschedule in manual mode to proceed anyway.

The conflict check also reports a canProceed flag — if all conflicts are advisory (warnings rather than hard blocks), you can proceed despite them.

Time slot (automatic) reschedules also check the assigned facilitators. If a facilitator is already booked on the new window, the reschedule is refused with the conflicting booking's confirmation code. Reassign the facilitator first, use a manual reschedule with Force reschedule, or send forceReschedule: true on the API request to proceed anyway.

The following guarantees apply to time slot reschedules:

• A booking with a custom duration keeps its full length. A three-day rental moved to a new start date stays a three-day rental; only the start moves.
• Time-extending add-ons carry their sold extra minutes to the new departure without adding them twice. Rescheduling cannot add, remove, or change the quantity of these add-ons.
• A per-person booking is repriced for its recorded party size, so a four-person booking is quoted (and refunded or charged) for four people, not one.

Pricing Recalculation

When rescheduling, pricing behavior depends on the Skip pricing recalculation toggle:

• Recalculate pricing (default) — the booking total is recalculated based on the new date's pricing rules. This accounts for seasonal rates, weekend pricing, time-of-day modifiers, and any other pricing logic. The reschedule event records the old total, new total, and price difference.
• Keep original pricing — the booking total stays the same regardless of the new date. Useful when you want to honor the original price as a courtesy.

If auto-refund is enabled and the new total is lower than the original, the difference is refunded automatically to the customer's card payments, starting with the most recent and splitting across earlier payments if needed. Two safeguards apply:

• The refund never exceeds the credit actually on the booking. If the customer still owed a balance, the price decrease is applied to that balance first and only the remaining overpayment (if any) is refunded.
• If part of the refund cannot be processed automatically (for example, the original payments have already been partially refunded), the remainder is flagged for a manual refund.

Customer Self-Service Rescheduling

If enabled in your customer booking management settings, customers can reschedule their own bookings through the customer-facing booking management portal. Self-service rescheduling respects the following settings:

Notifications

After rescheduling, you can optionally send the customer a notification (email or SMS) with the updated booking details. This uses your configured communication templates.

Audit Trail

All rescheduling actions are logged in the booking's event log as a booking.rescheduled event. The log captures:

• Original date and time — the old start and end times
• New date and time — the updated start and end times
• Old total and new total — pricing before and after the reschedule
• Price difference — the delta between old and new totals
• Auto refunded — whether an automatic refund was requested for this reschedule
• Skipped pricing — whether pricing recalculation was skipped
• Rescheduled by — the user ID of the staff member who performed the reschedule
• Notes — any notes provided during the reschedule

When a price decrease triggers an automatic refund attempt, a separate booking.reschedule_refund event records the outcome: the refund target, the amount actually refunded, the payments it was refunded to, and the reason if any portion could not be refunded automatically.

Extensions and reductions are logged as booking.extended and booking.reduced events, capturing the minutes changed, the pricing mode, the before and after end times, totals and balance, and any inventory or schedule conflicts detected for the changed window.

Related How-To Guides

• Reschedule a Booking
• Check Availability
• Use the Booking Calendar