> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Attribute it to a room block — or not">
    Optionally pick the [room block](/en/housing/room-blocks) 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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.                                                                          |

<Note>
  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.
</Note>

## 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](/en/events/attendees), alongside their registration history.
* [Automations](/en/marketing/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](/en/events/settings).

## 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](/en/housing/room-blocks).