Early-Bird and Last-Minute: Two Levers, One Calendar

One lever rewards planning and the other fills a hole. Run both on the same night and you've discounted twice for one booking.

Last updated: October 27, 2026

Two discounts can run on one calendar, but not on the same dates. The workable shape is three bands, not two: a far window that rewards early commitment, a hold band where the full rate does the work, and a near window that fills what's left. The hold band is the part most hosts skip, and it's the only thing standing between two levers and a double discount.

Key Takeaways

• The two levers do opposite jobs. One sells certainty months ahead. The other converts a date that would otherwise be empty. Priced as if they were the same product, both stop working.
• Build three bands, not two. Far, hold, near. The band where neither discount applies is what keeps the other two from meeting.
• A date inside both windows is a rule, not an accident. Decide at booking which single discount applies, and write it down where the next person to touch the calendar will find it.
• Never let one booking collect two levers. Stacking is the expensive failure, and it usually happens on the shoulder dates nobody was watching.
• Review each lever on net per night, with the bookings labelled at the time they arrive. A month-end reconstruction will tell you a story you can't check.

Two levers with opposite jobs

The early-bird rate buys certainty. You give up part of the rate on a date you're confident about, and in exchange you hold a booking months before you'd otherwise know. Its value is in the calendar being settled, not in the money arriving early.

The last-minute rate buys occupancy. By the time it applies, the question isn't what the night is worth — it's whether anything is coming at all. You give up part of the rate to convert a date whose realistic alternative is a dark night.

That difference sets their failure modes, and the failure modes are exact opposites. An early-bird window that runs too wide discounts dates that would have sold at full rate anyway, and does it months before you'd have known. A last-minute window that opens too early discounts dates that still had a real chance, and teaches the market to wait.

So the design question isn't which discount to run. It's where each one is allowed to be visible, and what sits between them.

Where the windows should stop

Picture the calendar as three bands rather than two windows.

The far band is where the early-bird rate lives. Its boundary is set by your own booking pace: it should close at the point where the bookings you're trying to attract would normally start arriving anyway. If your dates typically fill from a certain point in the countdown, a discount that runs past that point is paying for demand you already had.

The hold band is where the full rate applies and neither lever is visible. This is the band that pays for the other two, and it's the one that's almost never built. In the hold band, demand is real but not yet urgent: guests are booking, price is doing its normal work, and a discount here buys you a booking you'd have taken anyway at a lower number.

The near band is where the last-minute rate lives. Its boundary is set by the point where the realistic alternative to a booking becomes an empty night, not the point where you start feeling nervous. Those two dates are rarely the same, and confusing them is how a last-minute lever turns into a permanent low rate with a short name.

Each band's width comes from your own data, not from a competitor's calendar or a platform suggestion. Two units in the same building can have different boundaries if one takes weekend arrivals and the other takes midweek stays. That's not inconsistency; it's the bands reflecting different demand.

One test tells you whether the hold band is real: during it, the rate on the calendar should be the full rate, everywhere. If a weekly rate, a channel promotion or an old custom price quietly covers those dates, you don't have a hold band — you have one long discount with a gap in the naming.

The night both fire

The overlap is structural, and it happens for a boring reason: one window is measured from today and the other from the arrival date, so on shoulder dates they can both be true at once. A date six weeks out is deep inside the early-bird window and, once the calendar moves, inside the last-minute window too.

Three symptoms show up, in increasing order of cost. A guest sees two reductions on the same booking. A booking made early has its rate re-evaluated late, so the guest who committed in the far band ends up on the near band's number. Or the same date carries two different prices on two channels, because one of them has the far window loaded and the other has the near one.

The repair is a rule rather than a tweak. Decide, in writing, which lever wins when a date sits inside both: the far window for bookings made before a stated date, the near window for bookings made after it. One booking, one lever. The rule is about which discount applies — not about adding the two together, which is the version that costs you twice on one night.

Write it where the calendar gets edited, not in a document nobody opens in December. Two people managing dates will produce overlap by accident; a stated rule survives staff changes, and a rule that only lives in someone's head doesn't.

Then check that the rule is actually being applied, because the calendar is the only place the collision is visible. localsbnb.com shows each connected channel's own rate and its status next to yours, so a date where one channel has published the far-window price and another has published the near-window price reads as two different numbers on one line. That's the overlap, caught before a guest finds it.

A monthly look at what each earned

At the end of the month, count isn't the measure. Two levers can fill the same number of nights and earn materially different amounts, and the one that filled more is often the one that cost more.

Label each booking at the time it arrives with the lever that produced it — far band, hold band, or near band. That single field is the difference between attribution and storytelling: reconstructed at month end, every booking looks like it came from whichever lever you're currently defending.

Then compare net per night sold across the three bands, not the number of bookings. The far band should show a lower net per night than the hold band and a higher one than the near band; if it doesn't, one of the three is mispriced or mislabelled.

The harder question is the counterfactual, and it's worth asking once a quarter. For the far band: would these bookings have arrived anyway? Compare the booking pace in the discount window with the same window in a period when no early rate was running. For the near band: would these nights have sold at the full rate? Look for enquiries on those dates during the hold band — a date that had interest and still went to the last-minute rate is a date you discounted too early.

The month's shape then has two readings, and they answer different questions. Occupancy, ADR and RevPAR tell you how the month went as a whole; LOCALSBNB reports all three per unit, so a month where occupancy rose while ADR fell is visible as one movement rather than two arguments. The band split tells you which lever produced that movement. Read the second only after the first, or you'll be explaining a lever's performance with a number that includes both.

FAQ

Can I run an early-bird rate and a last-minute rate at the same time?

Yes, and most hosts with a full calendar do. The condition is that the two never touch: a hold band of dates at the full rate has to sit between them. Remove the hold band and the two windows begin to overlap, which is the state where a single booking can collect both levers.

What do I do with a date that's inside both windows?

Apply the rule you wrote, not the deeper of the two discounts. If you haven't written one, the simplest version is by booking date: bookings made before the far window closes get the far window's rate, bookings made after get the near window's. One booking, one lever, whichever band the guest booked in.

How do I know which lever actually filled a night?

Label the booking when it arrives, then compare net per night across the three bands at month end. If you didn't label it at the time, the next best evidence is the booking date against the window boundaries — but a month of guessing is a month of attribution you can't defend, so start labelling from the next booking.

Two levers on one calendar is a design problem before it's a pricing problem, and the design is mostly about the space you leave between them. localsbnb.com keeps each connected channel's rate and status on one calendar, which is where a date that has slipped into both windows shows up first.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Discount rules, platform terms and local pricing rules differ by market and change over time. Confirm the current terms of each channel you use and the current rules with the competent authority before you set or publish a rate.