Как мы увеличили RevPAR на 18% с помощью AI-ценообразования

Московский бутик-отель на 40 номеров сталкивался с классической проблемой: выручка колебалась от месяца к месяцу, а менеджеры устанавливали цены интуитивно. В выходные цены занижали, в будни слишком завышали. Из-за этого хорошие номера пустовали, дешёвые номера были забронированы, а выручка платила. Мы реализовали систему AI-ценообразования на основе градиентного бустинга, которая автоматически рассчитывает оптимальную цену на каждый номер каждый день. За 4 месяца тестирования RevPAR (средний доход на номер) увеличился на 18%, при этом occupancy (заполняемость) не упала. Это case study о том, как работает такая система, какие данные нужны, как её реализовать и какие проблемы ждут в production.

---

RevPAR (Revenue Per Available Room) — это средняя выручка, полученная с одного доступного номера за день.

Формула: RevPAR = (Total Room Revenue) / (Total Available Rooms × Days)

Или проще: RevPAR = Average Daily Rate (ADR) × Occupancy Rate

Пример: если в отеле 40 номеров, в месяц они приносят 16M рублей, то RevPAR = 16M / (40 × 30) = 13.3K в день.

Это главная метрика в HoReCa. Можно увеличивать выручку двумя способами:

• Поднять цену (ADR) — рискуешь потерять клиентов
• Заполнить номера (Occupancy) — надо привлекать больше гостей

А лучше: поднять цену в нужный момент, когда спрос высокий, и опустить в спад. Это и есть динамическое ценообразование.

---

В нашем отеле было примерно так:

• Пятница–суббота: цена 4,500 рублей (спрос максимален, но это было установлено месяц назад, и спрос оказался выше ожидания)
• Вторник: цена 2,800 (менеджер боялся, что номера не забронируют, хотя приехала конференция)
• Среда перед праздником: цена 2,800 (забыли про праздник, цена не изменена)

Проблемы:

• Задержка реакции: изменить цену в системе — 20 минут, обновить на OTA (Booking, Agoda) — от 2 часов до суток. К тому времени спрос прошёл.
• Субъективность: два менеджера установят разные цены в одну и ту же дату.
• Неполная информация: менеджер не знает про конференцию в соседнем отеле, про погоду, про праздник за 30 дней.
• Cannibalisation: не учитывают, как скидка на эту дату повлияет на бронирования на соседние даты.

Результат: в пиковые дни цена занижена на 15–25%, теряется выручка; в спадные дни цена завышена, номера стоят пусто.

"ML модель не забывает про праздники, не устаёт анализировать 2 года истории, и может обновить цену в OTA за 5 минут, пока на сайте отеля — за 1 секунду."

---

Компоненты системы:

1. Data Pipeline — собирает данные из PMS (Property Management System), OTA, погодного API, календаря праздников
2. Feature Engineering — преобразует сырые данные в features (признаки) для модели
3. ML Model — предсказывает спрос и рассчитывает оптимальную цену
4. Price Engine — применяет рекомендации к системе бронирований
5. Monitoring — отслеживает RevPAR, качество предсказаний, anomalies

Данные, которые мы собирали:

• Историческая информация о бронированиях: дата check-in, длина stay, тип номера, цена, source (OTA/Direct/Corporate)
• Сезонность и праздники: день недели, месяц, российские праздники, школьные каникулы
• Внешние факторы: температура и погода, события в городе (конференции, фестивали), курс валюты
• Конкурентные данные: цены у конкурентов (собирали через API Booking.com, вручную с сайтов)
• Pace: сколько номеров уже забронировано на эту дату, как быстро растёт booking curve

Как мы готовили данные:

В Python на Pandas/Numpy:

1. Экспортировали историю бронирований из PMS (2 года данных, ~15K бронирований)
2. Очищали данные: удаляли выбросы, обработки missing values, outliers (например, бронирование по цене 100 рублей — явно ошибка)
3. Создавали признаки:
   • day_of_week, is_weekend
   • days_until_checkin (за сколько дней до приезда забронировали)
   • length_of_stay
   • occupancy_forecast (прогноз заполняемости на эту дату)
   • competitor_avg_price
   • is_holiday, days_from_holiday
   • rolling_avg_price (средняя цена за последние 30 дней)
4. Нормализовали числовые признаки (StandardScaler)
5. Разделили на train/val/test с временным фильтром (не random split!): train на первый год, validation на второй год, test на последний месяц

Выбор модели: Gradient Boosting (XGBoost)

Мы пробовали несколько подходов:

• Linear Regression — слишком просто, R² = 0.41
• Random Forest — лучше, R² = 0.62, но медленный для inference
• XGBoost — R² = 0.78, быстрый, хорошо интерпретируемый. Выбрали этот.

Модель предсказывает: какова будет вероятность booking если установим цену X на дату Y для номера типа Z?

На основе этой вероятности рассчитываем оптимальную цену, которая максимизирует ожидаемую выручку:

Expected Revenue = Probability of Booking × Price

Price находим через hill climb алгоритм (пробуем цены в диапазоне ±30% от baseline и выбираем, что даёт макс выручку).

---

