Forecasting Hotel Demand with Azure ML Studio

Demand forecasting is one of the most valuable — and most underdeveloped — capabilities in hotel revenue management. Most properties still rely on a revenue manager's intuition, last year's numbers, and a spreadsheet. Azure ML Studio makes it possible to build a genuine time-series forecasting model without a data science team.

This is a practical walkthrough of how I approached demand forecasting for a Swiss mountain property, using Azure ML's AutoML with historical occupancy data.

The problem with traditional hotel forecasting

Standard forecasting in hospitality typically looks like this: take last year's occupancy, adjust for known events, add a gut-feel percentage. It works well in stable markets. It breaks down completely when demand patterns shift — post-COVID travel recovery, a new competitor opening nearby, or a major event moving dates.

A machine learning model trained on 3+ years of data handles these shifts better because it captures seasonal patterns, day-of-week effects, lead time curves, and external signals simultaneously.

What you need before starting

Historical reservation data — at least 24 months, ideally 36. One row per date with rooms sold, rooms available, and channel.
An Azure subscription — free tier works for experimentation
Azure ML workspace — set up via the Azure portal in about 10 minutes
Optional: external signals — local events calendar, school holiday dates, competitor rate data if available

Step-by-step: building the model

Prepare your dataset Export your PMS data and structure it as a time series: one row per date, columns for occupancy rate, rooms sold, ADR, and any categorical features (season, day type, major events). Upload this as a CSV to your Azure ML datastore.
Create an AutoML experiment In Azure ML Studio, go to Automated ML → New run. Select your dataset, choose "Time series forecasting" as the task type, and set your target column to occupancy rate. Set the forecast horizon to 30 days (or 90 for longer-range planning).
Configure the time series settings Set your time column to your date field. Define the forecast horizon. Enable "Use lags" to let the model learn from previous periods — I typically set lags to 7 and 14 days to capture weekly patterns.
Run and evaluate AutoML will test multiple algorithms — Prophet, AutoARIMA, TCNForecaster, and others. It ranks them by MAPE (Mean Absolute Percentage Error). For hotel occupancy I typically see MAPE between 4–8%, which is significantly better than manual forecasting.
Deploy as an endpoint Once you have a model you're happy with, deploy it as a real-time endpoint. You can then call it from Power BI using a Python script visual, or from your daily reporting workflow.

Connecting the forecast to Power BI

The most practical integration is calling the Azure ML endpoint from Power BI's Python visual. This way, your revenue dashboard shows both actuals and the 30-day forecast in a single chart.

# Power BI Python visual — call Azure ML endpoint
import requests, json, pandas as pd

url = "https://your-endpoint.azureml.net/score"
headers = { "Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/json" }

payload = json.dumps({ "data": dataset[["date","rooms_available"]].to_dict("records") })
response = requests.post(url, data=payload, headers=headers)
forecast = pd.DataFrame(response.json()["forecast"])

# forecast now contains predicted occupancy per date

What this looks like in practice: The revenue manager opens Power BI on Monday morning and sees actual occupancy for the last 30 days alongside the model's forecast for the next 30. Dates where actuals are tracking significantly below forecast trigger a pricing review. It takes about 5 minutes to set up the morning review — down from 45 minutes of manual spreadsheet work.

Limitations to be aware of

ML forecasting is not magic. A few honest caveats:

The model is only as good as your data. If your PMS has gaps, duplicate profiles, or inconsistent rate codes, the model will learn bad patterns. Data cleaning is 60% of the work.
Black swan events break it. The model won't predict a pandemic, a political crisis, or a road closure cutting off access to your property. It needs human override capability built in.
Retraining matters. Set up a monthly retraining pipeline so the model incorporates recent data — particularly important after demand shocks.

Is it worth it?

For a property doing CHF 5M+ in annual revenue, even a 2% improvement in RevPAR from better demand anticipation is worth CHF 100k. The Azure ML compute cost for this setup runs under CHF 50/month. The ROI case is straightforward.

For smaller properties, the simpler approach — a well-built Power BI dashboard with YoY comparisons and pace tracking — often delivers 80% of the value at 10% of the complexity. Start there, and graduate to ML when you've exhausted what descriptive analytics can tell you.

← Back to Blog