инструкция30 сентября 202610 мин чтения

Динамическое ценообразование в отеле: с чего начать

Статичный прайс - это когда стандарт стоит 5 000 ₽ и 15 января, и 3 мая, и в дни городского форума, на который съехалась тысяча человек. Отель с такой тарифной сеткой теряет деньги дважды: в пик продаёт дешевле, чем рынок готов платить, а в несезон стоит дороже спроса и держит пустые номера. Динамическое ценообразование - это способ перестать терять и там, и там.

Я 10 лет продаю проживание в отелях и видел обе крайности: отели, где цену не меняли годами «чтобы гости не обижались», и отели, где revenue-менеджер крутил тарифы по пять раз в день без единого записанного правила. Работает не софт и не интуиция, а система: сигналы → правила → контроль по метрикам. В этой инструкции - как её собрать с нуля, сначала руками, потом с автоматизацией.

Сразу зафиксирую: никаких обещаний «+X% к выручке» здесь не будет. Все цифры эффекта, которые вы встречали в рекламе инструментов, - заявления вендоров, я их ниже так и помечаю. Что даёт динамика конкретно вашему отелю - покажет только ваш RevPAR через несколько месяцев дисциплинной работы.

Что такое динамическое ценообразование и почему статичный прайс теряет деньги?

Коротко: это управление ценой номера вслед за спросом на конкретную дату заезда. Не «сезонный прайс» с двумя колонками «лето/зима», а цена, которая реагирует на загрузку, темп бронирований и события.

Номер - скоропортящийся товар. Непроданная ночь 14 марта сгорает навсегда: её нельзя положить на склад и продать в апреле. Поэтому у отеля два симметричных риска:

Главный индикатор здесь - глубина бронирования: за сколько дней до заезда гости выкупают номера. Если даты «закрываются» за 60-90 дней - вы недооценены. Если шахматка заполняется только в последние 2-3 дня - переоценены или невидимы для спроса. Статичный прайс этих сигналов не слышит по определению.

Какие сигналы использовать для управления ценой?

Коротко: четыре сигнала, и все четыре у вас уже есть - в шахматке, в отчётах PMS и в открытых ценах конкурентов. О том, какие системы эти отчёты дают, я писал в обзоре программ для гостиницы.

Загрузка на дату

Базовый сигнал: сколько процентов фонда уже продано на конкретную дату заезда. Важно смотреть не «загрузку месяца», а загрузку по каждой дате отдельно: в одном и том же июле пятницы и субботы могут стоять по 95%, а вторники - по 40%, и цена на них должна быть разной.

Темп бронирований (pick up) и окно бронирования

Загрузка - это фотография, pick up - видео: сколько броней на дату прибавилось за последние сутки или неделю. Дата с загрузкой 50% за 90 дней до заезда и дата с теми же 50% за 5 дней до заезда - это противоположные ситуации: первая идёт с опережением, вторая - провал. Поэтому правило всегда читается в паре «загрузка + сколько дней осталось».

События

Форумы, концерты, матчи, вахтовые заезды подрядчиков, выпускные - всё, что разово выкупает город. Календарь событий - бесплатный revenue-инструмент: его ведут руками в обычной таблице, и он окупается первым же закрытым по хорошей цене уикендом.

Цены конкурентов

5-7 объектов, с которыми вас реально сравнивает гость: та же локация, тот же класс, тот же тип размещения. Смотреть их цены на ключевые даты можно и руками через агрегаторы, автоматизированно - через rate shopper (есть и у TravelLine, и у Bnovo). Важно: конкуренты - это ориентир, а не руль. Если сосед демпингует - это не команда падать вслед.

Ручные правила: как запустить динамику без софта?

Коротко: динамическое ценообразование - это не софт, а правила. Софт лишь исполняет их без выходных. Поэтому начинать надо с ручной модели: она бесплатная, запускается за неделю и заодно готовит данные, которые потом попросит любой автоматический инструмент.

