Dynamic Pricing to anticipate demand and guide rates

A calendar that is still mostly empty can make it feel as though nothing is urgent. Yet an international marathon may be taking shape a few kilometres away, a trade show may be approaching, or the next school holidays may change how people stay. Future demand may already be present in those signals, before it appears in the manager's reservations.

For a short-term rental management company, the question is which price to offer for each night, on the basis of which information, and with what level of risk. Raising a rate too early can slow sales. Keeping a rate too low can let nights go that would have found a guest on better terms.

RevNLabs is an iKeeLabs project. The Dynamic Pricing service described here is a component being designed for a PMS, the software used to manage properties and their reservations. It aims to connect anticipation of the market with the manager's decisions. The figures below are fictitious. They explain the approach. They do not claim commercial results.

Anticipating periods of demand

Some market shifts are prepared a long time in advance. Tourist seasons, the year-end holidays and school holidays provide reference points. Recurring events provide another kind of visibility: a marathon, a festival or an international fair can draw visitors with specific accommodation needs.

Those reference points do not justify a uniform increase. Christmas does not have the same effect in a ski resort and in a business district. A trade show may matter mostly to properties that are well connected to the exhibition grounds. A festival that offers its own camping does not necessarily create the same demand as a professional event of comparable size.

The approach is therefore to estimate a usual demand for a destination and a period, then to study what the event may change. The comparison has to take previous editions into account and avoid counting twice a peak that is already present in the seasonal history.

This anticipation stays open to revision. The fact that an event recurs guarantees neither the exact dates nor the scale of its next edition.

Estimating accommodation needs

A number of visitors is not enough to measure accommodation needs. Part of the audience lives locally. Other people come for the day, stay with friends or relatives, or choose a solution offered by the organiser. Visitors who book a property may share an apartment and stay for several nights.

The path therefore runs, step by step, from the expected attendance to accommodation needs by night and by area. The length of stays matters as much as the day of the event: some arrivals come before it opens and some departures follow it.

Take the fictitious Harbor City marathon. For one night in the area under study, the demonstration scenario estimates:

• A usual demand of 650 properties.
• An additional need linked to the event of 540 properties.
• A supply of 900 properties for that night.

The illustrated total demand therefore reaches 1,190 properties. Demand above supply signals possible pressure. It does not mean that 1,190 reservations will be made, or that every property will find a guest at any price.

Location, access and property type remain decisive. A neighbourhood forecast still has to be interpreted for each property.

Revising the forecast as information arrives

Six months before the event, the manager mainly has historical recurrence and an expected period. Three months before, dates and elements of the organisation may be confirmed. One month out, the pace of reservations and new information about the event can sharpen the scenario. One week out, the remaining availability and recent changes carry more weight.

The anticipation view lets the manager move across these horizons and see how the forecast changes. New information can strengthen the scenario, call it into question, or widen the range of possible outcomes. Getting closer to the event does not guarantee that everything becomes more certain.

One rule is essential: at each observation date, only information that is already available may enter the analysis. An announcement published in May must not be used to explain a decision supposed to have been taken in February.

Testing a decision before changing rates

A forecast becomes useful to the business when it helps examine a concrete choice. What happens if the event draws fewer visitors? If the pace of reservations slows? If an assumption about air traffic changes? If the owner wants to keep a rate ceiling?

The "What if" simulator is there to explore these questions. The manager changes an assumption and sees the nights concerned, the associated forecast and the rate recommendation. Manual assumptions stay identifiable, and distinct from confirmed facts.

In the teaching model used for the simulator, a raw recommendation reaches €167 for one night. A demonstration ceiling brings it back to €160. When the event is switched off, with everything else held equal in this simulation, the recommendation becomes €149.

These amounts come from an illustrative formula. They show the logic of a decision, not an optimal price validated on a real market. The simulator makes it possible, in particular, to see why a stronger demand signal may stop changing the price once the ceiling applies.

The recommended rate is not yet an applied rate. The validation policy has to state what the system may publish automatically, what requires a review, and the limits that belong to the portfolio. The bounds shown in the demonstration are not rules imposed on the product.

Understanding a recommendation

An amount on its own answers a manager or an owner poorly. Why does this night deserve particular attention? Which elements influence the forecast? Why does the recommendation stop at this level?

A useful explanation separates three levels.

The first concerns the factors the model uses to forecast demand. The second concerns the rules that bound the rate, such as a ceiling. The third brings the documentary context: which event is involved, where it takes place, and which information is confirmed.

