Length-of-stay strategy: MLOS, CTA, CTD

Late April. Adam walks into the morning meeting in a great mood: “Have you seen it? Saturday May 26 is sold out — five weeks ahead! The stadium concert is going to make our month.”

Daniel doesn’t share the enthusiasm. He opens the calendar view: Saturday 100%, Friday 40%, Sunday 30%. And the more telling number: of the 80 bookings touching Saturday, 70 are one-night stays — the day’s ALOS is a mere 1.1 nights.

“Adam, this isn’t good news. It’s a trap. Our Saturday is full of one-night concert guests — and from now on we turn away every guest who would bring Friday or Sunday with them. Anyone searching for Friday–Saturday sees one thing at our hotel: no availability. They go to the Danubea — and take their Friday night with them.”

A full house is not always a win. This lesson is about how to control the length and pattern of stays — because the revenue optimum is decided not in days but in stay patterns. The toolkit is three acronyms: MLOS, CTA, CTD.

The third lever

So far on the advanced level we have worked with two main levers: price (lessons 35–36, dynamic pricing) and capacity allocation (lessons 40–41, displacement and the group ceiling). Length-of-stay (LOS) strategy is the third lever: it controls not how much we sell a room for, or to whom, but in what pattern. We laid down the basics — LOS, ALOS and a first look at the three restrictions — in lesson 11; now comes the day-to-day application.

Why does this need its own lever? Because demand arrives night by night, but the guest thinks in stays. A peak date (a concert Saturday, a trade-fair Tuesday, New Year’s Eve) pulls in one-night demand — and if we let that demand fill the house, the peak becomes isolated: the surrounding days stay empty, while the very fullness of the peak locks out the multi-night guests.

The three tools

MLOS — minimum length of stay

MLOS (minimum length of stay): a booking is accepted for the given date only if the stay reaches the specified number of nights. A Saturday MLOS-2 means: no one-night bookings for Saturday — two nights or more.

It comes in two variants, and the difference matters:

• Arrival-based MLOS: the rule binds only guests arriving on that day. A Saturday arrival MLOS-2 demands a minimum of 2 nights from anyone arriving on Saturday — a guest arriving on any other day is not affected.
• Stay-through MLOS (also called “min stay through”): the rule applies to every stay that touches that night — whichever day the guest arrives.

Against a one-night booking the two variants protect identically (the one-night Saturday guest arrives on Saturday — both catch them). The difference shows up at higher MLOS values and multi-day events: with a Saturday MLOS-3, the arrival variant lets through a two-night Friday–Saturday guest — the rule does not bind them — while the stay-through variant blocks them, because their stay touches the protected Saturday night but is shorter than required. The longer the pattern you want to enforce, the more the stay-through variant is the precise tool. Not every PMS and channel manager supports both — check before you implement.

CTA — closed to arrival

CTA (closed to arrival): no one can arrive on the given day, but guests who arrived earlier and stay through remain, spending that night in the hotel without any issue. A Saturday CTA says: no check-in on Saturday — whoever wants the Saturday night arrives on Friday (or earlier).

Two typical uses:

• Protecting the peak for the benefit of the shoulder days. The New Year’s Eve CTA is the classic: arrivals closed on December 31, so whoever wants to celebrate arrives on the 30th — and brings two nights.
• Operational relief. If 60 rooms would turn over on a single day (check-out and check-in the same day), housekeeping and the front office collapse. A CTA spreads the arrival peak across the surrounding days.

And just as important is what a CTA does not do: it does not block the sale of that night. A guest arriving Friday for a Friday–Sunday stay books without any problem alongside a Saturday CTA — that is exactly the pattern we want to see.

CTD — closed to departure

CTD (closed to departure): no one can check out on the given day. A Saturday CTD says: no check-out on Saturday — whoever arrives on Friday stays at least until Sunday.

This is the most rarely used tool, because it is the most aggressive: it is hard for the guest to understand (“why can’t I go home on Saturday?”), and it can render confusingly in booking engines. Its typical terrain is the resort and festival business, where the house runs in fixed blocks; in a city hotel it is rare. Its effect partly overlaps with the MLOS: the one-night guest arriving Friday — who would leave Saturday morning — is blocked by a Saturday CTD just as by a Friday MLOS-2.

