All documents

Stays and check-ins: tracking room occupancy without a spreadsheet

How to link a stay to a guest, record check-in, correct dates, configure cleaning, and close a stay after checkout.

Published
Updated

A stay record supports operational planning: it holds nights for a room, shows the expected check-in and checkout, and helps schedule cleaning. It is not a sale and does not replace an external booking system. It contains no price, payment, documents, or list of occupants.

Each stay is linked to one primary guest. Search for returning guests by telephone number in the guest directory, and check occupancy by date in the calendar.

How to add a stay

First, open ‘Calendar’:

  1. Select ‘Add stay’.
  2. Enter the guest’s telephone number in international format.
  3. If the telephone number is already in the directory, check the guest that was found. If the number is new, enter a name: the guest record will be created when you save.

  4. Select the check-in date, then the checkout date.
  5. Select a room that is available for the period.
  6. Check the required expected check-in and checkout times.
  7. If there is an external booking, enter its reference. Add only the note about this particular stay that employees need.

  8. Check the cleaning schedule and save the stay.

Start with the telephone number. It is the guest’s unique key within the organisation, so a repeat stay is linked to the existing record instead of creating a duplicate. The name of a guest who was found comes from the directory. To correct it, open ‘Guests’.

If the guest who was found is on the blocklist, the form shows the reason. This is a warning, not an automatic prohibition: you can save the stay after a considered review.

The external booking reference is optional. Leave it empty for a guest without a record in an external system; do not invent a value. Until a stay is completed or cancelled, the reference can be corrected in the same form — against the original booking, not arbitrarily. Every correction is kept in the journal, and the value must stay unique among the stays of one property.

Select the period first, then the room

The room list depends on the selected nights. Until a checkout date is selected, the form cannot reliably show available rooms. If the second date you select is earlier than the check-in date, period selection restarts from that date.

Stay durationSelect check-in date, then check-out date.
August 2026
Mon
Tue
Wed
Thu
Fri
Sat
Sun

19 August 2026 — 22 August 2026

Check-outCheck-inOccupied

Check-in
19 August 2026
Check-out
22 August 2026
Total
4 days, 3 nights
A practice period selector. Change the dates, check the occupied nights, and open the tooltip for a marked day using a pointer or the keyboard.

Dots on the practice calendar represent work for the room. They do not prevent a stay by themselves. Availability is determined only by occupied nights.

Stay statuses

  • Planned stay
  • In house
  • Checked out
  • Cancelled
Four states of one record: planned stay, actual stay, completion after checkout, and cancellation before check-in.
  • Planned stay: the guest has not checked in yet, but this record already holds every night in the period.
  • In house: an administrator recorded the actual check-in.
  • Checked out: checkout was confirmed from the room page and the stay was closed.
  • Cancelled: the stay was cancelled before check-in, releasing its nights.

The ‘No check-in’ marker is not a fifth status. If the actual check-in has not been recorded, the system opens a persistent situation for an administrator right at the expected check-in time and creates a Check the guest in task. The situation has a two-hour response deadline: while it runs, the calendar reads ‘Awaiting the guest’, and once it has passed — ‘No check-in’. The system reports the situation once; the list itself keeps it in the queue — until check-in is confirmed, the dates are validly corrected, the stay is cancelled, or the precise checkout is recorded. It does not cancel the stay, release the room, or change its readiness.

Check-in and correcting a mistake

When the guest arrives, open the stay, select ‘Check in’, and enter the actual time. The nights and dates do not change: the stay was already holding the room. Only the truthful fact of arrival and the displayed status change.

The actual check-in can be recorded later than planned, including outside the selected dates. In that case, the system saves the fact but shows ‘Dates need to be corrected’ and does not activate recurring cleaning until the dates include the check-in. If another guest is already recorded as actually staying in the same room, the second check-in will not be saved: refresh the data and check which stay needs to be closed or corrected.

If the time of a real check-in is wrong, select ‘Correct check-in time’, enter the correct date and time, and save. The stay remains ‘In house’ throughout the correction, while the journal retains the previous and corrected values. This is one correction, not an undo followed by another check-in.

‘Guest did not actually check in’ has a different meaning: the whole check-in fact was false. Only then remove it — the record returns to ‘Planned stay’, and the correction remains in the activity log.

A checked-in stay cannot be cancelled, because cancellation would release a room where a guest is present. The next action depends on the situation:

  • for a wrong time of a real check-in, correct the check-in time;
  • if the guest never checked in, remove the check-in and then cancel the stay if necessary;
  • for an actual departure, select ‘Confirm checkout’ in the same form.

Which nights are occupied

The period runs from the check-in date up to, but not including, the night after checkout. For example, a 10–14 record occupies the nights of the 10th through the 13th. The guest checks out on the 14th, and the next guest can check in that same day.

