Stays

One attendee’s hotel reservation: nights, room block attribution, the hotel’s answer, check-in — and the CSV export that is your rooming list.

A stay is one attendee housed in one room type for a span of nights: who, which hotel, which room type, check-in to check-out, and how far along the hotel is — requested, confirmed, checked in. The Stays page is the event’s rooming list.

A stay is a reservation, never a physical room. If the hotel later assigns a room number, you can record it — but a stay never requires one to exist.

Arrange a stay

1. Click Arrange stay

   Pick the attendee (search by name or email), the hotel and room type, and the 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 is what feeds that block’s pickup; choosing Outside every block means the person is housed but counted against no contract.

3. Track it through its lifecycle

   The stay starts as Requested. Move it along as reality happens — reserved with the hotel, confirmed by the hotel, checked in, checked out.

The lifecycle

Requested → Reserved → Confirmed → Checked in → Checked out, with two exits:

Status	Meaning
Requested	The stay exists on your side; nothing sent or settled yet.
Reserved	Placed with the hotel, awaiting their answer.
Confirmed	The hotel answered. The confirmation number is the evidence of this — record it when you have it, but the status does not wait for the number.
Checked in / Checked out	The guest arrived / departed.
Cancelled	Called off. Reinstatable — reinstating starts it over as a fresh request.
No-show	The guest did not arrive. A late guest can still be checked in from here.

A stay counts against its room block’s nightly pickup while it is not cancelled or a no-show — those two release the pickup for every night, without erasing the record. Nothing is ever deleted: who was housed where must stay answerable.

The hotel record

All optional, filled in as the hotel volunteers them: the hotel confirmation number (what “Confirmed” is evidenced by), the room number — added late, if at all — and external reservation/room IDs for hotels synced with an outside system.

Guests

A room often holds more than the attendee the stay belongs to. The Guests list records who shares the room — a name first, optionally linked to another registered attendee — and is edited as one list.

Everything leaves a trace

• Every change to a stay — created, dates moved, status changed, room number recorded — appears on the attendee’s activity timeline on their detail page, alongside their registration history.
• Automations can react to two housing moments: Stay confirmed by the hotel and Guest checked in at the hotel. “Email the guest their confirmation number” is a flow you wire, filtered by ticket type like any other trigger.
• All operations land in the event’s audit log.

The rooming list

Export CSV on the Stays page downloads the table — attendee, hotel, room type, nights, status, confirmation and room numbers. That file is the rooming list you exchange with the hotel.

Rules to know

• One stay = one attendee in one room type for a span of nights; the room number is optional and late.
• Attributed stays feed their block’s pickup; unattributed stays mean housed outside every block.
• Confirmed means “the hotel answered” — the confirmation number is evidence, not a precondition.
• Cancelled is reinstatable (as a fresh request); a no-show can still check in.
• Cancelled and no-show release pickup immediately; records are never deleted.
• A full block never prevents a stay — see over-block flagging.