Мы не просто включили AI на всех номерах сразу. Были опасения:

• Будут ли гости довольны высокими ценами?
• Повлияет ли на репутацию на OTA?
• Правильно ли считает модель?

Стратегия rollout (4 месяца):

Месяц 1: Пилот на 10 номерах

• 10 из 40 номеров переводим на AI-ценообразование
• Остальные 30 остаются на ручном управлении менеджера
• Каждый день сравниваем метрики (ADR, occupancy, RevPAR) по контрольной и тестовой группе
• Результат: AI номера показали +12% RevPAR, но -3% occupancy (цена часто была выше)

Месяц 2: Калибровка модели

• Добавили constraint: не поднимаем цену больше чем на 20% выше исторического максимума для этой даты
• Добавили "цены конкурентов" как более важный feature
• Результат: RevPAR +14%, occupancy -0.5% (почти вернулась)

Месяц 3: Расширение на 50% номеров

• Переводим 20 номеров на AI (всего 30 из 40)
• Продолжаем мониторить
• Результат: RevPAR +16%

Месяц 4: Полный rollout

• Все 40 номеров на AI-ценообразовании
• Финальный результат за месяц: RevPAR +18%, occupancy -0.8%

---

Модель может быть идеальной, но если цены не обновляются в системе бронирований, это бесполезно.

Архитектура интеграции:

1. PMS (Property Management System) — Мастерская Гостеприимства (системы Protel, Ростелеком, собственные)
2. Channel Manager — промежуточный слой (мы использовали Channelmanager.com)
3. OTA — Booking.com, Agoda, Яндекс.Путешествия, Ozon Travel

Процесс обновления цен:

Каждый день в 6:00 UTC (9:00 по Москве):

1. ML модель запускается на сервере, рассчитывает оптимальные цены на 90 дней вперёд
2. API нашего сервиса отправляет обновления в Channel Manager через REST API
3. Channel Manager распространяет цены на все OTA (Booking, Agoda и т.д.)
4. OTA получают обновления в течение 1–6 часов (зависит от партнёра)
5. На сайте отеля цены обновляются в real-time (интегрировали API с фронтендом)

Технические вызовы:

• Rate limiting — Booking позволяет обновлять цены 1 раз в час, не более 3000 обновлений в день. Мы пакуем обновления по 30 номеров в один запрос.
• Задержка обновления — от момента расчёта до видимости в Booking может пройти 6 часов. Критично в пиковые дни.
• Fallback логика — если API OTA упал, система должна откатиться на последние известные цены.
• Мониторинг — проверяем каждый час, что цены в OTA совпадают с ожидаемыми. Если расхождение >5%, алерт.

"Интеграция с OTA занимает 60% усилий в проекте, но именно она дает 90% результата. Без неё модель просто красивая статистика."

---

Что сработало:

• 18% рост RevPAR за 4 месяца. Без дополнительного Marketing.
• Consistency — цены устанавливаются по одной логике, без субъективности менеджера.
• Скорость реакции — система реагирует на изменения за часы, менеджер — за дни.
• Занимает мало времени — настроили, запустили, 1 раз в день проверяем метрики.

Что было трудным:

• Качество данных по конкурентам. Мы собирали цены вручную и парсили сайты, это хрупко. К концу проекта решили просто использовать внутренние метрики.
• Переговоры с OTA. Booking чуть не заблокировал отель за "слишком частые обновления цен". Пришлось согласовывать.
• Доверие менеджеров. Первый месяц они всё проверяли, думали, что модель ошибается. Когда увидели результаты, стали верить.

Уроки:

• Не переусложняйте модель. Мы пробовали Neural Networks, XGBoost был проще и точнее.
• Constraint очень важны. Без них модель выставляет цены, которые отпугивают гостей. С constraints она работает как нужно.
• A/B тестирование обязательно. Только так узнаёшь, что именно работает, а что нет.
• Мониторинг production важнее качества модели. Идеальная модель, которая не обновляется в OTA, — пустая трата времени.

---

Минимальные требования:

• История бронирований: минимум 1 год, лучше 2. Каждая бронь: дата, цена, длина stay, тип номера.
• PMS система, которая позволяет изменять цены через API или CSV загрузку.
• Доступ к данным конкурентов (или готовность собирать их вручную).
• Инструменты: Python (scikit-learn, XGBoost), базовые знания ML, DevOps для deployment.

Timeline:

• Неделя 1–2: сбор данных, EDA, feature engineering
• Неделя 3–4: обучение модели, baseline
• Неделя 5–6: интеграция с PMS и Channel Manager
• Неделя 7–8: тестирование, A/B пилот, мониторинг

Бюджет для отеля из 40 номеров:

• Разработка и интеграция: 400–600K руб
• Обслуживание и мониторинг: 50–100K в месяц (на первый год)
• ROI: 67.5K дополнительного дохода в месяц, окупаемость ~6–8 месяцев

Выводы: AI-ценообразование работает. RevPAR +18% — это не фейк. Но это не волшебство: нужны хорошие данные, правильная интеграция и постоянный мониторинг. Для отеля цепочки (50+ номеров) это рентабельно в первый год.