Every property manager has had this conversation. An owner calls in March and says they want the house for the last two weeks of July. The manager says sure, blocks the calendar, and moves on. Nobody writes down what those two weeks were worth. Nobody could, because at that point they don’t know.
Then the year ends, the property comes in under its revenue target, and the same owner wants to know why.
This post is about that gap. It’s about why blocked days are one of the biggest unsolved problems in short-term rental revenue management, why the tools most of the industry uses can’t solve it, and what a real answer looks like.
Hotels don’t have this problem
The single biggest structural difference between STR and hotels isn’t the size of the property or the length of stay. It’s ownership. A hotel owns every room it sells. An STR manager sells rooms that belong to somebody else, and that somebody else gets to use them for a portion of the year.
So STR owners block off a lot of inventory. Holidays, summer weeks, a weekend for the in-laws, a month for renovations, sometimes an entire off-season because they’d rather not deal with guests. Across a portfolio this adds up to a meaningful share of the calendar that was never available to be sold.
A hotel room is either sold or it isn’t. Either way the record is clean. An STR night can be sold, unsold, or unavailable, and that third state is where the trouble starts.
Two problems, not one
Blocked inventory causes two distinct problems for revenue management, and it’s worth separating them because they have different fixes.
Problem one: the model goes blind
Revenue management demand models run on historical data. The more booking data a model can ingest, the better its chances of forecasting the future. That’s the whole game. A demand curve is nothing more than a record of how many people were willing to pay how much on similar days in the past.
When an owner blocks a night, the economic value of that night cannot be determined. The night didn’t book. But it didn’t book because it couldn’t book, not because nobody wanted it. From the outside those two outcomes look identical. A model that treats blocked nights as unsold nights will conclude that demand was lower than it was, and it will price the next year too low. A model that throws blocked nights out entirely is working with a smaller, gappier dataset and gets less confident about everything.
Either way the forecast gets worse. And this is not a small effect. If 15% of a property’s calendar is blocked in a given year, that’s 15% of the training data for next year that is either missing or lying.
Problem two: the revenue goal takes the hit
The second problem is simpler and has nothing to do with math. Blocked inventory prevents the property from hitting its annual revenue goal. Every blocked night is a night that cannot produce rent. At the end of the year the owner is looking at a number that is lower than it could have been, and very often they’ve forgotten that they were the reason.
This is a communication problem as much as a revenue problem. The manager knows the blocks cost money. The owner half-knows it. Nobody has a number.
Why the industry settled for less
The first problem is the reason forecasting in STR has been so hard, and it’s why the industry has been forced to settle on base rate adjustment tools instead of real price optimization engines.
Hotels and airlines have been running expected marginal seat revenue (EMSR) models for decades. These models work by estimating the probability that a unit will sell at a given price, then protecting inventory for the higher-paying demand that hasn’t shown up yet. They are extremely good at what they do. They are also completely dependent on knowing, for every unit on every day, whether it was available to sell.
Drop those models into STR and they fall apart. The availability assumption is broken. The historical demand signal is corrupted by owner blocks. So instead of optimization, the industry built tools that start from a base rate the manager sets by hand and then nudge it up or down based on seasonality, day of week, lead time, and what the neighbors are charging. That’s useful. It is not the same thing as knowing what a night is worth.
Getting a number
There are a few ways to overcome this challenge, and they all start in the same place. You need to estimate what the blocked inventory was, or is, worth in the market.
Once you have that estimate it does two jobs.
First, it lets you evaluate the forecast. If the model says a blocked Saturday in July was worth $310, you can compare that against what the unblocked Saturdays around it actually booked for and see whether the model is calibrated. Blocked nights stop being holes in the data and become test cases.
Second, it gives you the best available answer for the owner. When they ask what that week was worth, or what they’ll forgo if they leave it blocked, you have a defensible number instead of a guess.
The simple formula, and why it’s wrong
The simple version is to tell the owner the value of a blocked day is equal to the rate they are currently charging. The night was listed at $400, so blocking it cost $400.
This is somewhat reasonable and it is what most people do. But it doesn’t map to reality.
The value of the day is only equal to the price if there is a 100% chance you get booked at that rate. That is never the case. Some nights have a 90% chance of booking. Some have a 15% chance. Telling an owner that a shoulder-season Tuesday cost them the full listed rate is overstating it, and they know it, which is exactly why they stop trusting the number.
There’s a second problem with the simple formula that’s less obvious. If you really did have a 100% chance of booking at your listed rate, you’re priced too cheaply. Full certainty of selling is a sign you left money on the table. So the simple formula is wrong in both directions: it overstates the value of soft nights and it quietly assumes a pricing strategy you shouldn’t want.
The better formula
The better formula is that the value of a day is equal to the price times the probability of getting booked at that price.
Value of the day = Price × Probability of booking
This is the expected value of the day, or days, that are getting blocked. Two examples:
- A $400 night with a 60% chance of booking is worth $240.
- A $400 night with a 20% chance of booking is worth $80.
Both show up as $400 nights on the calendar. They are not worth the same thing to the owner, and an owner who is deciding whether to use the house or rent it deserves to know the difference. Blocking the first night is a real sacrifice. Blocking the second one is nearly free. That’s useful information, and it changes behavior. Owners who see the expected value tend to shift their personal stays toward the nights that were unlikely to book anyway, which is a win for everybody.
Why this needs a probability model
Here is the catch. To use the better formula you need the probability, and the probability is exactly what base rate adjustment tools don’t produce.
A rules-based tool can tell you a price. It can’t tell you the odds of getting it, because it never modeled demand in the first place. It applied adjustments to a starting number. So anyone using that class of tool is stuck with the simple formula and all of its problems.
Calculating expected value is a unique capability of probability-based demand models. If the model is built to estimate how likely a night is to book at each price point, which is what it needs to do to optimize price in the first place, then the expected value of any night falls out for free. You don’t build a separate feature for it. It’s already there.
How we use it
For Quibble clients, expected value is a natural output of the pricing model. Every night on the calendar carries both a price and a probability, so every night carries a value, whether it is open, booked, or blocked.
We use that to solve both problems described above.
On the forecasting side, blocked nights get an estimated value instead of a blank. The model doesn’t have to choose between treating them as unsold or discarding them. That keeps the historical picture intact and makes it possible to check the forecast against the market even where booking data is missing.
On the communication side, it gives us a clear number to put in front of an owner. Not “you blocked two weeks in July,” but “the two weeks you blocked in July had an expected value of $5,800.” That is a very different conversation. It respects the fact that the house belongs to them and they can use it however they want. It just makes sure the decision is made with the cost in view.
The takeaway
Blocked days aren’t going away. Owners bought these properties partly to use them, and no revenue manager should be in the business of talking them out of it.
But a blocked day is not free, and it is not worth the sticker price either. It’s worth what it would have earned, weighted by how likely it was to earn it. Until you can put that number on the table, both the forecast and the owner conversation are running on guesswork.
The industry has spent a long time working around this problem instead of solving it. The math to solve it has existed for decades. It just needed a model built for the way STR actually works.