Пошагово:

  1. Зафиксируйте базовый тариф и минимальную цену. Базовый - цена стандарта в «обычный» день сезона. Минимальная - порог, ниже которого не продаём никогда, ни при какой загрузке: она должна покрывать себестоимость ночи и комиссию канала.
  2. Разбейте год на 3-4 сезона спроса. Не по календарю, а по факту: поднимите загрузку и ADR за прошлые год-два по месяцам и дням недели. У каждого сезона - свой базовый тариф.
  3. Постройте лестницу цен от загрузки. Привяжите надбавки к интервалам загрузки на дату - см. таблицу ниже.
  4. Добавьте поправку на окно бронирования. Одна и та же загрузка близко к дате и за три месяца до неё - разные решения.
  5. Назначьте ответственного и ритм. Один человек, 2-3 пересмотра цен в неделю по 20-30 минут, каждое изменение - с записанной причиной. Без ритма правила умирают за месяц.

Лестница правил может выглядеть так (условный пример - интервалы и шаги надо калибровать под свой объект):

Загрузка на дату заездаДо заезда больше 30 днейДо заезда меньше 30 дней
до 40%базовый тарифминус 5-10% от базового, но не ниже минимальной цены
40-60%базовый тарифбазовый тариф
60-80%плюс 10%плюс 15%
80-90%плюс 20%плюс 25%
выше 90%плюс 30% и minstay 2 ночиплюс 30-40%

И два ограничителя поверх таблицы: не менять цену на дату чаще раза в день и не двигать её больше чем на 10-15% за шаг. Плавность важнее скорости - почему, разберём в ошибках.

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

Автоматизация: что умеют инструменты динамического ценообразования?

Коротко: когда ручная модель прожила 2-3 месяца и правила устоялись, их можно отдать машине. У обоих главных российских вендоров отельного софта есть свои модули; чем сами платформы отличаются по деньгам, я разбирал в сравнении TravelLine или Bnovo. Здесь - только про revenue-функции, все факты с официальных сайтов, проверено 30 сентября 2026 года.

TL: Price Optimizer (TravelLine)

Инструмент рекомендует цены на каждый день на основе загрузки; опционально учитывает сезонность, глубину бронирования и цены конкурентов (сравнение с 10 конкурентами, динамика позиции за 90 дней). Целевой уровень задаётся стратегией «выше рынка / ниже рынка / в среднем по рынку». Есть «Справочник событий» - праздники и мероприятия показываются подсказками в календаре цен. Два режима: ручной, где вы подтверждаете или отклоняете рекомендации, и «Автопилот», где инструмент сам меняет цены на сайте и в каналах через менеджер каналов; для событий настраиваются дни-исключения с возвратом в ручной режим.

Показательно, кому TravelLine сам адресует инструмент: отелям со среднегодовой загрузкой от 40%, фондом больше 10 номеров, наличием конкурентов и эластичным спросом. Это честная рамка: на 8 номерах с загрузкой 25% автоматизация цен не окупится - сначала надо чинить канал продаж, а не тариф.

Цена - комиссия 0,5% от всех онлайн-броней, но не больше 20 000 ₽/мес. На промо-странице вендор приводит расчётный пример, где отель с динамикой зарабатывает «на 62% больше» отеля со статичным прайсом, - это иллюстрация TravelLine на модельных цифрах, не результат, который стоит закладывать в план.

Bnovo RMS

У Bnovo revenue-блок описан как «динамика цен, minstay, цены конкурентов, отчёты по загрузке, ADR и RevPAR». Механика - правила: вы задаёте, как цена меняется в зависимости от загрузки и дат, дальше система применяет их автоматически 24/7. То есть та самая лестница из прошлого раздела, только исполняемая без вашего участия.

Отдельно отмечу автоматику minstay: можно разрешать брони от одной ночи при свободном фонде и ставить минимум три ночи при высоком спросе, а короткие «окна» между бронями система расшивает сама, снимая ограничение. Для шахматки с длинными заездами это закрывает вечную боль битых окон.

