Score = 50 + (OCC−50)×w₁ + (ADR−50)×w₂ + (RevPAR−50)×w₃ + (Pace−50)×w₄

Как это работает: каждый компонент оценивается от 0 до 100 по отношению к цели. Если OCC = цели, компонент = 100. Если вдвое ниже цели — компонент ≈ 50. Компоненты взвешиваются и складываются вокруг базы 50 баллов.

Будущие периоды: для месяцев, которые ещё не закончились, OCC рассчитывается по Booking Pace — прогнозу на основе текущего темпа бронирований. Pace добавляет 3-й компонент с весом 25%.

Цели: каждый компонент сравнивается с целевым значением. По умолчанию цели подбираются автоматически по текущему сезону Бали. Вы можете задать собственные цели через кнопку ⚙ на KPI-карточках или через ссылку «Цели» ниже HS.

LEVEL автоматически подбирает цели по текущему сезону. Низкий сезон — мягкие цели. Праздничный — максимальные ожидания.

Вы можете задать собственные цели через панель «Цели» — они всегда имеют приоритет над автоматическими.

Для будущих месяцев LEVEL строит прогноз продаж на основе двух методов:

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

2. Прошлогодний рост — продажи прошлого года, скорректированные на коэффициент роста (не более 2×). Учитывает сезонность и исторические тренды.

Финальный прогноз — среднее двух методов с консервативным ограничением (не более 1.5× от текущих данных on-the-books). Отображается полупрозрачными столбиками на графике.

ADR = Σ продажи за ночь ÷ количество ночей

Источник данных: суммы бронирований из Exely Channel Manager. Ночи группируются по дате проживания, а не по дате заезда — одно бронирование может попасть в разные месяцы.

Особенности каналов: для OTA (Airbnb, Booking.com) Exely возвращает нетто-сумму (после вычета комиссии OTA). Для Lyvin.co — гросс (что платит гость, включая 12% markup). ADR по Lyvin.co на ~12% выше сопоставимого OTA.

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

Автоцель ADR = базовый ADR × сезонный мультипликатор. Влияет на HS (вес ADR: 25–30%) и отображается полоской прогресса на KPI-карточке. Собственная цель задаётся через кнопку ⚙ на карточке ADR.

Левые переключатели (метрики) — расположены над левой шкалой. RevPAR и ADR включены по умолчанию. Можно добавить Глубину и LOS. Каждая метрика — отдельная линия со своим цветом. Все используют левую шкалу (USD или дни).

Правый переключатель (столбики) — над правой шкалой. OCC показывает загрузку в процентах (цвет по уровню), Продажи — доход в USD. Переключатель синхронизирован со всеми тремя графиками Динамики — при переключении на одном все три обновляются.

Пустоты в столбиках OCC — незаполненные ночи. Проверьте VHP Cloud: возможно, это walk-in или comp stay, которые не отражены в Exely.

ADR падает при росте OCC — слишком агрессивные скидки. Гости приходят, но платят мало. Проверьте промо-тарифы.

Lead Time < 7 дней — last-minute бронирования. Можно поднять цену: гости готовы платить. Lead Time > 30 дней — ранние пташки, предложите long stay скидку.

Переключите на Продажи — столбики покажут доход в USD. Сравните с линией RevPAR: если RevPAR растёт, а продажи стагнируют — проблема в количестве ночей. Если наоборот — цена снижается.

Выходные vs будни — есть ли разрыв в OCC? Серые полосы на графике помогают увидеть паттерн. Если будни пустые — нужен промо-тариф.

Для Bingin (10 вилл, 2 категории) доступен фильтр по категориям над левой шкалой: Все, A, B.

Категория A — виллы с руфтопом (Rooftop). Премиальный сегмент, ADR обычно на 15–22% выше категории B.

Категория B — виллы с садом (Garden). Стандартный сегмент.

Фильтр пересчитывает все линии каналов и агрегат только по выбранной категории. Для Berawa (1 категория) фильтр скрыт.

Отель устанавливает базовый тариф (USD) в Exely master rate plan. Exely применяет маркапы (наценки) для формирования гостевых цен на каждом канале. Маркап ≠ комиссия — это разные числа.

Расхождение каналов — если один канал сильно дешевле остальных, проверьте тарифный план в Exely. Возможна ошибка в настройке наценок.