The stop-sell is not a LOS tool

The fourth switch, the stop-sell (closing the day entirely), does not belong in the LOS toolkit: it blocks everything, multi-night patterns included. A common mistake is for a hotel to simply close a “nearly full” peak date — losing precisely the Friday–Saturday–Sunday-pattern guest the whole LOS strategy works for. The restriction is a scalpel; the stop-sell is an axe.

The concert Saturday in numbers

Back to May 26. Let’s model both scenarios end to end — this is the lesson’s mandatory worked example, and it is worth following slowly, because the entire logic of LOS strategy is in it.

The demand picture, estimated from the historical curve and the pace (with the methods of lessons 37 and 39):

• One-night Saturday demand (the concert): 70 rooms. If we touch nothing, they book at the 118 EUR Saturday BAR.
• Two-night demand touching Saturday: 35 rooms — 10 of them already booked early (5 Friday–Saturday, 5 Saturday–Sunday), 25 would come later (15 Friday–Saturday, 10 Saturday–Sunday). The two-night patterns average ~108 EUR/night in the rate mix.
• Standalone Friday demand: 36 rooms (~95 EUR); standalone Sunday: 28 rooms (~88 EUR).

The model is stylised — we work with round numbers so the mechanics show — but every element maps to a real situation.

Scenario A — no restriction

This is the “do nothing” base case: the rate stays at the 118 EUR BAR, there is no restriction. The concert demand is fast, and five weeks before arrival it fills Saturday: 70 one-nighters + the 10 early two-nighters = 80 rooms — exactly the opening scene of this lesson. The 25 two-night guests arriving later no longer fit: their search dies on the full Saturday, and they end up at a competitor — taking their Friday and Sunday nights with them.

A full house on Saturday — and a 64% weekend.

Scenario B — stay-through MLOS-2, timed

Let’s rewind the clock. In scenario B, Daniel catches the spike not five but eight weeks before arrival — at the point where the pickup report first shows Saturday breaking away from the surrounding days, and only the 10 early two-night bookings sit on the books. That is when he puts a stay-through MLOS-2 on the Saturday night. What happens?

1. Part of the one-night demand converts. In the model we assume ~30% of the concert guests are willing to stay two nights if that is the only way to get a room: 21 rooms (13 Friday–Saturday, 8 Saturday–Sunday, at the ~108 EUR pattern average). The other 49 do not book for now. The conversion rate differs from event to event — which is exactly why you do not “set it and forget it”, you watch what it does.
2. The two-night demand gets in. The 25 later two-night guests now find space (15 Friday–Saturday, 10 Saturday–Sunday).
3. Two weeks before arrival, Daniel reviews. Saturday stands at 10 + 21 + 25 = 56 rooms (70%), and Friday and Sunday have been built up by the patterns. On the remaining 24 Saturday rooms he lifts the MLOS and raises the rate to 135 EUR — in the compression demand of the final two weeks before the concert, the remaining one-night guests book at this BAR, and the house fills.

The comparison

The lesson is twofold. First: Saturday itself lost nothing (−52 EUR — rounding noise) — the entire gain came from filling Friday and Sunday. The value of a restriction never shows on the day you set it on, but on its neighbours. Second: scenario B is not a single decision but a timed sequence — restriction early, review along the way, release at the right moment, combined with pricing. This is the most important, and most often botched, element of LOS strategy.

And an honest footnote: in scenario B, of the 49 one-night guests who bounced, only 24 came back after the release — 25 were lost for good. That is the real cost of a restriction. In the model it was well worth it, but you need to know that, not feel it — which is what trap 5 is about.

Price or restriction? The order matters

A restriction is a hard tool: demand rejection. Before you deploy it, always ask: can price solve this?

The price-based alternative is length-projected pricing — exactly the DCAL ladder we built in lessons 33–34: a high rate on the one-night Saturday cell (the concert demand’s willingness to pay is high — we monetise it along the demand-elasticity logic of lesson 36), a friendlier average rate on the multi-night patterns. If the one-night guest will pay 145 EUR, part of the problem solves itself without a restriction — at higher revenue.

The practical order:

