Setting each night's price in a hotel, guesthouse, or resort based on demand, season, and last-minute behavior — minimizing both empty nights and rooms sold too cheap.
In plain words
Sound familiar?
- You set room rates at the start of the season and they stay the same; weekends end up empty while weekdays sell out early
- When there's a local event, festival, or concert, you raise prices too late — you should have moved them up 2 months out, not 2 weeks
- On online booking platforms, every price change is click-by-click — a single update takes half a day
- You can't track the rate movements of nearby properties regularly; you sit too high or too low
- For last-minute requests, 'discount or not' is a guess — sometimes a room that would have sold at full rate gets discounted
- You don't differentiate between 1–2 night guests and 7+ night guests — there's no incentive structure for longer stays
- Once or twice a year you realize 'I could have charged more for this weekend last year' — but there's no analytics in place
Why it matters
How it's solved
Technical depth
How it's solved
Technical depthOne-liner: Don’t lock in a seasonal price — update it daily against demand. If weekends are filling early, raise the rate; if weekdays aren’t moving, drop it. Aim for the highest occupancy × rate balance, not for selling rooms as fast as possible at a discount.
What the software is really doing is this: it takes the seasonal rates you set at the start and recomputes them every day against fresh demand signals and history. Three stages:
1. It collects demand data. Historical occupancy and rate history, searches and lookups from online booking platforms (how many users picked a date, clicked, booked), local event calendar (festival, concert, conference, school holidays), neighbor property rate movements, seasonal and day-of-week character. The data flows from the property-management system automatically, or is configured once.
2. It computes the best price for each night. The software doesn’t try every possible price-quantity pair — that is mathematically impossible at scale. Instead, it uses demand forecasting and dynamic programming — bodies of work from operations research (a discipline that uses math and computing to solve business-decision problems) — to estimate the demand curve for each room category and each night, and then picks the price that maximizes occupancy × rate. Demand variability, length-of-stay preferences, and last-minute booking patterns enter the model. The result is a rate table for the next 90–180 nights, per room category, in minutes.
3. The prices flow to all channels automatically. The software pushes rates via API directly to the property-management system, online booking platforms, and the property’s own website. Manager approval is configurable — ‘apply automatically’ or ‘require approval for any change above 10%’. When a local event or market move is detected, the software flags it, optionally shows suggested rates, and you approve before they go live.
It does not replace the hotelier’s judgement; think of it as a calculator that takes the manager’s 3–6 hour weekly rate-updating task down to 15 minutes and tracks the market every day. The decision is still yours, but the data and the recommendation are always current.
Alternatives
Fixed seasonal rate + manual tracking
FreeFree
Who it fits: Under 10 rooms, single season, stable customer base
- + Zero cost
- + Simple — rates rarely change
- + No capex decision
- − Cannot react to demand swings — empty nights or early discount lock-ins
- − Local-event opportunity missed
- − Slow reaction to neighbor moves
- − No occupancy-curve visibility — you can't tell what worked
Local property-management system with manual pricing
Enterprise$200–1,000 setup + $50–200/month (regional SMB pricing)
Who it fits: 10–40 rooms, sales mainly through online booking platforms
- + Local-language interface and support
- + Channel manager wired to online booking platforms
- + Single-point rate edits push to every channel
- − No price recommendation — manager still decides from the gut
- − Demand forecasting and historical analytics are limited
- − Neighbor rate data usually not included
International specialized revenue management software
Enterprise$50–300/room/month subscription, or $25,000–150,000/year licence
Who it fits: 40–200 rooms, seasonal operation, multi-channel, high competition
- + Mature: demand forecasting, dynamic pricing, neighbor tracking, channel management all fully supported
- + Property-management-system integration included
- + Algorithms hardened over years
- − High licence and consulting cost
- − Rollout takes 2–4 months
- − Local-language support and event-calendar adaptation may need work
Custom build on an open-source solver
Open SourceLicence free; 8–16 weeks of internal development, or $50,000–200,000 of consulting
Who it fits: Hotel chain or multi-property investor with a data team
- + No licence cost
- + Fully customizable to your customer base and seasonal patterns
- + Runs in the cloud or on your own server
- − Requires real data-science capacity in-house
- − Ongoing maintenance is real work
- − Demand forecasting and dynamic pricing are two separate disciplines; building both teams is expensive
Recommendation
Ask in the meeting
- What model underpins demand forecasting — historical average, seasonal decomposition, advanced statistical model? Is the local event calendar fed into the model?
- Is nearby-property rate tracking handled inside the system? What's the source, and how often is it refreshed?
- Is there two-way API integration with at least 3–5 major online booking platforms? How fast does a rate change propagate to the platform?
- Are length-of-stay (LOS) price tiers supported? E.g. one price for 3-night stays, another for 7-night stays?
- Is overbooking management offered? How is the risk threshold set and what probability data drives it?
- Is the price recommendation fully automatic, or is there a rule system requiring manager approval? Can the threshold (e.g. approval for changes over 10%) be configured?
- How do you structure the pilot — how many room categories, how many weeks, what is the success bar?
- If we stop working with you, how do we get our reservation, rate history, and customer data back? Is there a standard export format?
Technical details
Editor’s note
In the day-to-day this problem is known as “rate setting”, “seasonal pricing”, or “occupancy management”. The academic name is Revenue Management (RM). Born in the airline industry in the 1970s, it has been adapted to every industry that combines fixed capacity, perishable inventory, and variable demand — airlines, hotels, car rental, event ticketing, freight. Without that vocabulary, you cannot tell in a software demo whether the “pricing module” being pitched is genuinely doing demand-forecast-driven dynamic pricing, or just running a “last-year’s price + 5%” rule.
The point most often overlooked in this segment: many products advertise “dynamic pricing” but underneath they only run rule-based triggers — e.g. “if occupancy passes 70%, raise the price by 10%”. That helps a little; but real revenue management forecasts the demand curve per night and prices against it. In any demo, insist on seeing a transparent output: ’tonight’s suggested rate is X, here’s why’, backed by 30 days of historical data.
A step-by-step path for an SMB
Stage 1 — Measure first, plan later. For at least 12 weeks, log four things:
- Daily occupancy and revenue per available room (RevPAR)
- Per-reservation lead time and source channel
- Empty nights and their cause (price too high, off-season, no event)
- Neighbor rates (even a once-a-week manual check is enough)
Without this baseline you can’t tell which software will deliver which result.
Stage 2 — Build your room-category and season table. How many room categories (standard, deluxe, suite); the base rate range for each; which dates are “high season”, “shoulder”, “low season”; which dates carry special events or holidays. A 5–10 category × 4–5 season table is a fine start — this is your knowledge capital, and any serious vendor will ask for it first.
Stage 3 — Pilot. Start with your one or two highest-revenue categories for 8–12 weeks. Define the success criterion in writing, before the pilot: e.g. “in 90 days, pilot-category RevPAR up 7% and manual rate-update time cut in half”. If the bar is missed, the pilot ends — keep that exit right in the contract.
Stage 4 — Rollout. If the pilot lands, scale to all room categories over 2–3 months. Manager training runs 1–2 weeks; the approval flow (automatic vs. manager-approved) is tuned to your culture.
Risks — what can go wrong
- Bad historical data. If the previous year had a pandemic, earthquake, or shutdown, the history can mislead. Before the pilot, separate ’normal’ from ‘unusual’ periods — a good RMS does this on its own.
- Customer perception of rate volatility. If the same room’s price swings ±30% in two weeks, guests may feel “manipulated”. Set guardrails (e.g. max 15% daily change) so movements stay credible.
- Online booking platform contracts. Some platforms enforce ‘rate parity’ clauses (same price across channels); review them. The RMS must respect that constraint in its optimizer.
- Vendor lock-in. Software that stores reservations and rate history in a proprietary format makes migration hard. Put a clause in the contract: “We can export our data in standard open formats (CSV or similar) at any time, on request.”
Related cautionary lesson (will be linked once published): “A 35-room hotel that dropped its revenue management software at month 6 — what they missed.”
A technical view of the solution method
This section holds what you’ll need when talking to a software team or a consultant. It is not what the manager sees on the daily screen — it is the engine behind the curtain.
The main approaches used for revenue management:
| Approach | Typical use | Data need | Decision logic |
|---|---|---|---|
| Rule-based | Fixed thresholds, simple demand | Low | “If occupancy > X, raise price by Y” |
| Demand forecast + EMSR | Classic airline/hotel | Medium | Statistical + probabilistic optimum |
| Dynamic programming | Complex multi-booking paths | High | Stage-by-stage optimum |
| Machine learning | Large chains, many drivers | Very high | Complex pattern recognition |
| Hybrid (rules + forecast) | SMB hotel practice | Medium | Transparency + math |
In practice: under 40 rooms with a simple operation, rule-based plus a simple forecast suffices. For 40+ rooms, seasonal swing, or strong competition, a demand-forecast plus EMSR (Expected Marginal Seat Revenue) or hybrid approach is preferred. Large chains add a machine-learning layer.
Objective function choice changes the shape of the solution:
- RevPAR (revenue per available room): “Use room capacity efficiently” — fits seasonal hotels
- GOPPAR (gross operating profit per room): “After cost, maximize profit” — fits full-board or restaurant-heavy hotels
- Revenue × market position: “Maximize revenue without losing share” — fits high-competition areas
- Customer-segment balance: “Off-season leisure, on-season business” — fits multi-segment boutiques
Most real deployments use a weighted blend of all four.
Academic references
Listed in the sources block of this page’s frontmatter. Revenue management has been one of the most active operations research fields since the 1970s; current work focuses on machine learning and real-time forecasting. INFORMS Interfaces and the Transportation Science archive carry deployment case studies tied to real hospitality operations.
Sources
- Talluri, K. T. and van Ryzin, G. J. (2004). The Theory and Practice of Revenue Management. Springer. The standard reference text in revenue management.
- Phillips, R. L. (2005). Pricing and Revenue Optimization. Stanford University Press. The practice-oriented foundational textbook.
- McGill, J. I. and van Ryzin, G. J. (1999). Revenue management: Research overview and prospects. Transportation Science, Vol. 33 — the foundational survey of the field.
- INFORMS Interfaces — case studies of revenue management deployments in hospitality and transport. informs.org/Publications/Interfaces
Glossary
- Revenue Management
- Setting dynamic prices for fixed-capacity, perishable inventory (hotel rooms, airline seats, event tickets) based on demand.
- Demand Forecasting
- Quantitatively predicting future demand using history, seasonality, events, and external signals.
- MIP
- An optimization model where some decision variables are forced to be whole numbers (e.g. number of trucks, number of shifts).