Booking

Problem Context

• The user is reserving a provider-defined appointment, service, room, class, seat, table, equipment, consultation, visit, or pickup window.
• The booking may require service selection, staff or resource selection, location, duration, date, slot, timezone, party size, customer identity, contact details, intake questions, consent, terms, deposit, prepayment, or cancellation policy.
• Availability can depend on business hours, staff calendars, resource capacity, buffers, minimum notice, lead time, service duration, party size, checked calendars, payment status, and concurrent users.
• Confirmation can create a held slot, calendar event, receipt, email or text notification, cancellation link, reschedule link, waitlist entry, or provider-side queue item.
• Booking errors can have external consequences such as double-booked staff, over-capacity classes, unreleased canceled slots, payment without confirmation, or no-show disputes.

Selection Rules

• Choose booking when users reserve an offered appointment, service, class, room, seat, resource, table, or visit from provider-defined availability.
• Use scheduling when the organizer is coordinating people, calendars, recurrence, attendees, and invitations rather than accepting a customer reservation.
• Use checkout when the main commitment is purchase completion; booking may include payment only to hold or confirm the selected appointment, class, or resource.
• Use date picker, time picker, or date range picker as sub-controls only after booking-specific service, capacity, availability, and policy rules are handled.
• Use payment collection inside booking when a deposit, no-show fee, prepaid service, or paid appointment is required before confirmation.
• Use confirmation page after the booking is committed, not as a substitute for slot validation, intake, verification, or payment.
• Expose service, provider or resource, location, duration, timezone, party size, capacity, price, policy, intake requirements, and confirmation delivery before commit.
• Recheck slot availability, capacity, provider/resource state, payment result, and email verification immediately before confirming the booking.
• Show sold-out, unavailable, closed, full, stale, waitlist, email verification, payment required, payment failed, canceled, rescheduled, and released-slot states.
• Keep cancel and reschedule paths tied to the original reference so customer notifications, provider calendars, payments, and released availability stay synchronized.

Required States

• Service or appointment type selection state.
• Provider, staff, resource, room, seat, or location selection state.
• Available date and slot list state with duration and timezone.
• Unavailable, closed, blocked, sold-out, or capacity-full state.
• Party size, attendee count, or quantity state.
• Customer contact and identity state.
• Required intake questions, consent, terms, or policy acceptance state.
• Email verification or identity verification state when required.
• Payment, deposit, or card authorization state when required.
• Temporary hold or pending confirmation state while availability is rechecked.
• Stale slot or slot taken state with alternatives.
• Confirmed booking state with reference, calendar option, notification delivery, and next steps.
• Cancel booking state that releases the slot and explains refund or policy effects.
• Reschedule booking state that preserves customer details and policy context.
• Waitlist or notify-me state when capacity is full.

Interaction Contract

• Changing service, staff, resource, party size, date, timezone, location, or duration recomputes available slots before confirmation.
• A selected slot is not treated as confirmed until required intake, policy acceptance, verification, and payment checks have succeeded.
• The final action names the booking consequence, such as Book appointment, Reserve table, Join class, or Confirm reservation.
• Availability is rechecked at commit and stale slots return users to equivalent alternatives without clearing safe customer details.
• Payment, deposit, and refund terms are shown before payment and remain tied to the booking reference after confirmation.
• Canceling or rescheduling updates provider calendars, customer notifications, capacity counts, waitlist state, and released availability consistently.
• Confirmation includes reference, service, time, timezone, location or meeting mode, provider/resource, customer details summary, policy, and manage-booking links.

Implementation Checklist

• Define booking ownership for service catalog, staff/resource calendars, capacity, business hours, buffers, lead time, party size, intake fields, policy, verification, payment, confirmation, cancellation, reschedule, and waitlist.
• Build slot availability from canonical booking services rather than browser-only filtering, including capacity, staff/resource availability, buffers, minimum notice, closed periods, and concurrent holds.
• Expose service, duration, price, location, staff/resource, timezone, available slots, capacity, customer contact, intake, terms, payment, and confirmation action with validation and state text.
• Implement temporary slot hold, stale-slot recheck, sold-out recovery, alternate slot suggestions, waitlist, and release behavior after cancel or timeout.
• Support email verification, payment authorization, deposit, cancellation policy, refund instructions, confirmation email or SMS, calendar attachment, and manage-booking links when required.
• Preserve safe customer and intake details across slot taken, payment failure, verification failure, browser Back, refresh, and reschedule while redacting payment secrets.
• Test sold-out capacity, staff unavailable, closed hours, timezone change, party-size limit, stale slot, payment decline, verification failure, cancellation, refund policy, reschedule, waitlist, mobile, keyboard, and screen reader status updates.

Common Generated-UI Mistakes

• Treating booking as only a date picker and time picker.
• Showing slots without service duration, staff/resource, timezone, price, or capacity context.
• Taking payment before proving the selected slot can be held.
• Confirming a booking before required intake, consent, email verification, or payment completes.
• Losing customer details when a slot becomes stale or payment fails.
• Hiding cancellation, refund, no-show, or reschedule policy until after booking.
• Letting canceled bookings keep the provider calendar blocked or fail to notify the customer.
• Using the customer's local timezone for an in-person venue booking without showing venue time.

Critique Questions

• What service, staff, resource, room, seat, or appointment type is being reserved?
• Which availability, capacity, business-hours, buffers, minimum notice, and party-size rules define bookable slots?
• What customer details, intake questions, consent, policy, verification, or payment must be complete before the slot is held?
• What timezone does the booking page show, and is that correct for remote and in-person bookings?
• When is the slot temporarily held, confirmed, released, canceled, rescheduled, or waitlisted?
• What happens if another user takes the slot between selection and confirmation?