1. Price first — collect the premium of the one-night peak demand, with LOS-differentiated cells rather than one blunt BAR increase.
2. If price is not enough — because the demand is price-insensitive and its volume is still crowding out the patterns — then comes the restriction.
3. The two combine: an MLOS early in the booking window + a high BAR for the one-nighters after the release. That is precisely what Daniel did in scenario B.

In lesson 33 we put it this way: the MLOS is a binary switch, and DCAL does the same thing with price. The two are not rivals — DCAL is the fine-tuning, the restriction is the enforcing power for the dates where price alone cannot reshape the pattern.

The classic traps

Trap 1: set-and-forget

The most common mistake: the restriction stays in after the demand picture has changed. The concert gets cancelled, the pace stalls — and the MLOS-2 is still blocking one-nighters on a Saturday sitting at 60%. Every restriction comes with a review date. In lesson 24 we saw the habit trap (“Saturdays always get MLOS-2”) — set-and-forget is its twin in time: setting a restriction is a responsibility, forgetting it in place is revenue destruction.

Trap 2: a restriction on a weak-demand day

An MLOS only works if there is something to protect and something to convert from. An MLOS placed on a 50%-demand day simply rejects half the demand, with no compensation. The restriction is a tool of excess demand — weak days belong to price and promotion.

Trap 3: mixing up arrival and stay-through

Whoever sets an arrival-based MLOS with stay-through intent leaves a loophole: short stays that touch the peak night but arrive earlier slip through. The other way around you get over-restriction: the stay-through variant binds guests you never meant to lock out. Before you set it, find out which logic your PMS and channel manager run — and test it with a trial booking.

Trap 4: unverified channel distribution

The channel manager pushes the restriction out to the OTAs — but not every channel displays every restriction type the same way. On some, an MLOS-restricted date simply shows as “not available” in search, which can hurt visibility even in two-night searches — the very guests you want. After distribution, check the guest-facing display channel by channel.

Trap 5: not measuring the rejected demand

The cost of a restriction is the rejected demand — which never shows in the PMS, because the booking was never born. In lesson 39 this had a name: denial — the hotel says no, because of a full house or an active restriction. Search data from the booking engine and OTA analytics give you an estimate: how many people searched for a pattern the rule blocked. Without it, the restriction decision flies blind — run the A/B comparison (like the one above) at least after the fact, on actuals.

Manually vs. Peaqplus

Recognising the pattern manually requires cross-referencing PMS reports: occupancy by arrival date + length-of-stay distribution + the state of the surrounding days — assembled by hand, weekly. In most hotels this never happens, and the concert-Saturday trap surfaces in the week of arrival — when it is too late.

In Peaqplus the pattern shows early. Pickup shows, day by day, which date is breaking away from its surroundings; the Same Point comparison shows how far ahead Saturday is running against the same point last year while Friday and Sunday lag — that is the “isolated peak” signal. The response side lives in the system too: the Pricing Engine raises a rate suggestion for the compression date and also manages the LOS restrictions — MLOS, CTA, CTD — so recognition, the price response and the restriction setup happen in one place; the restriction spreads to the channels through the channel manager (D-Edge, Cubilis, etc.). And for the review–release cycle — the key to scenario B — Pickup provides the daily feedback: is the pattern converting, are the shoulder days filling.

Key takeaways

• LOS strategy is revenue management’s third lever, next to price and capacity allocation: it shapes the stay pattern. A peak date optimised only for itself becomes isolated and leaves its neighbours empty.
• MLOS = minimum length of stay, with arrival or stay-through logic — and the two are not the same. CTA = closed to arrival (the stay-through guest remains). CTD = closed to departure. The stop-sell is not a LOS tool: it kills the good patterns too.
• A restriction’s value is realised on the surrounding days: in the concert-weekend example, Saturday revenue was practically unchanged (−52 EUR), while the three days together gained +30% and +19 pp occupancy.
• A restriction is a timed sequence, not a one-off setting: early introduction → review along the way → release to sell the remaining capacity. Every restriction comes with a review date.
• Price first, restriction second: the one-night peak premium can also be collected through DCAL cells — the restriction comes when price alone cannot reshape the pattern. Its cost (the blocked demand) is measurable from denial data.