This distinction avoids confusing a cautious recommendation with weak demand, or an interesting piece of information with a factor that is actually used in the calculation.

Traceability also makes it possible to revisit a decision after the stay. The manager can find the information that was available, the constraints that were applied and any human interventions, rather than judging an old choice with what is known today.

Steering a portfolio with clear priorities

For a company managing several destinations, this approach aims to concentrate attention on the periods and properties that deserve a review. An important event, a fragile forecast or a change of pace can justify a priority check.

The aim is not to multiply price changes. It is to make commercial policy more consistent, to make the conversation with owners easier, and to reduce the monitoring and comparison work done by hand.

The value will have to be measured in operation: time spent on rate review, net revenue relative to nights that can be sold, occupancy, and respect for the owners' constraints. None of these indicators should be read alone. A property filled earlier, or sold at a higher price, does not automatically imply a better overall result.

Predictive and generative models

The functional views rest on several complementary mechanisms. Their role is easier to understand when numerical forecasting, document analysis and explanation are kept distinct.

Numerical forecasting

Machine learning learns relationships from historical data. It can examine how the season, the lead time before the stay, the pace of reservations and characteristics of events are associated with a measurable target.

That target has to be defined precisely. Observed reservations do not describe all potential demand: a property that is already sold can no longer record further requests. A demand index also needs a definition and a method of validation.

The target architecture envisages Python models, in particular of the LightGBM type, with Azure Machine Learning for training and operation, and MLflow to track versions. Microsoft positions Azure Machine Learning on this cycle of custom models, and Foundry on generative applications and agents. Microsoft Learn

Forecasting demand pressure is not, however, enough to find an optimal price. The response of guests to different price levels also has to be understood. A historical association between high prices and strong sales does not prove that an increase will produce more revenue.

Explainability tools such as SHAP help show the factors of a prediction. On their own, they do not demonstrate a causal effect. If the model predicts a demand index, its contributions explain that index, not extra euros directly. SHAP documentation

Document analysis and context

Generative AI can help turn an event description into usable information: dates, place, category or an indication of scale. That information then has to be checked before it feeds the forecasts. A supposed next edition must not become a confirmed date simply because a model phrased it that way.

Aviation data is another possible source of context. IATA offers, in particular through AirportIS, historical traffic data and future flight schedules. The integration under consideration still has to specify the accessible product, its granularity, its frequency and its terms of use. Seats offered or expected passengers do not correspond directly to local nights. IATA AirportIS

Explanations tied to their sources

RAG, for Retrieval-Augmented Generation, means retrieving relevant information before asking a language model to write an answer. In this project it would bring the event documents, the calculated decision and the manager's question closer together.

Microsoft Foundry and Azure AI Search are envisaged for this generative and documentary layer. The search has to respect the management company's scope, the dates and the location. The presence of sources improves the possibility of verification, but it does not remove the need to evaluate the answers. Microsoft Learn on RAG

The numerical calculation keeps its own logic. The .NET backend remains responsible for authorisation, pricing constraints and publication through the Channex adapter. A generated text must not become a sufficient instruction to change a price.

Evaluating forecasts and pricing decisions

A convincing demonstration has to be followed by an evaluation on suitable data. For the forecast, that means in particular holding out periods the model did not use for learning, then replaying successive decisions through time. This approach is called backtesting. Microsoft Learn on forecast evaluation

Each forecast must use only the information available on its original date. A PMS-data approach can then be compared with an approach enriched by events and external signals, on an observable target and under the same evaluation conditions.

Generative explanations need other checks: fidelity to the calculated results, relevance of the documents, absence of invented figures, and respect for authorisations. Good writing quality does not replace the accuracy of the forecasting model.

Finally, a smaller forecast error does not yet prove a commercial gain. That gain will have to be examined in a progressive experiment, with suitable comparisons and operational indicators. The fictitious scenarios make the behaviour understandable. They replace neither this validation nor the economic measures.

A better informed commercial decision

The Dynamic Pricing described here aims to give the manager a reading of the market ahead, a way to examine assumptions, and an explanation of the recommendations.

Seasonality and events provide early reference points. Reservations and new information make it possible to revise them. Predictive models organise these signals, while generative AI can make them easier to use and to understand.

The criterion of success remains the management decision: knowing why a night deserves particular attention, which information supports that choice, and when it should be reviewed.