The periods 10–14 and 14–18 therefore do not overlap. The system will not allow two stays to be saved for the same night. In the period selector, half days are shown with diagonal edges: the room becomes available in the morning and occupied in the evening.

The stay and guest do not determine room readiness. Readiness is still derived from the preparation cycle, the accepted main cleaning task, and unresolved blockers. An occupied room can also be blocked for readiness.

Check-in and checkout times

Dates are selected in the calendar, while the required times refine the plan within each selected day. By default, the form suggests 14:00 for check-in and 12:00 for checkout in the organisation’s time zone. If the plan differs, enter the actual expected times: a new or changed stay cannot be saved without both values.

The expected checkout time remains visible in the calendar and helps with daily planning. For a guest who is in the house, it also starts checkout confirmation: at a moment chosen in advance — one hour before the expected checkout by default — the system opens a Confirm checkout task and reminds about it once.

Arrival confirmation

A day before the expected check-in time, ATQAR opens a Confirm the planned stay task. It is a question for an administrator rather than work for an executor: the confirmation is a planning fact, and it does not check the guest in, occupy nights, or change room readiness.

You may confirm at any point before the expected check-in time, and withdraw a confirmation recorded by mistake up to the same instant. A confirmation belongs to one exact check-in time: change that time and it is cleared, and the question is asked again — confirming one plan does not answer another.

Cleaning during a stay

In ‘Standard’ mode, the stay inherits its property’s schedule. ‘Special schedule’ mode lets you choose a different interval or disable this cleaning for a particular stay.

The schedule is calculated only from the operational day of the actual check-in. Until check-in is recorded, future cards can retain their assignment and room, but remain ‘Scheduled’: they cannot be started, are not overdue, and do not affect readiness. If check-in falls outside the planned dates, the schedule also waits for the dates to be corrected. Work that has already been completed, manually moved, or started is not rewritten retrospectively.

The ‘Set a preferred cleaning window’ option records an interval that is convenient for the guest. It is a preference:

  • it does not become a task deadline;
  • it does not make the task overdue;
  • it does not prevent work from starting earlier or later;
  • it does not block the room;
  • it does not guarantee a visit at exactly that time.

Distant future cleaning tasks are created as ‘Scheduled’. They can be assigned in advance but cannot be started before activation. After check-in is recorded with correct dates, a task dated today or the next two operational days becomes ‘Ready to do’, retaining its room and assignee. Scheduled cleaning during a stay does not affect room readiness.

When dates or the schedule change, the system updates only work that can still be rescheduled safely. A task that has started, is blocked, or has been submitted for review does not disappear: the administrator receives an explicit exception that must be resolved separately.

Correcting dates and cancelling a stay

To extend a stay, open it from the calendar or the ‘Stays in the period’ list and select the new checkout date once. The check-in date remains selected, so you do not have to find it again. To change the start instead, first select ‘Change check-in date’, then choose the new day.

When ‘Dates need to be corrected’ is shown, a short explanation names the actual check-in day. A changed period can be saved only when it includes that day. Other stay fields and ‘Confirm checkout’ remain available: correcting the plan is not required before recording a real departure.

The room on an existing record cannot be changed: ATQAR does not yet support moving to another room in a single action. The external booking reference, however, can be corrected in the form until the stay is completed or cancelled. Do not create a second active stay before the old one has ended. First cancel the old stay or confirm checkout from the previous room, then create a new record. To preserve the link to the external booking, enter its reference in the new record’s note: the original booking reference remains in the old history.

The ‘Cancel stay’ button is available only for ‘Planned stay’ status. Enter a reason and confirm the action. All of its nights are released. The system cancels future ‘Scheduled’ and not yet started ‘Ready to do’ cleaning; work that has already started, is blocked, or has been submitted for review remains an explicit exception for the administrator.

Checkout and closing a stay

Actual checkout is confirmed with ‘Confirm checkout’ in the stay form, from the room page, or from the ‘Checkout not confirmed’ situation — never with the stay cancellation button. The action remains available while ‘Dates need to be corrected’ is shown. The form identifies the exact stay being closed: you cannot select another one by date or leave the displayed stay open. Check the guest and enter the actual time. A late checkout can be recorded outside the planned period — the precise fact is saved, while the planned dates remain in the history.

On the room page, the ordinary checkout takes one press: the system records the current server time and immediately creates the cleaning. If checkout is being recorded later and the time differs, select ‘Checkout was earlier’ first.

If an active preparation cycle already exists for the room, the system does not create a second one: the action opens the existing cycle and its main cleaning task.

With an early checkout, the room is released from the actual operational day, but the original planned dates remain in the history. This makes the difference between plan and fact visible. Confirming checkout also starts a room preparation cycle. It does not automatically make the room ready.

The detailed process is described in ‘Checkouts and cleaning’.