YStay

Run a stay: check-in and checkout

The stay is born at confirmation, not on arrival day. The two arrival mechanisms, the checklists you tick yourself — and the steps the field worker confirms themselves —, and what departure really cuts off.

A stay is the operational face of a reservation: it is where lock access, the arrival and departure checklists, the inspection and the proof all live. The reservation keeps the commercial side — money, messages, status — and the View reservation → link moves back and forth between the two pages.

The stay is born at confirmation

The stay does not wait for the arrival date: it is created the moment the reservation turns Confirmed. Until then, the page reads “Confirm the reservation to create the stay and unlock operations (access, check-in/out, proof).” and no field panel exists. After that, the reservation status drives the stay: Checked in puts it in progress, Checked out ends it.

The path, screen by screen

  1. Open the Stays page

    The Stays menu opens the list, subtitled “Field operations: access, check-in/out, inspection and proof per stay.”. Three tabs split it — Ongoing, Upcoming, Ended — and a field filters by guest or home (“Search a guest or a home…”). Stays whose proof has been built carry the Proof available badge; empty tabs stay explicit, such as “Confirmed stays will appear here.” The Stays and Reservations menus only appear to members whose access includes Stay operations (reservations, check-in/out) for reading.

    The Stays page: the tabs and one ongoing stay.
    The Stays page: the tabs and one ongoing stay.
  2. Read the stay page

    The page stacks its panels in a fixed order: Property access, Guest inventory, Inspection incentive, Check-in / Checkout, then StayProof — evidence.

    An empty panel is a normal state, not a failure: nothing is created in advance. Property access says “No active access code.” until you generate one — see Guest access codes: issuance, tracking and troubleshooting.

    These panels are read with the Lecture box of Stay operations; their gestures — door code, inspection, sessions, evidence — require the Écriture box. The one exception: changing the Inspection incentive falls under the Écriture box of Short-term finances.

    A stay page: the operational panels.
    A stay page: the operational panels.
  3. Open a check-in session

    In Check-in / Checkout, two buttons: + Check-in and + Checkout. Each opens a session, that is, a dated checklist. Only one open session per type: the button stays disabled until the previous one is closed. Before any session exists, the panel shows “No session.”

    When a Check-in welcome or Check-out inspection task is entrusted to a field worker, you do not have to open the session: it opens by itself when the task starts, with the same steps (see below). Opened that way, it also disables the button, like any open session.

    An open check-in session: the steps and the closing button.
    An open check-in session: the steps and the closing button.
  4. Validate the steps

    A check-in session comes with three required steps: “Accès au logement vérifié”, “Arrivée du voyageur confirmée”, “État d'entrée constaté”. Checkout has its own: “Départ du voyageur confirmé”, “État de sortie vérifié”, “Accès clôturé”. Validate strikes the step through; there is no undo.

    When the session is linked to a Check-in welcome or Check-out inspection task, the field worker — an agent without an account or a contractor — confirms two of the steps themselves from their phone, with Confirm: on arrival “Accès au logement vérifié” and “Arrivée du voyageur confirmée”, on departure “Départ du voyageur confirmé” and “Accès clôturé”. They show up ticked in this same panel. The other two — “État d'entrée constaté” and “État de sortie vérifié” — are not theirs: they are ticked with the inspection, or by you, and the worker's screen shows them read-only. Until their two steps are confirmed, their Finish button stays greyed out; if you have to close their task for them, Force close goes past it, with a note (see Housekeeping and turnover). On arrival they must also get the guest to sign the key handover when the Key handover signature on arrival setting is on — it is by default (see Your schedule by link and Proof of service).

    A check-in welcome or a check-out that you carry out yourself, or that a member of your team carries out, requires neither these steps nor the signature: the task finishes as before, and you close the session from this panel.

  5. Close the session

    Close the session shuts the checklist. If every required step is validated, closing is immediate. Otherwise a confirmation opens: Close despite incomplete steps, with the message “Some required steps are not validated. The forced closure will be logged with your reason.”, a mandatory Override reason field and the Close anyway button. The reason stays attached to the session, including in a dispute.

    Sometimes there is nothing for you to close. When the field worker finishes their task and every required step is done — theirs and the inspection's —, the session closes by itself, with no override reason, and the reservation moves to Checked in (or Checked out for a checkout), as if you had closed the session. If a step is missing — the inspection is not finished yet, for example — the session stays open, even if the inspection ends later, and it is up to you to close it, as above. A task force-closed by the host never closes the session. And if the check-out inspection ends before the worker touches Finish, it is the end of the inspection that closes the task: the departure session is then left for you to close.

  6. Mark the arrival, then the departure

    On the reservation page, the Update status card only shows the transitions allowed from the current state: → Checked in on arrival day, then → Checked out at departure. Cancelling or marking a no-show asks for a confirmation with a reason. These buttons require the Écriture box of Stay operations.

Early arrival and late departure

Arrival and departure do not always happen at the standard times: YStay can offer the guest an early check-in or a late checkout, paid, free or “on request”. As long as the guest has not paid (or you have not marked the installment as paid), nothing changes on the stay. Once the extra is paid, the reservation page shows the confirmed time — “Early check-in confirmed at 12:00”, “Late check-out confirmed at 14:00” — in the Early check-in / late check-out card, and three things follow: the access code is reissued with a window that opens earlier or closes later, the check-in (or check-out) task that has not started is rescheduled, and the deadline of the departure cleaning, if it has not started, is recomputed.

Status transitions stay your gestures: → Checked in and → Checked out are used as usual, and departure still revokes the active codes. See Early check-in and late checkout.

What departure actually triggers

  • The stay turns ended and its departure time is stamped.
  • Active lock codes are revoked, even for an early departure: without that, a code would stay valid until the original end date.
  • A housekeeping task is created for the home — see Housekeeping and turnover.

If something does not go as expected

  • The + Check-in button stays disabled: a session of the same type is already open, including one that opened by itself when the field worker started their task. The error message itself is “Cannot open (session already open or stay not eligible).”
  • No field panel on the reservation: it is not Confirmed yet.
  • The transition you expect is missing: only transitions valid from the current state are shown.
  • A session opened or closed by itself: that is the field worker's doing. It opens when they start their welcome or departure task, and closes when they finish it if every required step is done.
  • The field worker cannot finish their task: one of their steps is missing or, on arrival, so is the key handover signature. They read it under their Finish button; you can force the closure with a note.

Next

Updated on