Свяжите каждую бронь с источником обращения и доведите её учёт до выезда гостя. Тогда сквозная аналитика малого отеля покажет, какая реклама привела к проживанию, где гость отменил поездку и сколько денег осталось после возвратов и комиссий. Для начала достаточно общей таблицы: в ней нужно разделить заявки, бронирования и фактические заезды. Ниже разберём, какие сведения записывать, как учитывать переносы и незаезды и по каким данным сравнивать каналы продаж отеля в Беларуси.
Что считать фактическим бронированием?
Заранее договоритесь, что означает каждый статус. Заявка — это обращение с вопросом о размещении. Бронь появляется, когда отель подтверждает условия и закрепляет номер за гостем. Подтверждение ещё не означает, что гость приедет, даже если он внёс предоплату.
Для отчёта лучше использовать точные названия: «подтверждено», «отменено», «незаезд», «гость заехал», «проживание завершено». Слово «фактическое» без пояснения создаёт путаницу: администратор считает так бронь с предоплатой, а владелец — проживание после выезда. Если задача состоит в оценке рекламы по состоявшимся поездкам, опирайтесь на завершённые проживания.
Сквозная аналитика связывает рекламный канал, клик, заявку и продажу. Такой принцип описан в материале «Реклама и продвижение туристических услуг и агентств: виды, методы, примеры и стратегии». В отеле цепочку нужно продолжить до результата брони: отмены, незаезда или завершённого проживания. Иначе рекламный отчёт закончится раньше, чем станет известен результат поездки.
Начните с короткой памятки для администратора: когда менять статус и где отмечать возврат. Например, после отмены бронь остаётся в таблице со своим номером и источником обращения. Удалять строку нельзя: вместе с ней исчезнет информация о том, что канал привёл гостя, который затем отказался от поездки.
Какие сведения записывать от заявки до выезда?
Заведите отдельную строку на каждую бронь. Если гость сначала написал, затем позвонил и внёс предоплату через сайт, это одна поездка с несколькими обращениями. Найти её в учёте поможет внутренний номер брони.
Соберите сведения в понятные группы, чтобы администратор не искал нужное поле среди случайных заметок:
- Связь с обращением: номер брони, дата заявки, источник первого обращения и канал оформления.
- Даты поездки: плановый заезд и выезд, фактический заезд и выезд.
- Состояние брони: текущий статус, дата его изменения, причина отмены со слов гостя, если она известна.
- Деньги: стоимость проживания после изменений, полученные платежи, возвраты и комиссия площадки.
- История изменений: перенос дат, сокращение проживания, замена номера или исправление ошибки.
Источник обращения и канал оформления держите отдельно. Гость мог найти отель через рекламу, а забронировать по телефону. Если записать только «телефон», реклама потеряет связь с продажей. Для переходов из объявлений используйте UTM-метки — подписи в ссылках, которые помогают различать рекламные источники. Для звонка без такой связи запишите ответ гостя или отметку «источник неизвестен».
Не заменяйте неизвестный источник предположением администратора. Отдельная категория покажет, где отель теряет связь между обращением и бронью. Затем можно проверить конкретный участок: передаёт ли форма метки, сохраняет ли администратор источник при ручном оформлении.
Если бронь с сайта приходится заново вводить вручную, при выборе модуля бронирования для малого отеля проверьте передачу номера брони, источника и статуса. Попросите показать весь путь на тестовой записи, включая отмену и возврат.
Как учитывать отмены, переносы и незаезды?
Сохраняйте историю брони и меняйте её состояние. При переносе дат оставьте исходный номер, если речь о той же поездке. Запишите новые даты и дату изменения. Если система создаёт другую бронь, свяжите записи и исключите старую из числа действующих, иначе один гость превратится в две продажи.
Отмену и незаезд разделяйте. В первом случае гость сообщил об отказе, во втором не приехал к согласованному сроку. Это разные ситуации для работы администратора. Причину фиксируйте только тогда, когда она известна: «гость сообщил об изменении планов» точнее, чем догадка «нашёл дешевле».
Отдельно ведите статус поездки и движение денег. После отмены отель мог вернуть всю предоплату, вернуть её часть или оставить платёж согласно условиям брони. Ни один из этих вариантов не превращает отмену в состоявшееся проживание. Сумму, которая осталась после отмены, показывайте отдельно от оплаты за проживание.
После выезда сверьте план с фактом. Если гость сократил поездку, замените плановую стоимость на стоимость фактического проживания и проверьте возврат. Плановая сумма нужна для прогноза загрузки и поступлений, но оценивать завершённую поездку следует по итоговым данным.
Для контроля назначьте понятный момент сверки: администратор закрывает статус после выезда и проверки расчётов. Пока расчёты не завершены, оставляйте отметку «сумма требует сверки». Так предварительные сведения не попадут в итоговый отчёт без пояснения.
Как связать проживание с расходами на канал?
Сначала выберите период и правило отбора броней. Для оценки проживания за месяц можно взять поездки по дате выезда. Для проверки рекламы за месяц — обращения, которые пришли в этот месяц, и их последующие результаты. Эти отчёты отвечают на разные вопросы: гость способен обратиться в одном месяце, а приехать в другом.
Не делите рекламные расходы текущего месяца на все проживания этого же месяца без проверки связи между ними. Среди гостей будут те, кто забронировал раньше. Если поездки по новым заявкам ещё впереди, пометьте результат рекламного периода как предварительный и обновите его после выездов.
Для каждого канала соберите число подтверждённых броней, отмен, незаездов и завершённых проживаний. Долю отмен считайте как число отменённых броней, делённое на число подтверждённых броней в той же группе. Незаезды показывайте отдельно, чтобы не смешивать отказ до поездки с отсутствием гостя в день заезда.
Денежный результат считайте отдельно от количества поездок. Для завершённых проживаний возьмите итоговую плату за размещение с учётом возвратов и вычтите комиссию канала. Возврат учитывайте только один раз: если он уже уменьшил итоговую сумму, повторно вычитать его не нужно. Все суммы в рабочем отчёте приведите к белорусским рублям, BYN.
Такой остаток ещё не показывает прибыль отеля: из него не вычтены расходы на обслуживание гостей и другие затраты. Но он помогает увидеть, сколько отель получил от проживания после комиссии. Расходы на рекламу держите отдельной строкой и относите к тем обращениям, которые она привела.
У прямого бронирования тоже есть затраты на привлечение. Поэтому при сравнении стоимости прямых бронирований и площадок учитывайте рекламу и плату за инструменты оформления. Общие расходы распределяйте по заранее выбранному правилу и не меняйте его ради результата отдельного канала.
Типичные ошибки в учёте бронирований
- Считать предоплату завершённой продажей. Исправление: хранить статус поездки отдельно от платежей и проверять результат после выезда.
- Удалять отмены из таблицы. Исправление: сохранять бронь, источник обращения и дату отмены, даже если отель вернул все деньги.
- Считать перенос новой продажей. Исправление: сохранять номер брони или связывать старую запись с новой.
- Записывать все обращения по телефону в прямой канал. Исправление: отдельно отмечать источник знакомства с отелем и способ оформления.
- Сравнивать каналы, пока часть гостей ещё не приехала. Исправление: разделять предварительный отчёт и результаты поездок после выезда.
Рабочая схема уже складывается из обычного учёта: у брони есть источник, история статусов и итоговая сумма. Проверить её можно на одной завершённой поездке, проследив путь от обращения до расчёта. Сейчас за две минуты откройте таблицу броней и добавьте поле «Итог поездки» с вариантами «проживание завершено», «отмена» и «незаезд».
