Dynamic pricing that reads demand in real time
A revenue-management engine that turns booking pace, seasonality, and local events into nightly rate recommendations across a multi-property portfolio.
Who, what, and how long
- Industry
- Hotels & Accommodation
- Duration
- 12 weeks
- Cooperation model
- Fixed price
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The question we were asked
Rooms were priced from spreadsheets and gut feel, which left money on the table on high-demand nights and empty rooms on soft ones. We built a demand model and a pricing dashboard revenue managers actually trust.
Eleven properties, each with a revenue manager setting rates in their own spreadsheet, and a group finance team comparing them monthly. Nobody could see booking pace across the portfolio, so two hotels in the same city routinely discounted into the same weekend. The engagement began after a conference month when the group sold out at Tuesday's prices.
Data & AI
The decision, first
- 01
Combining local event signals with historical pace improved RevPAR by +19%.
Pace alone reacts to demand that has already arrived. The events calendar moved the forecast before the bookings did, and that's where the nineteen percent came from.
- 02
Human-in-the-loop override controls were essential for manager trust and adoption.
The accept-or-override control is what made the model usable. Once managers could refuse it in one click, they stopped distrusting it in general.
- 03
Automated rate recommendations reduced manual pricing workload by 70%.
The workload fell because most nights are unambiguous. Managers stopped pricing every one of them and started reviewing the handful the model flagged as uncertain.
What the numbers couldn't answer
Rates were set by hand, property by property, with no shared view of booking pace or competitor movement. Pricing lagged market demand by days, and RevPAR paid for it.
Rates moved on a weekly cycle because that was how often someone sat down with the spreadsheet, while demand moved daily. The cost showed up in the pace data afterward: on the twelve highest-demand nights of the previous year, the group had been at or below its own average rate on nine of them.
We consolidated booking, occupancy, and event data into one pipeline, trained a demand-forecasting model, and shipped a dashboard that recommends nightly rates managers can accept or override in one click.
How we worked it through
- 01
Unified booking and occupancy feeds across every property
Booking pace, occupancy, rates and a local events calendar were normalized into one nightly feature table per room type: the join nobody had made before.
- 02
Built a demand forecast from three years of historical pace data
Three years of pace data lived in four systems, and no two of them agreed. Most of this step was deciding which source won on each disputed night.
- 03
Designed an accept/override dashboard for revenue managers
Two revenue managers sat through the design of this screen, and the accept-or-override control was their condition for using the model at all.
- 04
Ran a shadow period comparing model rates to manual pricing
For six weeks the model priced alongside the managers without touching a live rate, and the cases it lost are where the confidence-band rule came from.
Phase by phase
Phase 1: Pipeline Integration
Multi-Source Data Ingestion
Unified booking pace, historical occupancy, local event calendars, and market competitor rates into a central PostgreSQL data store.
- Ingestion Pipeline Specs
- PMS Integration API
- Data Hygiene Monitor
Phase 2: ML Model Training
Predictive Demand Engine
Tuned gradient-boosting demand forecasting models using 3+ years of seasonal booking data across the full property portfolio.
- Demand Forecast Model
- Validation Report
- Yield Optimization Logic
Phase 3: UX Dashboard Design
Revenue Manager Cockpit
Designed a clear accept/override dashboard interface where managers inspect recommendations and apply bulk pricing rules in seconds.
- Dashboard UI Specs
- Rate Preview System
- Audit Trail Logging
Phase 4: Pilot & Rollout
Shadow Testing & Full Launch
Piloted automated rate recommendations alongside manual pricing over 4 weeks, verifying a +19% RevPAR gain before chain-wide deployment.
- Pilot Comparison Study
- Staff Training Guide
- Production Release
The engagement in four phases, the six-week shadow period comparing the model's rate with the managers' week by week, including how many disagreements fell on wide-band nights, and the feeds and source-precedence rules behind the nightly feature table.
What it changed
+19%
RevPAR
−70%
Manual pricing time
92%
Forecast accuracy
RevPAR is compared against the same months of the previous year across the same eleven properties, with two refurbishments excluded from both sides. The manual-override rate is measured on live recommendations only, and it's reported per property because the group average hides the two that override most.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Real-Time Demand Forecaster
Predicts nightly room demand across the property portfolio based on local events and pace metrics.
Three years of booking pace, occupancy and rate history were joined against a local events calendar and normalized into one nightly feature table. A gradient-boosted model predicts demand per room type per night and retrains weekly on a rolling window, so a shifting market doesn't need an engineer. Every prediction carries a confidence band, and the cockpit withholds a recommendation when that band is too wide to act on.
- Pace, occupancy and events in one nightly feature table
- Weekly rolling retrain, no engineer in the loop
- Recommendations withheld when confidence is too wide
Three years of stays sorted by how far ahead they were booked, with the two- to four-week band on Fridays and Saturdays outlined; beside it the nightly feature table the model reads, its weekly rolling retrains, and the nights withheld because the confidence band was too wide.
Accept/Override Cockpit
Why Saturday is 185 and not 142: the folk festival, booking pace, competitor moves and the rain, each with its weight, the revenue either way and accept or override, above a scoreboard of past overrides with their reasons and whether the manager or the model came out ahead.
A clear cockpit where revenue managers accept the model's rate or adjust it, with every override kept in an audit trail.
Each recommendation shows the three inputs that moved it most, so a manager overriding the model can see exactly what they're disagreeing with. Overrides are first-class: stored with a reason, replayed into the next training window, and reported back as a scoreboard of where the human beat the model and where they didn't. Nothing touches the live rate without an explicit accept.
- Top three drivers shown beside every recommendation
- Overrides stored with reason and fed back into training
- No rate moves without an explicit accept
Portfolio Yield Optimizer
Maximizes Revenue Per Available Room (RevPAR) automatically across high and low-demand booking windows.
Properties in the group had been competing with each other for the same booking windows. The optimizer solves across the whole portfolio at once, holding a floor rate per property and shifting exposure toward whichever site converts best that week. Managers keep local control (a property can be pinned out of the portfolio view), and the cost of each pin is reported back monthly.
- Solves across the whole portfolio at once
- Per-property floor rates always respected
- The cost of each manual pin reported monthly
Five properties, 214 rooms, booking pace against the same nights last year with each floor and lowest rate side by side, the twelve rate changes still waiting on a manager, and one hotel pinned out of the solve with the estimated cost of that pin.
How the engagement ran
A cross-functional team of 6 worked on a fixed price basis over 12 weeks, covering Data engineering, Forecasting models, Ops dashboards. We shipped in two-week increments, each one releasable and reviewed live before it merged. Decisions were written down as they were made, so the reasoning outlived the people who made it.
Two revenue managers sat in every biweekly review, and the model's recommendations were shadowed against their manual decisions for six weeks before anything reached a live rate. That shadow period is where the confidence-band rule came from. The managers were consistently right in exactly the cases the model was least sure about, so those cases stopped being recommended at all.
One night, one rate
Why festival Saturday is 185, when last year it sold out at 142
One room type at one hotel, worked through: what the same Saturday did last year, the signals the model reads this year, and the move it recommends from them before a manager accepts or overrides it. Switch tabs, or use the arrow keys once one is focused.
The spreadsheet set Saturday once a week, from the weekday pattern. The festival was on the city’s calendar, but not on the one the rate came from, so the hotel filled three weeks early at an ordinary Saturday price.
From booking pace to a rate a manager accepts
Python and FastAPI over PostgreSQL, a Scikit-learn demand model, and a React cockpit with Recharts. The confidence band is computed at the model and carried unchanged to the screen where the rate is accepted or overridden.
- 01 · SourcePMS, events, competitorsBooking pace, historical occupancy, a local events calendar and competitor rates arrive for every property in one feed, where there used to be one spreadsheet per hotel.
- 02 · Feature storeNightly table · PostgreSQLThree years of pace from four systems normalized into one row per room type per night, with a decided winner for every disputed night.
- 03 · EngineGradient-boosted demand modelRetrained weekly on a rolling window with no engineer in the loop. Every prediction carries a confidence band; too wide, and nothing is recommended.
- 04 · SolvePortfolio yield optimizerSolves across the whole portfolio, holds each property's floor rate, and reports the cost of every manual pin monthly.
- 05 · DeliverAccept/override cockpitThe top drivers sit beside each rate. No live rate moves without an explicit accept; overrides are stored with a reason and fed back into training.
Explicit accept, stated confidence, floors that hold
Nothing goes live without an accept
Every recommendation waits for a manager to accept or override it. Overrides are first-class: stored with a reason, replayed into the next training window, and scored against the model after the stay.
Unsure nights get no recommendation
Each prediction carries a confidence band, and the cockpit withholds a recommendation when the band is too wide to act on. The rule came from the shadow period, where managers were right on exactly the nights the model was least sure about.
Floors hold, local control stays
The portfolio solve always respects each property's floor rate, and a manager can pin a property out of it. The cost of each pin is reported back monthly, and the pin stands.
Are your busiest nights still selling at a Tuesday price? Scope your build in 3 minutes.
Scope your buildNearby engagements
Web PlatformsThe invoice and the trip it pays for were separate records, so nobody could say which trips were unpaid
A booking and invoicing system for a travel agency where every invoice line points at the trip component it bills, and every payment points at the bank account it landed in. "Which trips are unpaid" becomes a query instead of an afternoon.
Travel & Tourism · 10 weeks
Web PlatformsA booking platform tuned from search to checkout
A reservation platform where the search-to-checkout path is designed around real traveler behavior, then engineered to load fast and hold up under seasonal spikes.
Travel & Tourism · 16 weeks
Mobile AppsA trip assistant that still answers with roaming switched off
A companion app for a tour operator's guided trips, whose assistant answers questions about a traveler's own itinerary on-device. The moment people land abroad they turn data roaming off, and most apps go dark exactly when they're needed.
Tour Operators · 12 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