Сезонность — ADR должен расти в пик и holiday-периоды. Если линии плоские — сезонные тарифы не настроены в Exely. Сезонные фоны на графике помогают увидеть соответствие.

Lyvin.co ADR выше OTA — это нормально (гросс vs нетто). Но если разница >20% — гости могут выбирать OTA как более дешёвый канал.

Много пунктира (оценки) — по каналу мало бронирований. Переключите на Продажи (правый переключатель), чтобы увидеть объём продаж и оценить долю канала.

Провалы на линиях — промо-акции OTA или ошибка в тарифах. Проверьте конкретные бронирования за эти даты.

OCC = soldNights ÷ min(TOTAL_ROOMS × daysInPeriod, nightsToToday)

Cap at today: для текущего месяца знаменатель ограничен днями до сегодня. Это предотвращает искусственное занижение OCC будущими датами, когда бронирования ещё могут поступить.

Пример: если сегодня 15 марта и продано 48 ночей, OCC = 48 ÷ (4×15) = 80%, а не 48 ÷ (4×31) = 39%.

Целевой OCC зависит от сезона. В низкий сезон 60% — норма. В праздничный 92% — ожидание.

Автоцели учитываются в HS (вес OCC: 30–35%) и отображаются полоской прогресса на KPI-карточке. Вы можете задать собственную цель через кнопку ⚙ на карточке OCC.

RevPAR = Revenue ÷ (TOTAL_ROOMS × days) = ADR × Occupancy

Два пути к одному результату: RevPAR можно посчитать как общие продажи, делённые на все доступные виллы-ночи (включая пустые). Или как ADR, умноженный на OCC. Результат одинаковый.

Пример: ADR = $200, OCC = 75%. RevPAR = $200 × 0.75 = $150. Если OCC упадёт до 50%, RevPAR = $100, даже при той же цене.

Целевой RevPAR = целевой ADR × целевой OCC. Комбинация обоих сезонных мультипликаторов.

RevPAR = ADR × OCC. Производная метрика, отображается для справки. В расчёт HS не входит — OCC и ADR уже учитываются напрямую.

Пример цен (при нетто-ставке $200/ночь):
• Lyvin.co: гость платит ~$224 (наценка 12%)
• Airbnb: гость платит ~$238 (наценка 19%)
• Booking.com: гость платит ~$296 (наценка 48%)
• Отель получает ~$200 с любого канала

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

Налоги разные: Airbnb платит налоги в Гонконге, Booking.com — в Индонезии (10%), прямые бронирования через Lyvin.co — в Гонконге. Ставки и правила различаются. Также не учтены: ежемесячная комиссия Exely за букинг-движок, банковские переводы. Для точных финансовых данных используйте бухгалтерию.

Только онлайн: walk-in гости, comp stays и owner stays бронируются через VHP Cloud и не попадают в Exely. Реальные продажи отеля могут быть выше.

Под названием каждого месяца — цветные pill-бейджи с ключевыми метриками:

Аномалии — дни, OCC которых необычен для своего сезона. Алгоритм: Z-score OCC по сезону. Если |Z| > 1.5, день помечается жёлтой обводкой. Помогает быстро найти резкие скачки или провалы.

Гэпы — полностью пустые ночи (0 бронирований) между занятыми датами. Длинные гэпы (3+ ночей) проще продать, чем короткие (1–2 ночи). Цвета рамки: красная (1–2 ночи, критичный), оранжевая (3–6), зелёная (7+, легко заполнить).

Прогноз = (ночи TY / ночи LY на ту же дату) × итог LY

Guard: если данных прошлого года мало (<3 ночей на аналогичную дату), используется итоговый результат LY как база прогноза.

Пример: в марте LY к 15 числу было 80 ночей, итого 120. Сейчас к 15 марта — 100. Прогноз: (100/80)×120 = 150 ночей.

Ценовой движок LEVEL использует Pace как множитель при расчёте рекомендуемых цен:

Рекомендация = База × Сезон × Pace × Праздник × Gap

Occ(cat) = ночи(cat) ÷ (rooms(cat) × дни)
ADR(cat) = продажи(cat) ÷ ночи(cat)
Ratio = max(ADR) ÷ min(ADR)

Фильтрация: бронирования привязаны к категории по типу номера (roomTypeName). Знаменатель OCC = количество вилл в категории, а не общее число вилл.

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