# Check-In (/docs/bookings/check-in) Check-in lets operators mark a booking as "the customer has arrived and is accounted for." It is independent of the booking's [status](/docs/bookings/statuses) — a booking can be confirmed but not yet checked in, or checked in and then reverted if a mistake was made. Every check-in and revert is recorded in the booking's event log with the acting user and the timestamp. What Check-In Is For [#what-check-in-is-for] Check-in is used at the start of the customer's experience to: * Confirm the guest has arrived and staff know they are on site * Enforce that required waivers are signed before the activity begins * Enforce that guest information is complete before the activity begins * Produce a clean audit trail of when arrivals actually happened (not just when bookings were created) Check-in is **orthogonal to status**. A checked-in booking can still be canceled later; a confirmed booking can go through the whole day without ever being checked in (reporting will show it as confirmed-but-never-checked-in). Per-Activity Prerequisites [#per-activity-prerequisites] Each activity can define what must be true before a booking for that activity can be checked in. Settings live under **Activity → Check-In**. | Setting | Description | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Require all guest info** | If enabled, every guest slot on the booking must be present and have a non-empty name before check-in is allowed. Guest counts come from the booking's demographic or equipment occupancy data. | | **Required waivers** | A list of waivers that must be signed. For each, choose whether **all guests must sign personally**, or **one signature on the booking** (typically a customer/parent) is sufficient. Optionally exempt minor guests from the all-guests requirement. | | **Minor Waiver** | An optional single waiver that a guardian must sign once per booking when any guest is younger than the location's [age of majority](#minors-age-of-majority). Used because minors cannot legally sign their own waivers. | When no check-in settings are configured for an activity, bookings for that activity can be checked in unconditionally. Required Waivers [#required-waivers] Waivers are location-scoped in Resytech — they belong to a location and can be reused across multiple activities. The **Required waivers** list on an activity links existing waivers to that activity's check-in gate. Editing a waiver from the **Waivers** section will affect every activity that requires it. For each required waiver: * **Applies to all guests** — every guest on the booking must have their own signature, matched via the guest record. Useful for personal liability waivers. * **One signature suffices** — any submission on the booking (a customer signing on behalf of everyone, or any single guest) clears the requirement. Useful when a parent is signing for minors. * **Minors except** (only available when "Applies to all guests" is on) — minor guests are skipped from the per-guest signature requirement. Pair this with the **Minor Waiver** setting to require a separate guardian-signed waiver instead. Minors (Age of Majority) [#minors-age-of-majority] Operators can set a per-location **age of majority** (default 18) under **Location → Waivers & Minors**. The system classifies each booking guest as a minor based on their date of birth and this threshold. * Guests **without** a date of birth on file are treated as adults (so locations that haven't opted into [DOB collection](/how-to/checkout/configure-customer-booking-management) see no behavior change). * If an activity has a **Minor Waiver** configured and the booking has one or more minor guests, a guardian must sign that waiver on the booking before check-in is allowed. One signature covers all minor guests. * The **Minors except** toggle on a regular required waiver removes minor guests from the per-guest signature requirement for that specific waiver. Checking a Booking In [#checking-a-booking-in] From the booking detail view: 1. Click **Check In** in the booking header. 2. If all prerequisites are met, the booking is marked checked in and the check-in timestamp appears in the header. 3. If any prerequisites are not met, the dashboard displays the full list of blocking reasons so staff can walk the customer through each one before retrying. Blocking reasons are returned as a single list so the customer can address all of them in one pass rather than bouncing back and forth. Blocking Reasons [#blocking-reasons] | Code | What it means | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MissingGuestInfo` | Require-all-guest-info is enabled and either the guest count is short, or at least one guest row has a blank name. | | `MissingCustomerWaiver` | A required waiver (one-signature mode) has no submission on the booking. | | `MissingGuestWaivers` | A required waiver (all-guests mode) is missing signatures for one or more specific guests. The response lists which guests. Minor guests are excluded from this list when the waiver has "Minors except" enabled. | | `MissingMinorWaiver` | The activity has a Minor Waiver configured, the booking has one or more minor guests, and no submission of that waiver exists on the booking. A guardian must sign it. | Reverting a Check-In [#reverting-a-check-in] If a booking was checked in by mistake, revert it from the booking header. Revert clears the checked-in flag, timestamp, and acting user, but the history is preserved: * The original check-in event (`checked_in`) stays in the event log. * A new `check_in_reverted` event is added, carrying the original check-in timestamp so you can see how long the booking was checked in before being reverted. Reverting a booking that is not checked in is a no-op (it does not create a log entry). Audit Trail [#audit-trail] Check-in actions are written to the booking event log alongside status changes, balance adjustments, and other audited events: | Event Name | When | | ------------------- | ---------------------------------------------------------------------------- | | `checked_in` | Booking was checked in. The log row captures the acting user and timestamp. | | `check_in_reverted` | A prior check-in was reverted. Event data includes `OriginalCheckedInAtUtc`. | Both events appear under the **Logs** tab of the booking detail view. Related How-To Guides [#related-how-to-guides] * [Update Booking Status](/how-to/bookings/update-booking-status) * [Editing Bookings](/docs/bookings/editing-bookings)