Один тип номеров продается за месяц до заезда, второй начинает двигаться только за неделю, а третий регулярно остается последним доступным.
Можно продолжать каждый день менять цены.
Можно остановиться и проверить, почему категории ведут себя по-разному.
Со второго варианта начинается работа с revenue-гипотезами.
Гипотеза позволяет перевести наблюдение из отчета в управленческое действие. Менеджер видит отклонение, предполагает его причину, меняет один из элементов продаж и затем проверяет результат.
Без этого revenue management постепенно превращается в набор повторяющихся операций.
Цена меняется. Ограничения открываются и закрываются. Скидки запускаются. Через месяц уже никто не помнит, зачем было принято решение и помогло ли оно вообще.
Гипотеза начинается с отклонения
Искать идеи ради количества не нужно.
Сначала появляется рабочий признак.
Например, воскресенье три месяца подряд закрывается хуже субботы.
Категория «Стандарт» продается за 25 дней до заезда, а более дорогая категория остается свободной до последней недели.
Средний LOS снизился с 2,4 до 1,7 ночи.
Прямой канал увеличил количество бронирований, но его доля в номеро-ночах почти не изменилась.
Отмены из одного OTA выросли, причем основная часть приходит за два дня до заезда.
Это еще не гипотезы.
Это наблюдения, из которых можно начать расследование.
Сначала нужно проверить, действительно ли проблема существует
Одна слабая дата ничего не доказывает.
Если воскресенье 12 июля продалось хуже субботы, причиной могло быть конкретное мероприятие, группа в соседнюю дату или случайное изменение спроса.
Поэтому перед формированием гипотезы нужно проверить повторяемость.
Если воскресенья отстают четыре недели подряд, прошлый год показывает похожее поведение, а текущий pickup снова идет медленнее субботы, уже появляется закономерность.
То же происходит с категориями.
Один случай, когда дорогой номер продался позже дешевого, нормален.
Если это повторяется большую часть сезона, появляется основание искать причину в ценовой архитектуре, составе категории, ее позиционировании или структуре спроса.
Хорошая гипотеза начинается с подтвержденной проблемы, а не с ощущения менеджера.
Наблюдение еще не объясняет причину
Представим, что средний LOS снизился.
Можно сразу запустить скидку за проживание от трех ночей.
Но сначала нужно понять, почему LOS изменился.
Возможно, стало больше бронирований из канала, где гости обычно приезжают на одну ночь.
Возможно, увеличилась доля делового спроса.
Может быть, минимальное проживание на выходные сняли слишком рано.
Или общий показатель снизился из-за одного конкретного дня недели.
Одно и то же отклонение может иметь несколько причин.
Поэтому между наблюдением и действием должен появиться еще один этап — диагностика.
Какие данные проверять перед формированием гипотезы
Набор показателей зависит от проблемы.
Если проседает загрузка, менеджер смотрит темп продаж, рынок, окно бронирования, отмены и доступность.
Если проблема находится в ADR, нужно проверить категории, дни недели, структуру каналов, глубину скидок и момент, когда продавался основной объем.
При снижении LOS стоит разобрать каналы, сегменты, дни недели и окно бронирования.
При изменении доходности OTA полезно проверить комиссию, скидки, ADR, количество номеро-ночей и чистый доход канала.
Главный принцип один.
Нужно найти показатель, который объясняет поведение основного результата.
Как выглядит нормальная revenue-гипотеза
Рабочую гипотезу можно собрать в простой конструкции:
Мы видим [проблему].
Предполагаем, что она возникает из-за [причины].
Если изменить [действие], то ожидаем получить [результат].
Результат проверим по [показателям] за [период].
Например:
«Категория Standard Plus продается значительно раньше остальных категорий. Предполагаем, что разница в цене со стандартным номером слишком мала. Если увеличить разрыв между категориями с 700 до 1 200 р, часть раннего спроса останется в стандартной категории, а Standard Plus будет продаваться позже и по более высокому ADR. Проверим изменение окна бронирования, ADR и количества проданных номеро-ночей в течение четырех недель».
Здесь уже понятно, что происходит, почему команда предлагает изменение и какой результат будет считаться положительным.
«Поднять цену» — это действие, а не гипотеза
Это одна из самых частых ошибок.
Менеджер говорит:
«Моя гипотеза — поднять цену на 10%».
Проверить такую формулировку невозможно, потому что отсутствует причина и ожидаемый результат.
Зачем увеличиваем цену?
Какой сигнал показывает, что рынок готов ее принять?
Что должно произойти после изменения?
Какие показатели будем смотреть?
Полная версия может выглядеть иначе:
«Пятницы на ближайшие шесть недель продаются на 20–25% быстрее прошлого года, а текущая загрузка выше соседних дней. Предполагаем, что начальная цена пятницы занижена. Увеличиваем ее на 10% и проверяем, сохранится ли темп продаж при более высоком ADR».
Теперь появляется логика.
Один тест должен отвечать на один главный вопрос
Представим, что объект одновременно снизил цену, включил скидку на OTA, снял минимальное проживание и запустил рекламу.
Через неделю продажи выросли.
Что сработало?
Ответа нет.
Поэтому по возможности лучше менять один существенный фактор за раз.
В реальной работе отеля полностью изолировать эксперимент получается редко. Спрос продолжает меняться, конкуренты корректируют цены, появляются мероприятия и отмены.
Но хотя бы внутри собственных действий нужно снижать количество одновременно изменяемых параметров.
Иначе команда получает результат, который невозможно интерпретировать.
Перед тестом нужно зафиксировать точку А
Без исходных данных любая гипотеза через месяц превращается в воспоминание.
«Кажется, продажи стали лучше».
Этого недостаточно.
До изменения нужно сохранить показатели, которые будут использоваться при оценке.
Допустим, объект хочет увеличить минимальное проживание на пятницу и субботу.
Перед тестом стоит зафиксировать текущий LOS, количество бронирований, номеро-ночи, ADR, загрузку пятницы, загрузку субботы и долю дат, где ограничение реально повлияло на продажу.
После теста появится база для сравнения.
Выбирайте основной показатель заранее
Гипотеза может затрагивать десятки метрик.
Но один показатель должен отвечать на главный вопрос.
Например, объект увеличивает разницу в цене между категориями.
Главная цель — увеличить ADR более дорогой категории.
Тогда именно ADR становится основным показателем.
Окно бронирования, количество номеро-ночей и загрузка будут дополнительными.
Это важно, потому что отдельные показатели могут двигаться в разные стороны.
ADR вырос на 12%, а проданных номеро-ночей стало на 5% меньше.
Получился хороший результат или плохой?
Ответ зависит от исходной цели и итогового дохода.
Если основной показатель заранее не выбран, после эксперимента легко подобрать ту цифру, которая показывает удобный результат.
Смотрите на коммерческий результат
Гипотеза должна в итоге связываться с деньгами.
Например, менеджер решил увеличить LOS.
Средняя продолжительность проживания выросла с 1,8 до 2,2 ночи.
Формально тест успешен.
Но одновременно загрузка снизилась с 82% до 68%, потому что введенные ограничения отсекли часть короткого спроса.
Сам рост LOS в таком случае мало что дает.
Или другой пример.
Объект увеличил цену на 15%.
ADR вырос.
При этом количество проданных номеро-ночей сократилось настолько, что RevPAR снизился.
Поэтому промежуточный показатель нельзя превращать в конечную цель.
Менять нужно поведение продаж, а оценивать — влияние на коммерческий результат.
Пример гипотезы по категории
Объект видит, что стандартные номера заканчиваются за 20–25 дней до заезда.
Улучшенные категории продаются позже и часто требуют снижения цены в последнюю неделю.
Менеджер проверяет историю и видит, что разница между стандартом и улучшенной категорией составляет всего 500 р при базовой цене около 8 000 р.
Формируется гипотеза:
Проблема. Стандарт продается слишком рано, после чего часть спроса не переходит в дорогие категории.
Предполагаемая причина. Начальная цена стандарта слишком низкая относительно улучшенной категории.
Действие. Увеличить цену стандарта и изменить разницу между категориями.
Ожидаемый результат. Стандарт будет продаваться медленнее, часть спроса распределится на другие категории, общий ADR вырастет.
Проверка. Сравнить окно бронирования, ADR, RN и доход категорий с предыдущими сопоставимыми периодами.
Такую гипотезу уже можно проверить.
Пример гипотезы по дням недели
Воскресенье системно закрывается хуже пятницы и субботы.
Менеджер видит, что основная часть гостей бронирует пятницу и субботу на две ночи и выезжает в воскресенье.
При этом пятница хорошо загружается уже за три недели.
Возникает гипотеза, что отель слишком рано продает пятницу отдельно и теряет возможность получить трехдневные бронирования.
На части периода вводится минимальное проживание на даты повышенного спроса.
Дальше команда проверяет LOS, загрузку воскресенья, общий объем RN и доход всего периода.
Если воскресенье загрузилось лучше, но пятница потеряла значительный объем продаж, результат нельзя считать успешным.
Гипотеза должна улучшать общую экономику периода.
Пример гипотезы по OTA
Один канал увеличил количество бронирований на 30%.
Это выглядит хорошо.
После расчета выясняется, что рост произошел после подключения дополнительной скидки. ADR канала снизился, комиссия сохранилась, а чистый доход с номеро-ночи стал заметно ниже.
Гипотеза может звучать так:
«Дополнительная скидка увеличивает объем канала, но часть новых бронирований приходит за счет снижения доходности уже существующего спроса. На части дат отключаем скидку и сравниваем изменение количества RN, Net ADR и чистого дохода».
Здесь проверяется уже не количество продаж.
Проверяется экономический эффект инструмента.
Пример гипотезы по окну бронирования
Объект видит, что номеро-ночи в окне 21–30 дней продаются хорошо, но по ADR почти не отличаются от продаж за 8–15 дней.
Это может означать, что дальний спрос покупает номер дешевле, чем готов платить.
Менеджер увеличивает цены для дальнего окна на части будущих дат.
Если объем бронирований сохраняется, а ADR растет, ценовую логику можно распространить дальше.
Если pickup резко останавливается, изменение было слишком сильным или предположение оказалось неверным.
Гипотеза должна иметь срок проверки
Некоторые решения можно оценить через неделю.
Для других нужен сезон.
Если объект изменил цену на ближайшие выходные, эффект появится быстро.
Если тестируется новая логика раннего бронирования на лето, вывод через три дня ничего не даст.
Поэтому срок задается до начала проверки.
Он должен учитывать обычное окно бронирования объекта.
Если большинство гостей бронирует за 20 дней до заезда, проверять изменение через два дня рано.
Спрос еще не успел отреагировать.
Сравнивать нужно сопоставимые периоды
После теста менеджер видит рост продаж на 30% и фиксирует успешную гипотезу.
Но неделю назад был февраль, а теперь начались мартовские праздники.
Рост мог произойти без каких-либо действий.
Поэтому результат нужно сравнивать с максимально похожим сценарием.
Используют прошлый год с сопоставимыми днями недели, соседние даты с похожим спросом, контрольную группу дат или динамику рынка.
Идеального контрольного эксперимента в гостинице обычно нет.
Задача — максимально отделить эффект собственного действия от внешнего изменения спроса.
Корреляция еще не доказывает результат гипотезы
Цена выросла, после этого увеличился ADR.
Кажется, связь очевидна.
Но в этот же момент в городе могло начаться крупное мероприятие, конкуренты закрыли продажи, а рынок получил дополнительный спрос.
Поэтому формулировка результата должна оставаться аккуратной.
Лучше:
«После изменения цены ADR вырос на 8%, при этом темп продаж сохранился. Аналогичная динамика наблюдалась на большинстве тестовых дат, поэтому изменение можно использовать дальше».
Хуже:
«Повышение цены обеспечило рост ADR на 8%».
Второе утверждение требует гораздо более строгого подтверждения причины.
Неудачная гипотеза — нормальный результат
Менеджер предположил, что увеличение минимального проживания улучшит загрузку воскресенья.
Тест показал обратное.
Количество бронирований снизилось, воскресенье почти не изменилось, а пятница начала отставать.
Гипотеза не подтвердилась.
Это нормальная часть работы.
Команда теперь знает, что конкретное ограничение в текущей структуре спроса не работает.
Изменение нужно отменить, результат записать и использовать в следующих решениях.
Настоящая проблема возникает, когда эксперимент не дал результата, но его продолжают применять по привычке.
Фиксируйте гипотезы
Даже простая таблица сильно меняет качество работы команды.
В ней достаточно хранить дату, объект, найденную проблему, гипотезу, действие, исходные показатели, срок проверки и результат.
Через несколько месяцев появляется собственная база знаний объекта.
Команда уже знает, как реагировал спрос на изменение цен, какие ограничения работали в высокий сезон, как разные категории чувствовали изменение разницы в стоимости и какие скидки действительно приносили дополнительный объем.
Без фиксации эти знания остаются в голове конкретного сотрудника и постепенно теряются.
Сколько гипотез нужно проверять
Количество само по себе ничего не гарантирует.
Десять мелких изменений без итоговой проверки слабее двух полноценных тестов, которые привели к понятному решению.
Для регулярной работы важнее сам цикл.
Менеджер находит отклонение, формирует предположение, проводит тест и возвращается к результату.
Затем появляется следующее действие.
Если такой цикл постоянно работает, объект постепенно накапливает знания о собственном спросе.
Как понять, что гипотеза сформулирована плохо
Есть простой тест.
Другой revenue-менеджер должен прочитать формулировку и понять, какую проблему нашли, почему предлагают именно это действие и по каким данным будет принято решение.
«Попробовать поднять цены» — слабая гипотеза.
«Увеличить продажи прямого канала» — это цель.
«Протестировать MLOS» — это действие.
Рабочая гипотеза связывает все элементы:
наблюдение → предполагаемая причина → действие → ожидаемый результат → показатель → срок проверки.
Если одного из звеньев нет, итог будет сложно оценить.
Что делать после проверки
У теста есть несколько нормальных результатов.
Гипотеза подтвердилась. Изменение можно закрепить или распространить на похожие периоды.
Гипотеза не подтвердилась. Решение возвращается назад, а команда фиксирует результат.
Данных недостаточно. Тест продолжается или повторяется на более подходящей выборке.
Получен смешанный результат. Например, ADR вырос, но RN снизился. Тогда нужно оценить итоговую экономику и уточнить гипотезу.
Самое плохое завершение звучит так:
«Проверили. Вроде нормально».
Если после теста нет решения, цикл не завершен.
Пример полного цикла
Отель видит, что категория «Стандарт» на майские даты продана уже на 80%, а «Стандарт плюс» загружен только на 45%.
До заезда остается 30 дней.
При этом разница в цене между категориями составляет 400 р.
Менеджер предполагает, что стандарт стоит слишком дешево относительно следующей категории и забирает ранний спрос.
Цена стандарта увеличивается на 8%, а разница между категориями становится меньше.
До изменения фиксируются загрузка, ADR, pickup и текущая структура категорий.
Через две недели менеджер возвращается к данным.
Темп продаж стандарта снизился незначительно. «Стандарт плюс» начал получать больше бронирований. Общий ADR двух категорий вырос на 6%, а суммарный pickup сохранился.
Гипотеза получает подтверждение.
Эту логику можно использовать для следующих сопоставимых дат, продолжая контролировать реакцию спроса.
Так выглядит законченный revenue-тест.
Итог
Гипотезы нужны не ради постоянных экспериментов.
Они дают структуру решениям.
Менеджер сначала видит отклонение в данных, затем ищет возможную причину, выбирает действие и заранее определяет, какой результат будет проверять.
После теста он возвращается к цифрам и принимает решение.
Сохранить изменение. Отменить его. Повторить тест. Уточнить причину.
Так объект перестает управлять продажами через отдельные реакции и начинает накапливать знания о собственном спросе.
Главный принцип простой: каждое существенное изменение должно отвечать на конкретный вопрос, а после проверки команда должна получить новое правило для дальнейшей работы.