Arrange a stay
1
Create it
Choose Arrange stay. Pick the attendee, hotel, room type, and check-in and check-out dates. Nights are the hotel’s local dates.
2
Attribute it to a room block — or not
Optionally pick the room block this stay draws from. Attribution feeds that block’s pickup. Outside every block means the person is housed and counted against no contract.
3
Move it through its lifecycle
The stay starts as Requested. Update status as the hotel confirms, then as the guest checks in and out.
Lifecycle
Requested → Reserved → Confirmed → Checked in → Checked out, with two exits:
A stay counts against its room block’s nightly pickup while it is not cancelled or a no-show. Those two statuses release pickup for every night. Records are never deleted.
Hotel record
Optional fields, filled when available: hotel confirmation number, room number, and external reservation/room IDs for hotels synced with an outside system.Guests
A room may hold more than the attendee the stay belongs to. Guests records who shares the room — a name, optionally linked to another registered attendee.Activity and automations
- Stay changes appear on the attendee’s activity timeline on the detail page.
- Automations can run on Stay confirmed by the hotel and Guest checked in at the hotel.
- Operations land in the event audit log.
Rooming list
Export CSV on the Stays page downloads the table — attendee, hotel, room type, nights, status, confirmation and room numbers.Rules
- One stay = one attendee in one room type for a span of nights. Room number is optional.
- Attributed stays feed block pickup. Unattributed stays are housed outside every block.
- Confirmed means the hotel confirmed. The confirmation number is evidence, not a precondition.
- Cancelled is reinstatable as a new request. A no-show can still check in.
- Cancelled and no-show release pickup immediately. Records are never deleted.
- A full block does not prevent a stay. See over-block flagging.