Short-Term Rental Dynamic Pricing Engine

You generate nightly rates for STR listings. Flat-rate pricing in 2026 leaves measurable revenue on the table (industry data: dynamic-priced listings outperform flat-priced comparables by 20-40% on RevPAR). The discipline is reading the market — not just the calendar.

============================================================ === PRE-FLIGHT === ============================================================

• [ ] Property data: bedrooms, bathrooms, sleeps capacity, amenities (pool, hot tub, EV charger, pet-friendly, A/C), location (lat/lng), photos count, listing age, current rating + review count.
• [ ] Market: city/region. Drives the comp set + event calendar.
• [ ] Existing channels: which OTAs are connected? PMS / channel manager (Hostaway, Hospitable, Guesty, OwnerRez)?
• [ ] Cost floor: minimum acceptable per-night rate (covers cleaning + utilities + minimal margin). Below this, the system blocks bookings rather than discount.
• [ ] Historical data: 6-12 months of booking history if available. Without it, defaults are softer (more comp-set weight, less property-history weight).
• [ ] Pricing tool: integrate with PriceLabs/Beyond/Wheelhouse OR run standalone.

Recovery:

• New listing (< 6 months): weight comp set + market data 80%, property history 20%. Be more aggressive on initial discount to build review count.
• No PMS integration: generate a rate calendar CSV that the user imports manually.

============================================================ === PHASE 1: COMP SET DEFINITION === ============================================================

Build the comparable property set with these filters:

Comp set size: 10-30 properties is the sweet spot. < 10 = too thin (one outlier moves rates). > 30 = dilutes signal.

Refresh comp set monthly (listings come and go).

VALIDATION: Comp set has ≥ 10 properties with the required amenity matches.

============================================================ === PHASE 2: BASE RATE COMPUTATION === ============================================================

For each night, compute a base rate:

Base = median(comp_set_rates_for_same_DOW_in_window) × adjustment_factors

Adjustment factors:
  Bedrooms vs comp median:    × 1.0 for match, ± 0.10/bedroom
  Reviews vs comp median:     × 1.05 if ≥ 2× comp median (premium)
  Rating vs comp median:      × 1.07 if 5.0 with ≥ 50 reviews
  Photos / staging quality:   × 0.95 to 1.10 (manual override)
  New-listing discount:       × 0.85 for first 90 days, taper to 1.0 by day 180
  Cost floor:                 max(base, cost_floor)

For each Day-of-Week in each Month, derive a separate median. Saturday rates ≠ Tuesday rates ≠ Christmas Day rates.

VALIDATION: Base rate is bounded (no rate of $0 or $10,000 from a single outlier).

============================================================ === PHASE 3: SEASONALITY MULTIPLIERS === ============================================================

Three layers of seasonality:

1. Annual — high season vs low season per market. Beach: summer × 1.6, winter × 0.7. Ski: winter × 1.8, summer × 0.6. Pull from AirDNA / Rabbu market data OR derive from prior year's market median by month.
2. Monthly cycle — months within season. Aug > June > July for many beaches.
3. Day-of-week — weekend premium (Fri/Sat). Default Fri × 1.15, Sat × 1.25, Sun × 1.10, weekday × 1.0.

Multipliers compound: Base × Annual × Monthly × DOW.

VALIDATION: Multipliers source-tagged so the user can override per market.

============================================================ === PHASE 4: EVENT-DRIVEN PRICING === ============================================================

Local events drive massive demand spikes. Maintain a market event calendar:

Sources: Ticketmaster + Eventbrite + city tourism feed + manual local-knowledge override.

VALIDATION: Events within next 60 days are detected and applied. New event addition propagates within hours.

============================================================ === PHASE 5: LEAD-TIME + BOOKING-PACE PRICING === ============================================================

As the date approaches, rates should shift based on whether bookings are pacing ahead or behind:

VALIDATION: Booking-pace lookup pulls actual current bookings + prior-year baseline before adjusting.

============================================================ === PHASE 6: MINIMUM-STAY OPTIMIZATION === ============================================================

Minimum-stay rules protect against orphans:

• Standard: 2-night minimum weekdays, 3-night minimum weekend, 7-night minimum holidays.
• Dynamic: drop min-stay during low-demand windows (allow 1-night fills) but enforce during high-demand windows (force 3+ to avoid breaking up bookable weeks).
• Gap-stay rules: if Mon-Wed is open and Fri-Sun is booked, allow Mon-Wed 3-night booking (fill the gap) but block 2-night Wed-Thu booking (would orphan Mon-Tue).

Generate min_stay_calendar.csv per night.

VALIDATION: No min-stay rule produces an unfillable orphan night.

============================================================ === PHASE 7: OUTPUTS === ============================================================

str-pricing-{listing-id}/
├── rate_calendar.csv           # nightly rates for next 365 days
├── min_stay.csv
├── rate_changes.md             # explanation per night (which rules applied)
├── forecast.md                 # 30/60/90-day occupancy + ADR + RevPAR forecast
├── weekly_report.md            # last 7 days performance vs comp set
└── alerts.md                   # nights with >25% drift from prior, events found, comp set changes

Push to PMS via API. Most channel managers accept a rate-push REST call per listing.

VALIDATION: Rate calendar has exactly 365 rows, no missing dates.

============================================================ === SELF-REVIEW === ============================================================

• Complete: All 7 phases produced output?
• Robust: Cost floor prevents negative deals? Gap nights detected? Event detection working?
• Clean: Each rate has a "why" explanation?
• STR-credible: Would a PriceLabs / Beyond user accept this as a viable engine?

Common gap: chasing comp set into a price war. Set a floor and respect it.

============================================================ === LEARNINGS CAPTURE === ============================================================

~/.claude/skills/str-dynamic-pricing/LEARNINGS.md.

============================================================ === STRICT RULES === ============================================================

• Never set rates below the cost floor. Empty nights cost less than below-cost ones.
• Never ignore minimum-stay coordination — orphan nights are unfillable.
• Never apply event multipliers without verifying the event is on (some get cancelled).
• Never let comp set fall below 10 properties. Refresh monthly.
• Always provide a "why this rate" explanation per night for transparency.