---
title: "Stays and check-ins: tracking room occupancy without a spreadsheet"
description: "How to link a stay to a guest, record check-in, correct dates, configure cleaning, and close a stay after checkout."
canonical: "https://atqar.com/en/docs/stays-and-calendar/"
locale: en
language: en-GB
audience: administrator
published: 2026-08-04
updated: 2026-09-03
source: "https://atqar.com"
alternates:
  ru: "https://atqar.com/ru/docs/stays-and-calendar.md"
  kk: "https://atqar.com/kk/docs/stays-and-calendar.md"
  es: "https://atqar.com/es/docs/stays-and-calendar.md"
  pt: "https://atqar.com/pt/docs/stays-and-calendar.md"
  de: "https://atqar.com/de/docs/stays-and-calendar.md"
  fr: "https://atqar.com/fr/docs/stays-and-calendar.md"
  it: "https://atqar.com/it/docs/stays-and-calendar.md"
  tr: "https://atqar.com/tr/docs/stays-and-calendar.md"
  uz: "https://atqar.com/uz/docs/stays-and-calendar.md"
  ky: "https://atqar.com/ky/docs/stays-and-calendar.md"
  tg: "https://atqar.com/tg/docs/stays-and-calendar.md"
---

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](https://atqar.com/en/docs/guests/), and check
occupancy by date in the [calendar](https://atqar.com/en/docs/calendar/).

## How to add a stay

First, open [**‘Calendar’**](https://atqar.com/en/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.

> Product demonstration: 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

> Product demonstration: 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’](https://atqar.com/en/docs/checkouts-and-cleaning/).
