The dates your pricing engine must not be allowed to touch

Thirty-nine days to the date you cannot get wrong

Today is 11 September. In Oaxaca, the Day of the Dead ramp-up starts on 20 October and the event itself runs 27 October to 5 November. That is 39 days out. If your property already carries hand-made rates on those nights, and if you have been operating here more than a year you do, this is the week to decide which part of your pricing you are going to automate and which part goes under lock.

The useful question is not should I automate rates? It is which dates can the automation never touch, and how do I guarantee that?

What a pricing engine does to your good nights if you let it

This is the engine running on my own property, Maka Hostel in Oaxaca. Every morning since 14 August 2026 it reads that night's occupancy, checks three competitors on Hostelworld, and rewrites five lead-time rate bands: same-day, 1-3 days out, 4-7, 8-21, and 22-45. Thirty-two runs are logged between 14 August and 5 September, across 22 calendar dates.

Over those weeks the engine deepened the same-day discount in three-point steps, from 0% to -8%, chasing near-term occupancy that would not lift. Tonight-occupancy across the logged window ranged from 11% to 47%. Its low-season target is 75%. It saw a soft market and did the obvious thing.

Now hold that against a Day of the Dead night. Every one of those 32 runs falls in the low-season bucket. The engine's entire education happened in a month when beds do not sell. Three days out from 1 November, a dorm sitting at 30% looks, to a model that only knows September, exactly like a dead Tuesday. Same input, opposite meaning. Bookings for those nights arrive earlier, at higher prices, from people who are not shopping around.

The arithmetic on a single bed

The protected Day of the Dead rate on my property carries a +800% multiplier over base: nine times. The competitor floor the engine tracked between 14 August and 5 September moved between MXN 168 and MXN 206 per bed, probed three days out.

Take 190 as the base for the sum. Nine times that is 1,710 pesos per bed-night. If the engine rewrites that night with the discount it learned in low season, -8% off base, it writes roughly 175. The gap is about 1,535 pesos. On one bed. On one night.

I am not going to multiply that by your beds and your ten nights, because your number is not mine. Do it yourself, on a napkin, before you read further. And notice what makes this failure mode nasty: it is invisible. The engine does not crash, does not raise an alert, does not leave an error in the log. It writes a perfectly valid rate and moves on with its morning.

Four locks, not one

1. The engine may only touch rates it created itself

In my code the engine only ever creates and deletes rates prefixed AUTO -- followed by the band name. Every hand-made rate survives by construction, not by good intentions and not by a condition somebody might forget to write. If your vendor cannot guarantee you this one, everything else is decoration.

2. Protected rate ids, immune to the logic

The Day of the Dead rate id is hard-coded and no code path touches it, whatever the rest of the logic decides. A lock by name is not enough: the day somebody renames a band, you want the id still blocked.

3. Date windows, with the ramp as its own window

Three windows are closed in my configuration: Day of the Dead from 27 October to 5 November 2026, the ramp-up from 20 to 26 October, and Guelaguetza from 20 to 27 July 2027. Any range the engine would otherwise write gets clipped against those windows, and a band that falls entirely inside a window is skipped outright.

The ramp is the part everyone forgets. Day of the Dead bookings do not arrive on the 27th; they arrive weeks earlier, and the price of the preceding week is part of the event. Lock only the hard dates and the engine will discount exactly the stretch where the event's occupancy is actually decided.

4. Hard floors that do not depend on the learning layer

Separate from anything the learning layer wants, there is a floor at -55% off base price and a minimum net of 130 pesos per bed on the worst channel imaginable, with promotions stacked and commission high. There is also a pre-write check: if any computed price makes no sense, the whole run aborts and writes nothing. Across 32 runs it never fired once. I want it there anyway.

How to build your own list

Open the calendar, not your memory. Three categories, exact dates:

• Event: the hard festival, long-weekend or conference dates.
• Ramp: how many days ahead your booking pace changes. For Day of the Dead in Oaxaca I use seven.
• Hand-made rates: groups, corporate deals, the odd rate you built for one agency that nobody else understands.

Put 2027 in now. Guelaguetza July 2027 is already on my list and it is September 2026; protected windows get set once and reviewed, not remembered in a hurry each year. And write it into the system, not onto a sticky note on the monitor.

How you verify it worked

The only proof that counts is the log. Across my 32 runs, the line confirming that Day of the Dead and every hand-made rate were left untouched appears 23 times, once for each run that wrote live. Zero of 32 runs touched a protected window or a protected rate.

After your first automated week, open the PMS and look at the protected nights with your own eyes. Do not read a summary. Open the date and look at the rate. If there is a rate sitting there that you did not put there, the lock does not exist.

What this data does not say

Be honest about the scope. This is 32 runs over 22 distinct dates on a single property; four of those dates were re-run several times the same day while I tuned the formula, so they are not 32 independent decisions. And all of them fall in low season: I have not yet watched this mechanism go through a real high-season window. Day of the Dead 2026 is the first genuine test, which is precisely why those dates are locked rather than trusted to the learning layer.

What I can state is what the log holds: no protected date was written to. Not that it earned money. Results vary by property, market and season, and anyone who promises you a number before seeing your data is selling you something else.

If this sounds like your property, see the three Nightfill tiers and start a free 14-day pilot on your own data: view pricing.