--- title: "Room review after cleaning: who checks it, and what a return does" description: "How an administrator accepts a work result, when to return it, and why the reviewer must not be the person who carried it out." canonical: "https://atqar.com/en/docs/review-and-rework/" locale: en language: en-GB audience: administrator published: 2026-08-03 updated: 2026-09-05 source: "https://atqar.com" alternates: ru: "https://atqar.com/ru/docs/review-and-rework.md" kk: "https://atqar.com/kk/docs/review-and-rework.md" es: "https://atqar.com/es/docs/review-and-rework.md" pt: "https://atqar.com/pt/docs/review-and-rework.md" de: "https://atqar.com/de/docs/review-and-rework.md" fr: "https://atqar.com/fr/docs/review-and-rework.md" it: "https://atqar.com/it/docs/review-and-rework.md" tr: "https://atqar.com/tr/docs/review-and-rework.md" uz: "https://atqar.com/uz/docs/review-and-rework.md" ky: "https://atqar.com/ky/docs/review-and-rework.md" tg: "https://atqar.com/tg/docs/review-and-rework.md" --- This page is for administrators and owners. Any employee assigned cleaning or repair needs to know one thing: after submitting the result, wait for an independent review. What is reviewed is the work of a housekeeper, or cleaner, and of a technician. ## Who reviews The result of cleaning and repair is accepted by an administrator or owner **who did not carry out that work**. Nobody can accept their own work — with one narrow exception: when no other eligible reviewer exists in the organisation at the moment of acceptance (for example, there is a single administrator), the server lets the executor accept their own result and records that exception in the history as an immutable fact. Wherever another eligible reviewer exists, the rule applies without exception. The person carrying out an inspection, replenishment, or other work closes it themselves; these tasks do not have a separate review. However, if such work blocks room readiness, its result still goes to an administrator, except when the work was carried out by an administrator or owner. In that case the history already records who did what, and a second person is not required. ## Where work awaits your decision Open [**Important**](https://atqar.com/en/tasks/?view=attention) in Tasks. It contains everything awaiting an administrator: submitted work, problem reports, and unassigned work. Overdue work and work due in less than two hours remain visible in the same view. This work is visible to every active owner and administrator in one organisation-wide list. A problem report or unassigned work can be **claimed** in advance. While the administrative triage is claimed by you, another administrator cannot complete the same triage. A future, unassigned automatic cleaning with the **“Scheduled”** status appears in plans and does not raise an alert. If it has activated while still unassigned, the system creates a persistent administrative item and notifies about it once. From then on, the list itself keeps the situation visible: until the work is assigned or the triage is claimed, the item does not go anywhere. If the decision is claimed by you but you cannot continue, use **“Release”** and provide a reason. A potentially blocking triage has a 15-minute deadline to begin the first decision. After that, the card becomes overdue and draws administrators' attention again, but somebody else's claim is not removed or transferred automatically. The person who owns it must explicitly release it. Acceptance of a result does not become exclusive because of such a claim. Any eligible administrator or owner who did not carry out the work can accept or return the result. If two people decide simultaneously, the first valid decision is saved and the second person's screen asks them to refresh the data. ## Photos, videos, and review onsite A photo or video is optional when a worker selects **“Done”**. - With an available file, review the result remotely and select **“Accept”** if it meets the task. - Without a file, inspect the result onsite and select **“Accept”**: the action itself records the personal inspection. An upload failure never traps completed work in a form: the worker may retry or continue without a file. Files that were uploaded remain private, immutable evidence and must still be reviewed. If all files were later destroyed through the permitted privacy process, use an onsite inspection; the decision remains linked to the deletion audit. Acceptance and return take place in the web app. Telegram displays a safe alert and a link to the card, but does not open files or record the decision for you. ## Accept a result 1. Open work with the “Under review” status. 2. Read the task, the optional worker note, and any available files. 3. Review the files remotely, or inspect the result onsite when there is no usable file. 4. Select the matching accept action. The action itself records the review method; there is no extra checkbox. > Product demonstration: Work submitted for review. The administrator must act next. After acceptance, the work moves to **“Completed”**. Accepting the canonical cleaning completes its preparation cycle. If no unresolved blocking work remains, the room becomes **ready**. If blockers remain, the cycle is still complete but the room stays **blocked** until that work is resolved. ## Return for rework If the result is not acceptable, select the equally visible **“Return”** action and describe exactly what must be corrected. When there is no usable file, inspect the result onsite first. The return action records that inspection without an extra checkbox. Be specific. “Redo it” tells the worker nothing; “the bathroom towel was not replaced and there is dust on the windowsill” tells them what is wrong. A returned cleaning releases its previous assignee and exact hour. It appears in **“Important”** as work that must be assigned again; an administrator then chooses an active housekeeper and a valid exact hour with the ordinary planning action. After that, the worker corrects it and selects “Done” again; no new start is required. The original submission is not erased: it, your return, and the resubmission all remain in the history. ## Work completed outside the normal flow An administrator closes such work with **“Mark as done”** on the task card. One press closes the task: the history records the assigned performer and the time of the press, and the press itself is your confirmation that you inspected the result personally. The “who performed the work” and “when” fields open only where the record cannot answer for you: nobody is assigned, or the cleaning or repair was performed by the confirming administrator, who for those work types cannot be the recorded performer. Then choose an employee or an external specialist and give the time; it cannot be in the future. The same **“Done”** button sits on a worker’s own task. It is one word for two different acts, told apart by role rather than by label: the worker hands the work over, and it then either awaits review when that work type requires it or closes immediately when it does not. ## Triage a problem report When an employee reports a problem, the task reaches you awaiting triage. Select **“Assign”** and choose: | Decision | When to choose it | | ---------------------------- | ---------------------------------------- | | Requires repair | something is broken and needs repair | | Requires replenishment | something is missing | | The report is mistaken | everything is actually fine | | This is a duplicate of another task | the same issue has already been reported | In the form, decide **whether the problem blocks room readiness** and, if the result is needed by a particular time, fill in the **Date** field — the deadline, its day and its hour together. There is no separate question about urgency: the **‘Urgent’** mark appears automatically two hours before the deadline, then changes to **‘Overdue’** after it. On the current screen, select an eligible assignee for repair or replenishment. The deadline can also be changed later by changing the task planning. Before triage, a potentially blocking report keeps the room blocked. This is deliberately cautious behaviour. If you select duplicate, identify the primary task. It then determines readiness. ## Assignment Every classified operational task may be assigned to any active employee. The exception is the two cleaning types: checkout cleaning and scheduled cleaning. Such work may be held only by an active housekeeper whose current duty at that property fully covers the exact 60-minute slot. An administrator must classify a problem report first. There is no shared list from which employees select work themselves. Select **“Assign”** — on the card, or in the Assignee row itself. The list contains every active employee in the organisation. Choose the person whose practical skills fit the task; the system does not infer skills from their role. ## Work history Every event already recorded is collected in a single chronological **Work history** section, newest first. It shows together: - the worker's results, verification method, acceptance, and return; - assignments, work starts, blockers, comments, and corrections. A resubmission after rework is added to the same stream beside the previous submission rather than replacing it. A short recent segment loads first; for a long history, select “Show older entries” until you reach the required record. If the work type's rules closed a result immediately without separate review, the log displays it as complete. Such a submission is not labelled “Awaiting review”. Records are not rewritten. A mistake and its correction remain beside each other in the history, making it possible to see not only the outcome but how it was reached. A room has the same complete view: the **Room timeline** on its card brings together events from every task for that room, newest first. ## Correcting mistakes A mistake is corrected with a visible action, not deletion. When several options exist, uncommon actions sit under the **“Task actions”** heading: - **“Cancel”**: the work is not required; provide a reason; - **“Reopen”**: it was accepted, but later proved to have been accepted too early; - **“Edit”**: correct the property, room, task description, assignee, work type, or date. Once work has been accepted there is nothing left to decide, and then these two actions are not hidden behind anything: the card says **“Work accepted”**, and **“Reopen”** and **“Edit”** stand on it as ordinary buttons. The **“More”** fold stays where it is — it holds rarities such as **“Correct departure details”**. Cancelling and reopening require a reason. Changing a task does not: the entry itself keeps what the value was and what it became. The **“Edit task”** form repeats the fields of a new task and fills them with what the record holds now. The text in **“Task description”** can be reworded while the work is unfinished: the previous wording is not erased but goes into the task history as **“Description corrected”**, where the previous and the corrected text stand side by side. The short title is re-derived from that text, so the heading and the description never disagree. In the activity journal the correction reads as **“Corrected the wording”**. The **“Assignee”** field hands the work to somebody else; a cleaning has no such field, because its employee and its exact hour are one indivisible plan changed by an action of its own. The **“Room is available for check-in”** switch answers the same question the creating form asks, and its answer can now be corrected: **“No”** holds the room and **“Yes”** releases it. A reason is required here — a lifted block is seen by nobody until somebody tries to put a guest in that room — and it goes into the task history beside the previous and the new answer. The changes are written by pressing **“Save”**. The form shows only the fields that can actually be saved in the task's current state — the rest are not shown at all, and one line at the top says that you are not seeing everything. Started work can no longer be moved to another property, and the work type changes between the three an administrator classifies by hand — **repair**, **replenishment** and **scheduled cleaning** — before the work starts, or after it is completed or cancelled. The room within the same property can still be corrected. The exception is a preparation cycle's main cleaning and a cleaning created by a stay's cadence: neither their work type nor their property and room are corrected here, because the cycle or the stay owns that. The work type also stays fixed on any other cleaning bound to a preparation cycle. When work becomes a scheduled cleaning, the previous assignee is released and the cleaning goes to administrative distribution: the assignee and the exact hour are chosen by a separate next action. A completed or cancelled task can no longer be reworded: it keeps the wording it was carried out and accepted against; a task marked as a duplicate must have that link removed first. An assignee can only be handed to somebody else, never removed: the empty **“Not assigned yet”** option is offered only while nobody holds the task. The deadline stands in the form as the **Date** field and is available in any state, including after completion: a typo in a record stays a typo. A cleaning has no such field at all — its day and its hour come from the cleaning plan, which stands in the same group as the separate **Date** and **Time** fields. There is no separate urgency control in the form; urgency is calculated from the deadline and appears only during its final two hours. Reopening a cleaning does not ask for an assignee or exact slot: it first returns the cleaning to administrative distribution, and planning is a separate next action. Every such action remains in the history with the original, so both what happened and how it was corrected stay visible later. > Simply cancelling blocking work does not restore room readiness. A blocker is > cleared by accepting the result, direct completion by an administrator or > owner of work eligible for that flow, explicit reclassification with a > reason, or identifying the work as a duplicate. Next: [Checkouts and cleaning](https://atqar.com/en/docs/checkouts-and-cleaning/).