The Guest Who Won't Leave: A 37-Day Case and What Followed

A stay that runs past its end date is a process problem before it is a legal one. The first four days decide the rest.

Last updated: October 31, 2026

A booking has an end date. A room doesn't empty itself on that date. Between the two sits a stretch of hours where nothing has formally happened yet, and what you do in those hours sets the shape of everything after. In the case this piece is built on, a stay that should have ended on a Tuesday ran for thirty-seven days.

Key Takeaways

• The end date is a date, not an event. Nothing changes in the room when the calendar turns over. Only your record knows what was supposed to happen.
• The first twenty-four hours are for facts. Restate the date in writing, look at the unit, and skip the argument you're tempted to have.
• A record made in order beats a case made late. A timestamp does more work than an adjective, and it's harder to argue with.
• Escalation feels like progress and usually isn't. The loud step is the one that's hardest to walk back.
• Where the stay turns into a tenancy question, the call isn't yours. Put the file in order and take it to the competent authority.

What the calendar said, and what the room said

On the system side, everything is tidy. A reservation carries a checkout date. The guest has a phone number that worked when they booked. On the morning of departure, the room shows up on a list of rooms that should be empty by eleven.

That list is useful, and it's also where the trouble starts, because it describes an expectation rather than a fact. The room is due out. The guest is still in it.

On the ground the picture is messier. There's a bag by the door and a person attached to a story. Sometimes the story is good: a cancelled flight, a hospital visit, a job that ran three days long. Sometimes there's no story at all, which is the harder version, because there's nothing to negotiate with.

The damage happens in the gap between those two views. An owner who reads the system and assumes the room is empty stops watching the room. An owner who reads the room and assumes the system will catch up stops writing things down. Both mistakes come from trusting one half of a situation that has two halves.

A read-only view of today's arrivals, who's in house and which rooms are due out gives you the one thing you actually need in that moment: a fixed point. It tells you the room should have turned over at a stated time. Write the time down. Later, that timestamp will be the hardest line in the file to argue with.

The first twenty-four hours

Three moves, in this order. None of them is a threat, and that's deliberate.

Restate the date in writing, on the channel the booking came through. Give the checkout date and the time, then ask what they need. A question gets an answer. A demand gets a position, and a position is much harder to move than an answer.

Then look at the room. Not to build a case — just to know what's there. How many people, how much luggage, whether anything's been changed. Photograph it if you can do that without a confrontation. If you can't, note the time you looked and what you saw. A sentence written at 10:40 that morning is worth more than a paragraph written three weeks later.

Then decide nothing. Twenty-four hours is enough to learn which kind of case you have. A guest with a problem wants a date that works and will usually take one. A guest with a plan wants ambiguity, because ambiguity is what buys time. Those two need different handling, and you can't tell them apart on the first morning.

localsbnb.com holds Airbnb, Booking.com, Agoda and Trip.com on a single calendar, so the departure date you quote back to someone is the same date every channel is showing. That consistency matters more than it sounds. A guest who can point to two different dates on two platforms has an argument. A guest who can't has a conversation.

Documenting without escalating

What goes in the file: the booking record, every message in order, the times, who said what, photographs with their own timestamps, and a flat note of what you did and when you did it.

What stays out: opinion. "Guest is being difficult" isn't a fact, and it makes the rest of the file read like it was written by someone with a grievance. "Guest said on 14 October at 09:12 that they'd leave on 15 October, and didn't" is a fact, and it does the work by itself.

Keep one folder and one index. Name files by date, not by feeling. If a second person is involved — a co-host, a cleaner, a neighbour — write down what they saw and when, with their name on it. Their account will be worth more than yours later, precisely because they've got nothing riding on the outcome.

Then there are the steps that remove access. Changing a lock code, cutting power, moving belongings out. These are the actions most likely to be examined later by someone who isn't you, and they're the ones that turn a scheduling problem into a dispute. They belong at the end of the sequence, after you've taken advice — not at the start, where they feel decisive.

One more thing about the system side. A checkout or a room change isn't something the software does on its own. The write step waits for a person to confirm it, and it's built for overseas properties. That's the right order of operations. What's on the screen should follow what happened in the room, never lead it.

The threshold that ends it

People ask for a number. There isn't one that holds everywhere, and the one that applies where you are depends on rules that change and on the facts of your particular case. That's a bad combination to guess at.

What you can watch is the shape of the conversation. It shifts before anything else does.

The guest stops asking for more time and starts asserting a right to stay. They won't put an end date in writing — or they put one and break it without comment. Other people arrive, or more belongings do. They stop answering and start recording. Any one of those moves the question out of operations and into something else, and that something else isn't yours to settle.

At that point the useful move is the dull one. Stop negotiating on your own judgment. Put the file in order. Then put the question to the competent authority where the unit sits — the body that handles housing questions in your area — and to a local adviser who works with that body regularly.

After that, your job narrows. Answer inside whatever deadlines they set. Keep doing what the file says. Don't try to win the argument in the corridor.

Most owners get this backwards, and it isn't a matter of nerve. It's a matter of sequence. The person who documented first and asked second gets a clean answer. The person who escalated first and documented later spends the following month explaining why the record starts in the middle.

FAQ

Can I change the lock once the booking has ended?

Not as a first move. It's the step most likely to be reviewed by someone other than you, and the one that turns a scheduling problem into a dispute. Ask the competent authority what you're allowed to do, and in what order, before you remove anyone's access to the unit.

Do I have to let them stay while I sort it out?

That's set by local rules and by the facts of the case, and it isn't something to settle from an article. What you control is the record and the speed of your questions. Get the file in front of the right body early, and keep track of the dates they give you.

What if the guest stops answering?

Keep writing on the same channel anyway, dated and short. A silent guest plus a documented sequence is a far stronger position than a silent guest plus an empty inbox. Don't switch to a private number to chase a reply — stay where the record is.

The case behind this piece closed at thirty-seven days, with a file that ran to a few pages and read like a maintenance log. That's the target. Not a clever argument, a boring one that's in order. When the room does turn over, localsbnb.com is where the calendar and the channel data sit, so the next departure date is one you can point to rather than reconstruct.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Rules on occupancy, notice and access differ by place and change over time, and nothing here decides whether a particular stay has become a tenancy. Confirm the position with the competent authority and a local adviser before you act on a guest who has stayed past their date.