When to Override Dynamic Pricing (and When to Leave It Alone)
Automated pricing handles averages well and context badly. This guide names the five date types a pricing rule cannot see, gives a one-minute test for deciding whether to override, and shows how to measure whether the override paid.
Automated pricing is good at averages and blind to context. The skill is knowing which dates are context.
Last updated: September 19, 2026
Automated pricing reads a demand curve and moves your rate along it. It is fast, consistent, and unbothered by the fact that you are tired on a Sunday. What it cannot do is know anything that is not already in the data it was given: a festival that moved cities, a boiler service you booked for Tuesday, a cleaner who just put their price up. An override is how you put that information back in. The risk is not overriding, it is overriding without a rule, which turns a pricing system into a mood ring. This guide sets out what the engine is actually optimising, the five date types it structurally cannot see, a one-minute test to apply before you touch a number, and a way to judge whether the change worked. Where a figure depends on your market, confirm the current terms rather than assuming.
Key Takeaways
- The engine optimises a forecast, not your business. It moves rate against predicted demand, using history, lead time and pace, and it has no view of your costs.
- Five date types defeat any rule. One-off events, dates next to your own blocks, cost changes, fee and tax changes, and rate plan changes.
- Write the test before you write the rate. Four questions, one minute, and most overrides answer themselves.
- Judge an override on net payout, not on whether it sold. A night that sells below your floor is not a win because it sold.
- Keep a log. An override you cannot review next season is a guess you have to make twice.
What a pricing engine actually optimises for
A pricing rule is not trying to guess the highest price a guest would pay. It is trying to maximise expected revenue across a window, which usually means it would rather sell at a slightly lower rate than hold out and go dark. That is a defensible objective, and it is also the reason automated pricing feels timid in a strong week: the model is pricing the risk of an empty night, not the upside of a full one.
The inputs are narrower than most hosts assume. A typical engine reads your own booking history, the pace of bookings against the same dates last year, day-of-week patterns, lead time, seasonality, and some view of comparable listings. Everything it reads is a pattern. Anything that happens once is invisible to it.
There is a second blind spot worth naming: the engine does not own your costs. It has no idea that your cleaner charges more on a Sunday, that a four-night stay costs you one turnaround while four one-night stays cost you four, or that a channel takes a share of the whole subtotal. Those are your numbers, and they are exactly the numbers an override exists to protect.
The five date types a rule cannot see
| Date type | Why the rule misses it | What to do instead |
|---|---|---|
| A one-off local event | No historical analogue, so the demand curve has nothing to learn from | Set the rate by hand for the event window, then let the engine resume |
| A date next to a block you created | The engine sees a gap, not the maintenance, owner stay or long booking that caused it | Price the shoulder night to fill, or close it deliberately |
| A date where your own cost changed | Cost is not an input at all | Recompute the floor and re-derive the rate above it |
| A date after a fee or tax change | The rule keeps optimising against an old retained share | Reprice in bulk from the change date forward |
| A date covered by a new rate plan | The engine does not know you changed minimum stay or inclusions | Check the plan before you check the number |
The fourth row is the one most hosts are carrying right now. Airbnb's single host-paid service fee of 15.5% took effect outside the EEA on 15 September 2026 and takes effect inside the EEA and Switzerland on 13 October 2026, and it is charged on the whole booking subtotal, cleaning and pet fees included. Holding your previous payout means dividing your target net by 0.845, roughly an 18.3% gross-up, not multiplying the old rate by 1.155; third-party industry calculations put the equivalent price rise at about 14.8%. That is a bulk edit, not a per-date judgement, and it is the kind of change a single calendar makes cheap: you can start free at localsbnb.com and see every connected channel's rate and status in one view before you reprice the rest of the quarter.
A one-minute override test you can apply
Before you type a number, answer four questions in order. If you cannot answer the first one, stop; the override is an impulse.
- What do I know that the data does not? Name the fact. "It feels slow" is not a fact; "the conference moved to my street this year" is.
- Does the change move my net payout the right way? Convert to net before you commit. Under the single fee, a rate that looks 10% higher may deliver less than the rate it replaced once the subtotal base and tax treatment are applied.
- Is the change reversible before it costs me? An override applied to a date 90 days out is cheap to undo. One applied to a date nine days out is a bet on a window that is already closing.
- Am I overriding a number or a mood? If two comparable dates got opposite treatment this week, you are managing anxiety, not price.
Two answers out of four is the working threshold: if you can name the fact and confirm the net direction, the override is worth making. If you can only name the mood, leave the rate alone. The discipline matters more than the particular number, because a pricing system you override inconsistently gives you neither its judgement nor your own.
How to tell whether an override worked
The obvious measure is wrong. "The night sold" tells you demand was there, and not whether your override captured it or gave it away. Judge the change on three measures instead.
First, realised net payout per occupied night against the same measure for comparable dates you left alone. Second, the pace of the booking: a good override usually converts earlier than the surrounding dates, not later. Third, the neighbouring nights. An override that fills one date by draining the two beside it has moved revenue around rather than added it.
Your dashboard is the place to read all three. Occupancy, average daily rate and revenue per available night belong together, because each one alone can be flattered: occupancy rises when you cut price, ADR rises when you lose your cheapest bookings, and only RevPAR keeps the two honest. Review monthly, and read OCC, ADR and RevPAR as a set rather than picking the one that improved.
Keeping a log so the second year is easier
An override log needs three columns: the date or range, the fact you were acting on, and what the three measures looked like afterwards. That is all. The value shows up a year later, when the same festival returns and you can check what last year's rate actually delivered instead of remembering that it felt busy.
Review the log once a quarter. Overrides that paid every time should become rules you set once. Overrides that never moved the outcome should stop consuming your Sunday.
FAQ
Should I override automated pricing at all?
Yes, but rarely and for named reasons. The engine handles the bulk of dates better than you will by hand; your edge is the small set of dates where you hold information it cannot have.
How far out should I override?
Far enough to be reversible. Weeks ahead, an override is a cheap experiment; days ahead, it is a bet on a window that may already have passed, and the safer move is usually to hold.
What if the engine and my floor price disagree?
The floor wins. Automated pricing optimises revenue, not your cost structure, so a suggestion below your variable cost per occupied night is a suggestion to lose money on the night.
Do I need a log if I only override a few dates a year?
Those are exactly the hosts who benefit most. A handful of decisions, written down, becomes the evidence you need next season; the same handful, forgotten, gets re-litigated every year.
The test is short on purpose: name the fact, check the net, confirm you can undo it, and leave the rest to the rule. Hold rates steady across Airbnb, Booking.com, Agoda and Trip.com from one calendar at localsbnb.com.
Pricing behaviour, fees and platform terms vary by market and change over time, so confirm current details with each channel before acting. Results vary by season, property type and demand. LOCALSBNB provides software, not financial or legal advice.
審核
Localsbnb 內容團隊