When a Guest Extends: Pushing New Nights Everywhere

An extension accepted in one place is a double booking waiting in another. The fix is order, not speed.

Last updated: October 21, 2026

A guest messages at ten at night asking for two more nights. You want to say yes, and the answer feels obvious. But the two nights are still on sale on three other channels while you type, and the next guest can book them in that gap. The fix isn't answering faster. It's doing three things in the right order.

Key Takeaways

• Answer last, not first. The reply is the end of the process, not the start of it.
• Hold before you push. Take the nights out of sale in your own calendar, then change the channels.
• Every channel, every time. A push that misses one leaves the nights bookable somewhere you aren't looking.
• A person still confirms the write. Extension changes aren't a good candidate for hands-off automation.
• Leave a line for the next turn. Who confirmed what, and which channel is still stale.

The order that prevents a double booking

Three moves, in this sequence: hold, push, confirm.

Hold the nights in your own calendar. Before you type anything to the guest, block the two nights on the unit so they can't be sold. A hold isn't a promise to the guest, and it isn't a booking. It's the removal of inventory, and it's the only move that works even if everything after it fails.

Push the new dates to every channel. Change the availability on each channel the unit sells on, so the two nights come off sale everywhere at once. Do this before you reply, because the reply is what creates the expectation. If a channel fails or the change doesn't take, you still have time to fix it while the guest is waiting for an answer.

Confirm with the total. Only now do you message the guest. Yes, the nights are available, here's the new total, here's what it covers, and here's when payment or the amendment goes through. The confirmation is the last step, and it's also the only step the guest ever sees.

Reverse the first two and you get the common failure. The host replies yes because the guest is waiting, then goes to update the channels, and finds that the second night was booked forty minutes ago on a channel they hadn't opened. The guest has a promise, the other guest has a confirmation, and the host has a relocation problem.

There's a subtler version. The host holds the nights in one channel's extranet and assumes the other three follow, because they usually do. Usually isn't a control. Each channel is a separate place where the unit is for sale, and each needs its own change.

Speed isn't the variable here. A careful host who takes ten minutes and touches every surface beats a fast host who answers in ninety seconds and updates two channels out of four. The guest's real need is certainty, not immediacy, and certainty arrives with the third message.

What the calendar has to show

The push only works if you can see, in one place, whether it landed.

Four things need to be visible per night: the channel, its status, its rate, and whether the night is still open for sale. Without the last one you're pushing blind, and a channel that accepts the change but keeps the night live looks identical to one that closed it.

On localsbnb.com, the calendar shows the source rate and status of each connected channel beside the dates, so a night still open on one channel sits next to the three that closed. That's the view that tells you a push is finished rather than started.

Watch for the two shapes that cause trouble. The first is a night that closes on the calendar but stays open on a channel because a rate plan or a minimum-stay rule blocks the update. The calendar says one thing, the channel does another, and only the channel can take a booking.

The second is the extension that runs into a blocked night. If the two extra nights overlap a maintenance block, an owner stay or another booking's arrival, the extension isn't a push problem at all. It's a decision about moving someone, and no amount of refreshing the calendar will resolve it. Find that out before you reply, not after.

Where confirmations still need a human

Extension changes are a poor candidate for hands-off automation, and the reason is the pricing.

Two more nights on the end of a stay aren't priced like two nights in the middle of a month. The weekend rate may apply to one of them and not the other. A minimum-stay rule on a channel may reject a two-night addition even though the original booking was fine. A cleaning fee that was charged once shouldn't be charged twice, and a weekly discount may or may not still apply at the new length.

None of that is a decision software should make quietly on your behalf, because the guest will read the total and hold you to it. In LOCALSBNB, write actions apply to overseas stores only, and each one waits for a person to confirm it. That constraint is a feature here: the person confirming is the person who priced the nights.

Three other places need a human. The message itself, because an extension is often the moment a guest asks for something else — a late checkout, an extra key, a cot. The payment, because an extension changes the amount and sometimes the schedule. And the exception, because the guest who asks for two nights and gets one is a conversation, not a system state.

There's a useful test for whether a step should be automatic. If getting it wrong produces a message you'd have to apologise for, keep the person in the loop. An extension that overcharges by a weekend rate is exactly that kind of message.

The note to leave for the next turn

Most extensions don't fail on the night they're agreed. They fail the next morning, when somebody else picks up the thread and can't tell what actually happened.

So write one line where the next person will look, and make it four facts long: what changed, what was confirmed to the guest, which channels were updated, and what's still open. Something like: two nights added, guest confirmed at the new total, three channels closed, the fourth pending a rate-plan error.

That line does three things. It stops a second confirmation going out with a different number. It tells whoever checks the calendar tomorrow which channel to verify first. And it creates a record you can read a month later when the guest asks why the last invoice looks different.

Keep it in the same place every time. A handover note that lives in three apps is a note nobody reads, and the morning after an extension is exactly when nobody has time to hunt.

None of this makes overbooking impossible. A channel can accept a booking in the seconds between your check and the guest's arrival, and a rate-plan error can reopen a night you closed. What the order buys you is a smaller window and a visible one, plus the ability to say honestly what you did and when.

FAQ

Can I just say yes and update the calendar after?

You can, and it works most of the time. The nights are still on sale during the gap, though, and the gap is longest exactly when you're busiest. Holding first costs a minute and removes the failure mode entirely.

What if one channel won't accept the change?

Then keep the hold in place and treat that channel as the open item. Don't confirm to the guest until it's closed, or confirm with a clear caveat and a time by which you'll have an answer. A night that closes everywhere except one channel is still a night for sale.

Does an extension change the cleaning schedule?

Usually yes, and it's the step people forget. A longer stay moves the checkout, which moves the turnover, which may collide with the next arrival. Update the cleaner's date in the same pass as the channels, or you'll have a clean unit with a guest still in it.

The whole method is three moves and one line of writing, and it costs about ten minutes. That's a small price for not spending the next morning relocating somebody. If the letting side is where your nights already live, localsbnb.com is the place to keep the calendar that the push is checked against.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. What an extension does to a guest's rights, to a local stay limit or to a tax position differs by jurisdiction and by booking. Confirm the current rules with the competent authority and the current terms of each platform you use before you amend a stay.