Невостребованное бронирование обычно означает потерянный доход, а не плохого гостя
Бронирование на шесть человек в пятничный вечер — это обещание для менеджера зала. Официанты готовят столик, кухня отсчитывает порции. У двери выстроилась очередь пар без брони. Гость, который не пришёл и не сообщил, забирает этот вечер безвозвратно. Обычно виноват не гость, а отсутствие процесса подтверждения бронирования. Хороший процесс подтверждает присутствие гостя, прежде чем столик исчезнет из графика.
Прежде чем вообще дойдёт до подтверждения, во многих заведениях нет места, куда можно записать бронирование.
Запрос на столик тогда никуда не попадает, кроме памяти человека, который принял звонок.
Как выглядит цепочка подтверждений: бронирование → SMS → телефон → освобождение столика
- 01Бронирование
- →02SMS с подтверждением
- →03напоминание за день до
- →04телефон в день визита
- →05решение об освобождении столика
Первый SMS система отправляет автоматически, сразу после записи бронирования в системе бронирования. Второе сообщение, за день до визита, напоминает о времени и количестве гостей. Если гость не ответит до установленного времени, звонит менеджер зала или администратор. Только отсутствие ответа на третий контакт даёт основание освободить столик для другого.
Бронирование принято: {data}, {godzina}, {liczba osób}.
Напоминаем о завтрашней брони. Ответьте ДА, чтобы подтвердить.
Первое сообщение после сохранения брони, второе — за день раньше. Количество шагов и интервалы — настройка локации, а не результат измерения.
Количество шагов и интервалы между ними — это настройка для согласования с заведением, а не результат измерения — у нас нет исследования, которое указало бы здесь одно правильное число. Если через месяц бронирования всё ещё ждут ответа до последнего момента, цепочка не работает. Тогда нужно проверить интеграцию автоматических сообщений с CRM, а не добавлять ещё один SMS. Показатель, за которым стоит следить с первой недели, - это количество бронирований без ответа до начала сервиса.
Что-то здесь регулярно ломается: официант вручную освобождает столик в системе бронирования, но никто не обновляет CRM. Система тогда отправляет SMS гостю, бронирование которого уже не существует, а новый гость получает двойное бронирование столика. Ошибку видно по жалобам при входе, а не в отчёте — поэтому менеджер зала должен раз в день проверять журнал изменений в CRM, а не только бумажный график.
Кто наблюдает, работает ли цепочка вообще? На практике это делает менеджер зала, потому что у него есть доступ к CRM и он видит график в реальном времени. Владелец получает отчёт — не ежедневный, а только недельную сводку — и на этой основе принимает решение, нужно ли изменить порог предоплаты.
Кто и чем следит за бронированием: роли и инструменты
За процесс обычно отвечает менеджер зала, а не владелец лично. Владелец устанавливает правило, менеджер выполняет его ежедневно на основе данных из CRM, а не памяти смены. Подтверждающие сообщения отправляет CRM, подключённый к SMSAPI или WhatsApp Business, в зависимости от того, чем пользуются ваши гости. Сценарий, который связывает бронирование с отправкой, обычно создаётся в n8n — этот инструмент позволяет соединить систему бронирования с календарём зала без написания интеграции с нуля. Задаток, если заведение его берёт, проходит через BLIK или Przelewy24, а подтверждение оплаты само закрывает бронирование в системе.
- Телефон зала
- Система бронирования
- Сообщение от гостя
- CRM — карточка бронирования
- SMSAPI или WhatsApp Business
- Задача для менеджера зала
- BLIK / Przelewy24 — задаток
Это может быть каталог, портал бронирования или профиль в социальных сетях, без собственного сайта для записи бронирования. Номер телефона гостя, который попадает в CRM, — это персональные данные — их хранение подпадает под RODO, а о том, где физически оказываются такие данные, пишем отдельно.
Сколько стоит внедрение цепочки подтверждений
Автоматические сообщения, то есть SMS и WhatsApp, отправляемые без участия администрации, стерегут бронь, которая уже есть. Система бронирования, которая видит весь график столиков и сама блокирует даты, следит, чтобы эта бронь вообще появилась правильно. Интеграция с Telegram или WhatsApp открывает канал, по которому гость на самом деле отвечает. Это три звена одной цепочки подтверждений, а объём определяем после разговора о том, как она сегодня у вас устроена.
Складывать здесь нечего. Модуль сообщений и модуль бронирования стерегут два разных момента одного визита, а порядок зависит от того, где сегодня теряется больше столиков: на записи или на напоминании.
Предоплата как граница: когда просить задаток
Предоплата не устраняет no-show, но устанавливает границу риска. Бронирование без задатка — это декларация. Бронирование с задатком — это решение, за которое гость уже заплатил. Для столика на двоих задаток обычно не имеет смысла — стоимость обработки платежа превышает риск. Для группового бронирования, первого причастия или мероприятия с установленным меню на человека задаток защищает кухню от покупки продуктов для гостя, который не появится.
Порог, с которого вы берёте задаток, — это решение владельца, а не системы. Система только следит, чтобы правило было одинаковым для каждого бронирования такого типа.
Когда это не имеет смысла: небольшие заведения и бронирования на ходу
Цепочка подтверждений имеет смысл там, где бронирования поступают одновременно из нескольких каналов и никто не успевает вручную звонить каждому гостю. В бистро на восемь столиков, где владелец знает гостей по имени, дополнительная система часто не нужна — телефона и памяти достаточно, а автоматизация только добавляет ещё один инструмент, который надо поддерживать. При этом мы не обещаем, что сам SMS уменьшит количество пустых столиков — это зависит также от того, кто вообще реагирует на отсутствие ответа гостя.
Бронирования, сделанные на ходу, на те же полчаса, тоже не нуждаются в цепочке. Тогда важна доступность столика в данный момент, а не подтверждение заранее. Более широкий обзор того, что в ресторанном бизнесе стоит автоматизировать, а что лучше оставить людям, мы описываем в тексте об автоматизации ресторанов.
Цепочка подтверждений также не исправит неправильно подобранный столик или гостя, который заявляет шесть человек, а приходит вдесятером. Она не заменит разговор в особых случаях — первого причастия или банкета — где меню и зал требуют согласований, а не автоматического напоминания.
Часто задаваемые вопросы
Решает ли предоплата проблему no-show?
Не полностью. Задаток ограничивает количество бронирований, брошенных без предупреждения, потому что гость теряет деньги, но не меняет ситуацию, когда кто-то действительно не может прийти и не сообщает об этом. Поэтому предоплату мы сочетаем с SMS-напоминанием, а не рассматриваем как единственную защиту.
Сколько стоит внедрение цепочки подтверждений?
Зависит от того, сколько звеньев этой цепочки нужно замкнуть: сама рассылка сообщений — одно, график, который сам блокирует даты, — другое. Объём определяем после разговора о том, что именно должен делать ваш процесс подтверждений.
Достаточно ли SMS или нужно звонить?
SMS решает обычное бронирование, но не каждую ситуацию. Телефон остаётся как последний шаг перед освобождением столика, для гостей, которые не ответили на два предыдущих сообщения. Разговор также даёт шанс услышать напрямую, что гость всё-таки не придёт, вместо того чтобы гадать.
Что происходит с номером телефона гостя после бронирования?
Он попадает в CRM и подпадает под RODO как любые другие персональные данные клиента. О том, где мы физически храним такие данные и как долго, пишем в тексте о RODO в автоматизации.
Имеет ли это смысл для небольшого ресторана с несколькими столиками?
Обычно не сразу. При нескольких столиках и постоянных гостях менеджер зала часто помнит бронирования без поддержки системы. Цепочка подтверждений начинает окупаться, когда бронирования поступают одновременно из нескольких каналов и никто не успевает обзванивать всех вручную.
Давайте обсудим цепочку подтверждений для вашего ресторана в Варшаве.