Как учитывать неявки и освобождать столы в ресторане

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

Что подготовить

• Единые определения для подтвержденной брони, отмены гостем, отмены рестораном, опоздания, визита и неявки.
• Причины отмены, которые сотрудники выбирают или фиксируют по принятому в заведении правилу.
• Ответственного за обработку новых броней, изменений и конечного статуса визита.
• Срок, в который хостес или администратор должен закрыть бронь после времени визита.
• Перечень систем, между которыми передаются данные о брони, столе и статусе, если используется CRM, сервис бронирования или интеграция с iiko.

Разделите отмену, опоздание и неявку

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

В Яндекс Бронированиях предусмотрены статусы резервов, включая подтверждение, ожидание, опоздание, визит, отмену и другие состояния. В правилах расчетов сервиса отдельно упоминаются конечные статусы «Гость ушёл», «Не пришёл» и «Отмена рестораном». Это относится к конкретному сервису: набор статусов и автоматическая обработка незакрытых броней в другой системе необходимо проверять по ее документации и настройкам.

Проверьте, как закрываются незавершенные брони

Не стоит рассчитывать неявки как все записи без отметки «Пришел». В правилах Яндекс Бронирований указано, что если ресторан не проставит конечный статус вручную, сервис через 23 часа после начала брони засчитывает ее как подтвержденную, а через 24 часа автоматически закрывает с отметкой о визите. Значит, для этого сценария отсутствие ручного закрытия может исказить показатель неявок.

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

Тестируйте подтверждение и освобождение слота

Подтверждение брони и напоминания могут быть частью рабочего процесса, но не гарантируют сокращения неявок. Яндекс сообщает о push-уведомлениях и СМС-напоминаниях о визите, а в СмартРезерве доступны ручное и автоматическое подтверждение онлайн-брони. Для автоматического подтверждения есть ограничение: оно срабатывает, когда всех гостей можно посадить за один стол. Условия, каналы, время отправки и доступность таких функций нужно проверять в конкретном сервисе.

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

Что проверить в интеграции

• Какая система является источником статуса брони и кто может его изменить.
• Передаются ли в другую систему отмена, причина отмены, опоздание, неявка и факт визита.
• С какой задержкой обновляется занятость стола и есть ли защита от пересекающихся броней.
• Как обрабатываются сбой связи, повторная отправка события и ручная корректировка сотрудником.
• Какие версии, лицензии, права доступа и методы обмена требуются для выбранной связки сервисов.

Типичные ошибки и ограничения

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

С чего начать

• Утвердите рабочее определение неявки и список конечных статусов.
• Назначьте сотрудника и срок закрытия каждой завершенной брони.
• Проведите выборочную сверку незакрытых записей за одну-две смены.
• Опишите сценарии отмены, опоздания и освобождения стола.
• Протестируйте их в используемом сервисе и в связанных системах до автоматизации обмена.