Дополнительные услуги в отеле: как автоматизировать продажи после бронирования

Чтобы продавать дополнительные услуги после бронирования, отелю нужен не список предложений в сообщении, а управляемый маршрут: событие из брони → уместное предложение → подтверждение доступности и цены → заказ → оплата → исполнение. Начинать лучше с трёх–пяти услуг, у которых понятны владелец, срок ответа и правило возврата: завтрак, трансфер, поздний выезд, SPA или дополнительное место.

Concierge Online уже может быть гостевым слоем такого маршрута: показать настроенные объектом категории и услуги, варианты и атрибуты, дату или слот, собрать корзину, создать заказ и, если для объекта подключён платёжный сценарий, показать доступный способ оплаты. Но наличие каталога не гарантирует продажи: PMS, коммуникации, платёж и исполнение должны обмениваться доказуемыми статусами.

Что именно автоматизировать после бронирования

Дополнительная услуга — это отдельное обязательство перед гостем. Отель должен знать не только «что выбрано», но и можно ли исполнить заказ к нужному времени, кто его принял, оплачено ли требование и что делать при изменении брони. Поэтому полезно разделить маршрут на пять контуров.

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

Когда и что предлагать гостю

Oracle Hospitality в актуальной документации Nor1 описывает предложения в нескольких точках: после бронирования, до приезда и во время check-in. Там же доступность, содержание предложения, цена и статус рассматриваются как части одного управляемого процесса. Практический вывод не в том, что каждому объекту нужен тот же продукт, а в том, что момент показа должен зависеть от контекста брони и реальной способности исполнить услугу.

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

Минимальная модель предложения

Карточка услуги должна отвечать на операционные вопросы ещё до CTA. Минимальный контракт включает:

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

Для позднего выезда недостаточно написать «до 18:00». Нужно определить дату, конкретный номер или бронь, доступность, цену, момент окончательного подтверждения и влияние на доступ. Для трансфера дополнительно нужны направление, количество пассажиров, багаж, рейс и контакт. Для SPA — услуга, количество гостей, длительность, специалист или кабинет и допустимый слот.

Не смешивайте запрос, заказ и исполнение

Эти состояния отвечают на разные вопросы:

1. Запрос создан: гость сообщил намерение, но отель ещё ничего не обещал.
2. Заказ подтверждён: цена, время и ресурс согласованы.
3. Оплата подтверждена: провайдер вернул финальный статус для нужной суммы.
4. Передано в исполнение: назначен ответственный и дедлайн.
5. Выполнено или отменено: результат записан, гость уведомлён.

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

Как работает маршрут в Concierge Online

Подтверждено 25 августа 2026 года по текущему продукту: объект может настроить категории и карточки услуг; гостевой web- и mobile-контур умеет показывать услуги и варианты, собирать требуемые атрибуты, работать с датой и слотом, формировать заказ и корзину. В заказе поддерживается дальнейшая обработка, а доступные способы оплаты зависят от конфигурации объекта и конкретного сценария.

Это даёт базовый маршрут:

1. PMS или ссылка проживания идентифицирует объект и контекст гостя.
2. Concierge Online показывает разрешённые категории и предложения.
3. Гость выбирает вариант, заполняет обязательные данные, дату или слот.
4. Система создаёт заказ и передаёт его в операционный контур.
5. Если подключена онлайн-оплата, платёжный статус связывается с заказом.
6. Сотрудник или интеграция подтверждает и исполняет услугу.

Не подтверждено как универсальная функция: автоматическое изменение каждой PMS-брони после покупки, единый real-time остаток для любого SPA/ресторана/трансфера, персональная ML-рекомендация и автоматическая кампания по всем каналам. Такие возможности зависят от интеграции, конфигурации объекта и отдельного пилота; их нельзя обещать по умолчанию.

PMS, guest journey и исполнение — разные роли

PMS остаётся источником фактов о проживании, но не обязана быть каталогом всех услуг. Гостевой слой отвечает за понятный выбор и сбор заказа. Операционная система или сотрудник отвечает за ресурс и выполнение. Платёжный контур подтверждает деньги, но не заменяет исполнение.

Booking.com называет post-booking messaging отдельным контуром взаимодействия, привязанным к брони. Это полезная граница: сообщение доставляет предложение или статус, но авторитетные данные о цене, заказе и исполнении должны оставаться в системах, где ими можно управлять и сверять.

Пилот на 30 дней без выдуманной экономики

Неделя 1: выбрать услуги и владельцев

Возьмите три–пять услуг с повторяемым процессом. Для каждой назначьте владельца, часы доступности, дедлайн ответа, правило отмены и источник цены. Исключите предложения, которые команда не может гарантированно исполнить.

Неделя 2: собрать контракт и тесты

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

Неделя 3: запустить на ограниченной аудитории

Ограничьте один объект, одну группу броней или один канал. Не отправляйте одинаковое предложение всем гостям. Разделяйте сервисное сообщение о брони и маркетинговое предложение; правила согласия и электронной коммуникации зависят от юрисдикции и должны быть проверены для объекта.

Неделя 4: принять решение по данным объекта

Не используйте внешний «средний процент допродаж» как план. Считайте собственную воронку:

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

Подтверждено сегодня, roadmap и гипотезы

• Подтверждено сегодня: Concierge Online поддерживает настраиваемый гостевой каталог, варианты и атрибуты, даты/слоты, корзину, создание заказа и конфигурационно доступные платёжные методы. Конкретный набор услуг и интеграций определяется объектом.
• Roadmap объекта: связать выбранные услуги с фактическими остатками, PMS, платёжным статусом и исполнителями; настроить коммуникационный триггер и журнал исключений.
• Гипотеза: предложение в контексте брони повысит дополнительную маржу и снизит ручную переписку. Эффект измеряется только на данных пилота конкретного объекта.

FAQ

Сколько услуг выводить в первом запуске?

Три–пять. Малый каталог проще поддерживать актуальным, а команда быстрее обнаружит разрыв между заказом и исполнением.

Можно ли начать без интеграции с PMS?

Можно провести ограниченный пилот по безопасной ссылке и с ручным подтверждением, но контекст брони придётся проверять отдельно. Масштабировать такой маршрут без авторитетной связи с проживанием рискованно.

Когда списывать деньги?

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

Нужно ли отправлять предложение во все каналы?

Нет. Выберите один разрешённый канал и остановите каскад после подтверждённого результата. Дубли раздражают гостя и усложняют атрибуцию.

Что делать, если услугу оказывает партнёр?

Зафиксировать владельца подтверждения, SLA, цену, комиссию, отмену и доказательство исполнения. Для гостя отель всё равно должен показать один понятный статус.

Источники

• Oracle Hospitality Nor1: предложения до приезда и при заселении.
• Oracle Hospitality: встраивание upsell в digital guest journey.
• Booking.com Developers: post-booking messaging.
• Stripe: идемпотентное исполнение после оплаты.