Как revenue management влияет на загрузку отеля

Управляющий смотрит на календарь: до заезда две недели, продано 40% фонда, в прошлом году на эту дату было 65%. Решение принимается за минуту — «давайте скидку 20%». Через неделю выясняется, что соседний отель в эти же даты стоит дороже и при этом почти распродан, а падение загрузки было не рыночным: просто в этом году не было того же автобусного заезда.

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

Что такое revenue management

Revenue management — это управление доходом через цену, доступность и ограничения продаж. Не «умение делать скидки» и не «поднять цены в сезон», а система, которая отвечает на три вопроса по каждой дате в календаре: по какой цене продавать, кому продавать в первую очередь и что закрыть, чтобы не отдать дорогую дату дёшево.

Управляют тремя рычагами:

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

Связь с загрузкой прямая, но не линейная. Загрузку можно нагнать скидками — и получить полный отель с провальной выручкой. Можно задрать цену и остаться с пустыми номерами и красивым средним чеком. Revenue management ищет точку, где произведение цены на загрузку максимально, и эта точка на каждую дату своя. Почему смотреть нужно именно на произведение, разбирали в материале про ADR, RevPAR и загрузку.

Почему мы взялись за эту статью

Про revenue management написано много, и почти всё — на уровне теории: сегменты, эластичность, прогноз спроса. Когда отельер дочитывает такую статью и открывает свою систему бронирования, он оказывается ровно там же, где был: непонятно, куда нажимать и с чего начинать.

Материала, где по шагам показано, как запустить динамическое ценообразование на инструментах, за которые отель уже платит, мы не нашли. Поэтому разбираем конкретную связку, которую сами используем на объектах: TravelLine + TravelDB.

Если у вас TravelLine — начинайте с него

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

Два инструмента, ради которых всё затевается:

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

Чего в TravelLine не видно: загрузка конкурентов

Rate Shopper показывает цену соседа. Он не показывает, продаётся ли сосед по этой цене. А это и есть главный вопрос: цена без загрузки не значит ничего.

Три ситуации, которые выглядят одинаково в мониторинге цен и требуют противоположных решений:

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

Настройка: уровни цен и динамический тариф

Дальше связка собирается в работающий механизм. Два обязательных шага в TravelLine:

• Уровни цен. Вместо одной цены заводится лестница: от минимальной, ниже которой продавать нельзя, до максимальной в пик спроса. Каждый уровень — это фиксированный набор цен по всем категориям и тарифам сразу. Обычно достаточно 8–12 уровней с шагом 5–10%.
• Динамический тариф. Тариф, который привязан не к конкретной цифре, а к текущему уровню цен. Когда меняется уровень, цена по всем связанным тарифам и каналам меняется автоматически, без ручной правки каждой строки.

Смысл лестницы в том, что решение сводится к одному действию: «поднять на уровень» или «опустить на уровень». Не нужно каждый раз придумывать цифру и вручную разносить её по категориям — и именно поэтому система переживает высокий сезон, когда на ручную работу нет времени.

Цифры условные, шаг и количество уровней считаются под конкретный отель. Как собирается сама сетка — сегменты, ограждения между тарифами, невозвратный и ранний — разбирали в статье про сегментацию и тарифную сетку.

Как это работает вместе

Когда уровни заведены, а данные о себе и о рынке есть, решение перестаёт быть спором на планёрке и становится правилом. Логика простая: смотрим на свою загрузку и на загрузку конкурентов на ту же дату.

Обратите внимание на третью и четвёртую строки. Обе выглядят как «у нас плохая загрузка», и в обеих скидка — неправильный ответ. Без данных о конкурентах отличить их друг от друга невозможно, и отель раз за разом лечит скидкой то, что скидкой не лечится.

Что это даёт в низкий сезон

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

Связка даёт три вещи, которых нет при ручном управлении:

• Видимость дат, где спрос есть. Карта спроса показывает, где рынок набирает бронирования раньше обычного: праздники, локальные события, длинные выходные. Эти даты нельзя отдавать по цене «мёртвого ноября».
• Понимание, где падает рынок, а где вы. Если проседают все — цену держат и работают со спросом: пакетами, событиями, сегментами. Если проседаете только вы — цена ни при чём.
• Скорость. Уровни цен позволяют реагировать в день, когда изменилась картина, а не через неделю, когда даты уже сгорели.

Именно поэтому связка TravelDB и инструментов TravelLine позволяет продавать больше и догружать отель в межсезонье: вы перестаёте применять одно решение ко всему месяцу и начинаете работать по датам. Чем ещё закрывают провалы между сезонами, кроме цены, — в материале про низкий сезон.

Пять ошибок на старте

• Включить оптимизатор на грязных данных. Пока часть броней не заведена в систему, а категории и квоты не совпадают с реальностью, любые рекомендации будут считаться по неправде.
• Собрать конкурентную группу «по размеру звёзд». Категория не равна конкуренции. В группу идут те, между кем гость реально выбирает.
• Ставить слишком широкий шаг между уровнями. Прыжок цены на 25% гость замечает и запоминает. Шаг 5–10% работает лучше и не ломает доверие.
• Не задать нижнюю границу. Без минимального уровня система в плохие даты будет опускать цену туда, где ночь перестаёт окупать обслуживание номера.
• Запустить и забыть. Правила требуют пересмотра хотя бы раз в квартал: меняется рынок, состав конкурентов и структура каналов.

Что делать дальше

Порядок запуска, если начинаете с нуля: навести порядок в данных и квотах, собрать честную конкурентную группу, подключить Rate Shopper и TravelDB, завести уровни цен, включить динамический тариф, задать правила перехода между уровнями и договориться, кто и с какой периодичностью смотрит календарь.

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

Если хотите, чтобы мы разобрали это на вашем объекте и показали настройку руками, — отправьте запрос. Посмотрим текущие тарифы, конкурентов и загрузку и скажем, что даст эффект в первую очередь.