How the pricing rules engine works.

Watchfox reprices every listing you connect, every night, by reading the signals that actually move bookings in your market. The ruleset is per-listing, so a downtown loft and a studio in the suburbs can run on different logic without one overriding the other.

What the engine reads

Every night, the engine pulls four signals and applies them to the rules you saved for that listing.

• Pace of bookings. How quickly reservations are coming in versus the same window a year ago, and how that compares to your own historical pace.
• Local demand. Concerts, festivals, conferences, and other events in your area within the next 14 nights. You upload these as a demand signals CSV; they show up as peaks on the 30-day calendar.
• Lead-time. Whether the next stay is 30 days out (cheap to discount) or three days out (cheap to bump).
• Channel pull. Comparative rates for nearby listings on the same channel, weighted by how often your listing has been the cheaper option in the past.

Inputs you tune

Each listing has a ruleset with five inputs. You change them per listing from the Pricing rules page. Every input has a sensible default, so a brand new listing starts with a tuned baseline.

• Base rate.The price the engine treats as a starting point for the next 14 nights. Think of it as your "normal" rate.
• Weekday multiplier.A figure the engine applies to Sun–Thu nights. Defaults to 1.0× (no change).
• Weekend multiplier. Applied to Fri–Sat nights. Defaults to 1.15×.
• Lead-time bump. A small bump applied to nights inside the next 7 days where occupancy is high. Defaults to +8%, scaling lower for longer lead times.
• Demand-signals weight. How much weight the engine gives to event peaks. Defaults to moderate; raise it during festival season, drop it during slow months.

How the math runs

The engine runs the ruleset on each saved change and on a nightly schedule, in this order:

1. Start at the listing's base rate for every night in the next 30.
2. Apply weekday or weekend multipliers by night-of-week, so Fri/Sat nights in adjacent weeks don't disagree by more than the multiplier you set.
3. Add the lead-time bump where the next 7 nights are more than 60% occupied, scaling down to zero the closer the calendar gets to 30 days out.
4. Add demand-signals weight where a local event peaks within a 4-night window of the stay.
5. Cap the recomputed rate to within ±25% of the prior recommended rate, so two consecutive nights never swing wildly.

What you do (and don't do)

You don't set nightly rates. You only set the inputs above per listing. The engine then resolves the next 14 nights into the rate table on your dashboard, and pushes the recommendation to each channel for any night you've opted in to auto-send pricing.

Any recompute also shows up in the audit log: which listing, which input changed, which nights the change affected, and the recommended rate before versus after. If you ever disagree with the math, raise or lower the affected input and the rule logs the new version with a timestamp.

What this looks like in week one

When you connect a new listing, Watchfox runs a one-time calibration pass: it reads the historical pace your channel exposes, fills in the 14-night rate table with a suggested base rate, and queues a draft pricing event for the next refresh window. After that, you only touch the inputs when your market shifts — a new competitor, a seasonal change, or a calendar you want to nudge up for a festival.

Related articles

The pricing rules engine reads from your demand signals — upload a CSV of local events so peaks show up on the calendar and the rate table. Read about it under demand signals.