Booking HandbookKeep every part of a multi-date booking.
First checks
- List every item
Show the date, time, service, place, staff, resources, price, and order for each selection.
- Check each item
One available appointment must not hide a conflict elsewhere in the request.
- Choose a group rule
Decide whether all, some, or a minimum useful number of selections must succeed.
- Give one clear receipt
Confirm, reject, or return each item for recovery without making the customer guess.
What should happen when only part of the request is available?
Name each date or service, list the unavailable item numbers, set the minimum useful result, and choose the confirmation policy. The checker returns an itemized outcome before any real booking is made.
Resolve the missing items first
Keep the request unconfirmed while 2 items get a replacement time, service, staff member, or explicit removal.
- Total items
- 5
- Confirmed now
- 0
- Ready
- 3
- Unavailable
- 2
This planning aid does not search calendars, calculate availability, reserve staff or resources, charge money, create bookings, send messages, or prove product behavior.
A request is not complete until every selected item has an outcome.
A customer may want a consultation on Monday, treatment on Wednesday, and a review on Friday. If Wednesday is unavailable, the system needs a declared rule: confirm the other two, reject everything, or hold the request while an alternative is chosen.
Safe multi-booking = itemized selections + per-item availability + group confirmation rule + linked recovery
A five-part request has conflicts on items 2 and 4. The customer should see which items are ready, what remains unresolved, and whether anything has actually been reserved or charged.
Follow the complete multiple-booking workflow
Some customers choose several unrelated dates, repeat the same service at irregular times, or assemble different services into one visit. These are not recurring rules: every requested item has its own service, availability, dependencies, and later change history.
Keep one customer request together while making every appointment independently understandable.
- Capture the exact selections
Create a visible line for every requested service and date instead of compressing the request into one vague booking note.
- Record order and dependencies
Identify whether items are independent, must happen in sequence, share a location, or require time to pass between services.
- Validate each item
Check staff, resources, place, buffers, travel, policy, price, entitlement, payment timing, and external calendars per selection.
- Hold available items briefly
Prevent a final slot or resource from disappearing while the remaining checks run, then expire unused holds predictably.
- Apply the confirmation rule
Require every item, confirm the available subset above a useful minimum, or resolve all conflicts before confirming anything.
- Return an itemized outcome
Give each item a stable identity and explicit state, plus one grouped receipt and a direct recovery path for unresolved items.
Compare the five request models
Independent appointments
Example: a customer chooses three separate consultations on unrelated dates.
- Rule
- Each appointment can succeed, change, or cancel independently while remaining visible under one request.
- Watch for
- A failure on one date should not silently delete or block the others unless the customer chose an all-or-nothing rule.
Ordered service itinerary
Example: consultation, treatment, and review must happen in that order.
- Rule
- Store the sequence and recheck downstream times when an earlier service moves or runs longer.
- Watch for
- Independent availability checks can still produce an impossible day if travel, buffers, or service order are ignored.
Irregular multi-date request
Example: the same service is selected for Monday, Thursday, and the following Tuesday.
- Rule
- Treat the chosen dates as a list, not a weekly rule that may regenerate or overwrite them.
- Watch for
- Calling every collection a series can apply the wrong edit scope and create dates the customer never selected.
Dependent booking chain
Example: an assessment must be completed before a later procedure can remain confirmed.
- Rule
- Record the dependency and define what happens downstream when a prerequisite is moved, cancelled, or incomplete.
- Watch for
- A later appointment can remain apparently valid after the event that made it eligible disappears.
Shared checkout, separate records
Example: several appointments are reviewed and paid for in one customer checkout.
- Rule
- Keep one order or receipt while preserving item-level booking, price, payment, message, and refund states.
- Watch for
- One total without item allocation makes partial cancellation, refund, credit, tax, and reconciliation difficult to explain.
Recheck changes and demo failures
One item changes
Recheck that item and every declared dependencyPreserve the unaffected appointments while recalculating order, buffers, travel, staff, resources, price, and customer promises where necessary.
Shared staff or resources change
Find every linked conflictA staff absence, room closure, or equipment failure should create visible alternatives rather than silently splitting the request.
Price or credit changes
Allocate value per itemShow which appointment holds money or value, what the new total is, and whether the customer owes, receives, or retains anything.
One item or the whole request cancels
Ask for scope before releasing anythingCancel only the chosen records, preserve the rest, release their holds, and explain item-level money, credit, and message consequences.
Confirmation or payment partly fails
Do not leave an invisible half-bookingReconcile every hold, booking, charge, calendar event, and notification, then present one recoverable result to the customer and operator.
Location, time zone, or order changes
Rebuild the feasible itineraryRecheck chronological order, local display times, travel, opening hours, and dependencies before claiming the remaining plan still works.
The checkout hides item states
A single success message appears even though one or more selected dates or services were never reserved.
Partial availability has no policy
The software sometimes books a subset and sometimes blocks everything without a customer-visible business rule.
One edit breaks the chain
Moving an early service leaves later services, travel, staff, rooms, or eligibility unchanged even when the itinerary is no longer possible.
Money exists only as one total
The system cannot explain the charge, refund, credit, tax, or cancellation consequence of one item in the request.
Recovery starts from zero
When one item fails, the customer must rebuild every available selection instead of fixing only the unresolved part.
Force two conflicts and compare all three confirmation policies.
A cart, multi-booking, or itinerary label proves little. Give every shortlisted product the same mixed request and inspect what the customer and operator see before and after partial failure.
- Create five individually selected appointments or services, make items 2 and 4 unavailable, and require at least three useful items.
- Test confirm-available, require-all, and resolve-first behavior while recording holds, bookings, prices, payments, calendars, and messages per item.
- Move one confirmed item, cancel another, and fail one payment or notification; confirm that unaffected items survive and recovery stays itemized.