По тарифной сетке динамика цен и minstay входят в тариф «Рост» (400 ₽ за номер в месяц при оплате за 3 месяца), а анализ конкурентов - только в «Максимум». Маркетинговые плашки «+30% рост дохода» и «+25% потенциал роста RevPAR» на странице RMS - заявления Bnovo без опубликованной методологии; отношусь к ним как к рекламе, чего и вам советую.

Что автоматизация не сделает за вас

Ни один модуль не знает вашу минимальную цену, себестоимость ночи, календарь местных событий и то, каким сегментам вы вообще хотите продавать. Автопилот исполняет стратегию - придумать её всё равно придётся человеку. Поэтому порядок именно такой: сначала ручная модель, потом софт.

Типичные ошибки при внедрении динамических цен

Коротко: почти все провалы динамики - не про математику, а про дисциплину. Вот что я вижу чаще всего.

Демпинг в несезон

Первая реакция на пустую шахматку - уронить цену. Но в мёртвый сезон спрос неэластичен: скидка 30% не рождает гостей, которых нет в городе, зато режет ADR и приучает постоянных гостей ждать распродажу. Нижняя граница - ваша минимальная цена, дальше работают не скидки, а пакеты, длинные проживания и работа с сегментами, которые едут именно в несезон.

Резкие скачки цен

Гость смотрел номер утром за 5 000 ₽, вернулся вечером - 7 500 ₽. Для алгоритма это «реакция на спрос», для гостя - повод уйти к соседям и написать про вас в отзывах. Отсюда ограничители: шаг 10-15%, не чаще раза в день. Плавная лестница собирает ту же выручку без ощущения казино.

Игнор паритета каналов

Подняли цену на сайте, забыли про офлайн-выгрузку в один из каналов - и агрегатор продаёт вас дешевле вашего же сайта. Гость это видит за 30 секунд, и весь смысл прямых продаж рушится: зачем бронировать напрямую, если в ОТА дешевле? Синхронизация через менеджер каналов - обязательное условие динамики; сколько при этом каждый канал стоит вам в комиссии - удобно посчитать в калькуляторе комиссий ОТА, а как выстроить сам прямой канал - в разборе прямых продаж отеля.

Правила без минимальной цены

Автоправило «при загрузке ниже 30% давать минус 20%» без жёсткого пола однажды продаст номер ниже себестоимости. Минимальная цена задаётся до запуска любых правил, ручных или автоматических.

Изменения без журнала

Если цену меняли «по ощущению» и нигде не записали причину, через три месяца невозможно понять, какие решения сработали. Журнал изменений - дата, было/стало, причина - это 30 секунд на запись и единственный способ учиться на собственных данных.

Как измерять эффект: почему RevPAR, а не загрузка?

Коротко: загрузка и ADR по отдельности врут. Загрузку легко купить демпингом, высокий ADR - получить на трёх проданных номерах. Честный итог работы с ценой показывает RevPAR - выручка на доступный номер, которая сводит обе метрики в одну. Формулы и разборы с примерами - в отдельной статье про RevPAR, ADR и загрузку, здесь - только принцип контроля:

И последнее. Динамическое ценообразование усиливает тот канал, в котором вы продаёте. Если 80% броней приходит из ОТА, рост цен в первую очередь увеличит комиссию, которую вы платите агрегаторам. Поэтому параллельно с тарифами стоит наводить порядок в прямых продажах - мы в «Свой Гость» начинаем с диагностики: разбираем воронку и тарифную политику и считаем, сколько денег отель отдаёт посредникам и сколько можно вернуть.

Источники

Все факты о продуктах - с официальных страниц вендоров:

Тарифы и состав продуктов меняются - перед решением сверяйте страницы вендоров. Числовые примеры лестницы цен в статье - условные, калибруйте под свой объект.

Сколько прямых броней теряет ваш отель?

Диагностика прямых продаж отеля: разбираем воронку и тарифную политику, считаем, сколько отель отдаёт агрегаторам и сколько можно вернуть прямыми бронями.

Записаться на диагностику