A Cleaning Job Nobody Was Assigned: How to Trace It

When the room was never cleaned, the failure is usually not the cleaner. It is a handoff that quietly had no owner.

Last updated: September 20, 2026

A unit found uncleaned at check-in has four possible origins, and only one of them is a person deciding not to work. Before you make a phone call, run the trace in a fixed order: did a job exist for that departure, was it created against the unit the guest walked into, was anybody named as responsible. Most cases fail at the first or third question, which matters because the fixes are completely different. This guide sets out the four stall points, the check that settles each, and the changes that make the trace unnecessary. Screen names and field labels differ between products and versions, so read yours for what they are and confirm current behaviour in your own account.

Key Takeaways

• The symptom is not the location. "The guest found it dirty" has four possible origins, and only one of them is a person not turning up.
• Check creation before attendance. A job that was never created cannot be late; that is the most common single cause.
• Right unit is a separate question. A job attached to a similarly named unit leaves the real one untouched and looks identical from outside.
• A queue is not an owner. A task visible to four people is a task nobody has.
• Fix the handoff, not the person. Naming one owner per unit per day removes the failure mode; chasing the cleaner does not.

Symptom, then location: the four places a turnover can stall

Start by placing the symptom, because the four stall points have different traces and different fixes.

Where it stalls	What it looks like from outside	What to check first
1. No job	Nothing was ever created for the departure	Count departures against jobs created for the same dates
2. Wrong unit	A job exists, but for a different listing	Read the unit field on the job, not its title
3. No owner	A job exists, sits in a shared queue, nobody took it	Look for a named assignee, not a team or a role
4. No completion	Someone was named, the work was not finished or not recorded	Look for a completion timestamp and a handover record

The order matters: start at step four and you have a conversation with a cleaner about something that was never in their list; start at step one and you have the answer in two minutes.

Note what three of the four have in common: everybody behaved reasonably. Somebody assumed the job would be created, or assumed a colleague had taken it. Unowned handoffs do not look like failures while they are happening, which is why they repeat.

Whether the job was created at all

This is the question to settle first, and it has a clean answer: does a cleaning job exist whose date matches the departure date of the stay that just ended?

The fastest version is a count rather than a search. Take the departures in a date range — a week is enough — and count the cleaning jobs created for those dates. If the numbers differ, the gap is your answer and the date takes a minute to find. If they match, stop here and move on.

Signal	What it rules out	Where to look next
Departures outnumber jobs for the same dates	Not an attendance problem; creation never happened	How jobs are triggered: manual entry, or a rule per departure
One date missing, all others present	A rule fired every other time	The reservation for that date: when it arrived and from which channel
Counts match, unit still dirty	Creation worked	The unit field on the job, then the assignee field
A job exists dated a day early or late	The trigger is keyed to the wrong date	Whether the trigger uses check-out or check-in

Three failures account for most of the first row. A turnover created by hand for each stay, which works until the week somebody is away. A same-day changeover assumed to generate a job by itself, when nothing in the setup does that. And a reservation that arrived late or by a route nobody watched, so there was no departure on the books when jobs were made.

That last one is a channel question rather than a cleaning question, and it is easier to see when every connected booking sits in one calendar with its source and status visible per night. You can put that in one place at localsbnb.com and connect a single channel before you commit to anything.

Whether it was created for the right unit

A job that exists for the wrong unit is invisible from the guest's side and easy to miss from yours, because the queue looks busy and correct.

The check is mechanical: open the job and read the unit field itself. Do not read the job title, the note, or the address line typed into a description, all of which can say one thing while the field says another. Where a property has units with similar names — a letter, a floor number, a "garden" and a "garden view" — this is the single most productive check in the whole trace.

Two situations produce the mismatch. Creation against a default, where the job picked the first unit in a list and nobody corrected it. Or a move after creation: the guest is shifted for a maintenance block or an upgrade, and the job stays behind with the original unit. Anything that moves a reservation without moving its task will produce this failure, and it will look random.

Timing distinguishes them. A job that was always wrong was wrong at creation. A job that became wrong has a change to the reservation after the job was made.

Whether anyone was ever made responsible for it

This is where most traces end, and the distinction is narrower than it sounds. A job with a due date and no assignee is not a job somebody declined; it is a job nobody was ever given.

What the job shows	What it actually means	The fix
No assignee at all	Never handed to anyone	One named owner per unit per day
A team or group named	Visible to several people, owned by none	Name a person, even when the team is one person today
A person named, no completion record	Either not done, or done and not recorded	Require a timestamp and a handover photo to close it
A person named who says they never saw it	They may not have been able to act on it	Check what their role is allowed to change

That last row is a permissions problem rather than a motivation problem. Where access is granted by domain — reservations, finances, room status, rates — a person whose role covers one domain can see a queue in another and still be unable to take from it. From outside that looks like indifference; from their side the control simply was not there. Check what a role can change before drawing a conclusion about a person.

The same caution applies to anything acting on your data. Where an assistant can carry out write actions for you, those are limited to overseas stores and wait for your confirmation before anything runs, so nothing is quietly done on your behalf. An unconfirmed handoff has not happened, and no tool will cover for one.

Making the trace unnecessary

Once you know which of the four stall points you hit, the fix is usually one of three changes rather than a conversation.

The first is one named owner per unit per day: not a team, not a pool, a name written before the day starts, so an unclaimed job shows at 8 am rather than at check-in. The second is tying creation to the departure date rather than to somebody's memory, whether by a rule or a list printed each morning and counted against the departures. The third is requiring a handover record to close a job: a timestamp and the photographs showing the unit as it was left.

All three are cheap, and they fail visibly rather than quietly. A missing owner shows at 8 am. A missing job shows in a count. A job that cannot close without a record cannot be quietly forgotten. The cost is a few minutes a day; what it removes is the 5 pm call from a guest standing in a room that should have been ready.

FAQ

Should I call the cleaner first?

No. Call them last, if at all. The two most common causes are a job never created and a job with no named owner; neither is something the cleaner could have acted on. Three checks take about five minutes and usually let you make a factual call instead of an accusation.

What if the job was created and assigned, and still was not done?

Then it is a capacity or attendance question, and it deserves a different conversation. Before having it, check whether one person was covering more units than one person can turn in a day: turnover cleaning runs roughly two to three hours for a one or two bedroom unit and three to five for a larger one, plus a recheck, so a four-unit day is not four units of work.

How do I stop the same unit failing repeatedly?

Give that unit a named owner for a month and count departures against jobs every morning. Repetition usually means creation is manual for that unit, or two similarly named units are being confused; both show up in a daily count within a week.

Is a shared queue ever fine?

For a one-person operation, yes, because owner and team are the same. The moment two people can see the same job, the queue needs a name on each item. A task that four people can do is a task nobody is doing, and nobody notices until a guest does.

An uncleaned unit is rarely a mystery and almost never a character problem. Count the departures against the jobs, read the unit field, check for a named person — in that order — and the answer is usually on screen before the guest has finished unloading the car. Reservations, availability and rates across Airbnb, Booking.com, Agoda and Trip.com belong in one calendar too: localsbnb.com.

---

Screen labels, role names and permission behaviour differ between products and versions, so confirm what applies in your own account. Turnover durations above are common industry ranges, not a standard. LOCALSBNB provides software, not legal advice.