No-show у ресторані: ланцюжок підтверджень, який захищає столик у п'ятницю ввечері

Неотримане бронювання - це зазвичай втрачений вечір, а не поганий гість

Бронювання на шість осіб у п'ятницю ввечері для менеджера зали - це обіцянка. Офіціанти готують столик, кухня рахує порції. Біля дверей чекає черга пар без бронювання. Гість, який не прийшов і не зв'язався, забирає цей вечір назавжди. Зазвичай винен не гість, а відсутність процесу підтвердження бронювання. Хороший процес підтверджує присутність гостя, перш ніж столик зникне з графіка.

Перш ніж взагалі дійде до підтвердження, у багатьох закладів немає місця, де бронювання може бути записано.

Запит про столик тоді нікуди не потрапляє, крім пам'яті людини, яка прийняла дзвінок.

Як виглядає ланцюжок підтверджень: бронювання → SMS → телефон → звільнення столика

Перший SMS система надсилає автоматично, одразу після запису бронювання в системі бронювання. Друге повідомлення, за день до візиту, нагадує про час і кількість осіб. Якщо гість не відповість до встановленого часу, менеджер зали або рецепціоністка телефонує. Лише відсутність відповіді на третій контакт дає підставу, щоб звільнити столик для когось іншого.

Кількість кроків та інтервали між ними - це налаштування, які потрібно узгодити із закладом, а не результат вимірювання - у нас немає дослідження, яке б вказало тут одне правильне число. Якщо через місяць бронювання все ще чекають без відповіді до останнього моменту, ланцюжок не працює. Тоді треба перевірити інтеграцію автоматичних повідомлень з CRM, а не додавати ще один SMS. Показником, за яким варто стежити з першого тижня, є кількість бронювань без відповіді до початку обслуговування.

Тут регулярно щось ламається: офіціант вручну звільняє столик у книзі бронювань, але ніхто не оновлює CRM. Система тоді надсилає SMS гостю, бронювання якого вже не існує, а новий гість отримує подвійно зарезервований столик. Помилку видно зі скарг при вході, не в звіті - тому менеджер зали повинен раз на день перевіряти журнал змін у CRM, а не лише паперовий графік.

Хто стежить за тим, чи ланцюжок взагалі працює? На практиці це робить менеджер зали, бо має доступ до CRM і бачить графік у реальному часі. Власник отримує з цього звіт - не щоденний, лише підсумок тижня - і на цій основі приймає рішення, чи потрібно змінити поріг передоплати.

Хто і чим стежить за бронюванням: ролі та інструменти

За процес відповідає зазвичай менеджер зали, а не власник особисто. Власник встановлює правило, менеджер виконує його щодня на основі даних з CRM, а не пам'яті зміни. Повідомлення з підтвердженням надсилає CRM, поєднаний з SMSAPI або з WhatsApp Business, залежно від того, чим користуються ваші гості. Сценарій, який поєднує бронювання з відправкою, зазвичай створюється в n8n - це інструмент, який дозволяє поєднати систему бронювання з календарем зали без написання інтеграції з нуля. Завдаток, якщо заклад його стягує, проходить через BLIK або Przelewy24, а підтвердження платежу само закриває бронювання в системі.

Це може бути каталог, портал бронювання або профіль у соціальних мережах, без власного сайту для запису бронювання. Номер телефону гостя, який потрапляє до CRM, - це персональні дані - їхнє зберігання підлягає RODO, а про те, де фізично опиняються такі дані, пишемо окремо.

Скільки коштує впровадження ланцюжка підтверджень

Автоматичні повідомлення, тобто SMS і WhatsApp, що надсилаються без участі рецепції, стережуть бронь, яка вже є. Система бронювання, яка бачить весь графік столиків і сама блокує терміни, стежить, щоб ця бронь узагалі з'явилася правильно. Інтеграція з Telegram або WhatsApp відкриває канал, яким гість справді відповідає. Це три ланки одного ланцюга підтверджень, а обсяг визначаємо після розмови про те, як він сьогодні у вас влаштований.

Підсумовувати тут нічого. Модуль повідомлень і модуль бронювання стережуть два різні моменти одного візиту, а черговість залежить від того, де сьогодні втрачається більше столиків: на записі чи на нагадуванні.

Передоплата як межа: коли просити завдаток

Передоплата не усуває no-show, але визначає межу ризику. Бронювання без завдатку - це декларація. Бронювання із завдатком - це рішення, за яке гість вже заплатив. Для столика на двох завдаток зазвичай не має сенсу - вартість обслуговування платежу перевищує ризик. Для групового бронювання, першого причастя або святкового заходу зі встановленим меню на особу, завдаток захищає кухню від закупівлі продуктів під гостя, який не з'явиться.

Поріг, з якого ви стягуєте завдаток, - це рішення власника, не системи. Система лише стежить, щоб правило було однаковим для кожного бронювання цього типу.

Коли це не має сенсу: невеликі заклади та бронювання на ходу

Ланцюжок підтверджень має сенс там, де бронювання надходять з кількох каналів одночасно і ніхто не має часу вручну дзвонити кожному гостю. У бістро на вісім столиків, де власник знає гостей на ім'я, додаткова система часто непотрібна - телефона й пам'яті вистачить, а автоматизація лише додає ще один інструмент, який треба підтримувати. При цьому ми не обіцяємо, що сам SMS зменшить кількість порожніх столиків - це залежить також від того, чи хтось взагалі реагує на відсутність відповіді гостя.

Бронювання, зроблені на ходу, на ті самі півгодини, теж не потребують ланцюжка. Тоді важлива доступність столика в даний момент, а не підтвердження заздалегідь. Ширший огляд того, що в гастрономії варто автоматизувати, а що краще залишити людям, описуємо в тексті про автоматизацію ресторанів.

Ланцюжок підтверджень також не виправить неправильно підібраний столик або гостя, який заявляє шість осіб, а приходить удесятьох. Не замінить розмову при особливих нагодах - першому причасті чи банкеті - де меню і зала вимагають домовленостей, а не автоматичного нагадування.

Найчастіші питання

Чи передоплата вирішує проблему no-show?

Не повністю. Завдаток обмежує кількість покинутих бронювань без слова, бо гість втрачає гроші, але не змінює ситуацію, коли хтось справді не може прийти і про це не повідомляє. Тому передоплату ми поєднуємо з SMS-нагадуванням, а не розглядаємо як єдиний захист.

Скільки коштує впровадження ланцюжка підтверджень?

Залежить від того, скільки ланок цього ланцюга треба замкнути: сама розсилка повідомлень - одне, графік, який сам блокує терміни, - інше. Обсяг визначаємо після розмови про те, що саме має робити ваш процес підтверджень.

Чи SMS достатньо, чи треба дзвонити?

SMS вирішує звичайне бронювання, але не кожну ситуацію. Телефон залишається як останній крок перед звільненням столика, для гостей, які не відповіли на два попередні повідомлення. Розмова також дає шанс почути напряму, що гість все ж не прийде, замість здогадуватися.

Що відбувається з номером телефону гостя після бронювання?

Він потрапляє до CRM і підлягає RODO, як і будь-які інші персональні дані клієнта. Про те, де фізично ми зберігаємо такі дані і як довго, пишемо в тексті про RODO в автоматизації.

Чи це має сенс для невеликого ресторану з кількома столиками?

Зазвичай не відразу. При кількох столиках і постійних гостях менеджер зали часто пам'ятає бронювання без підтримки системи. Ланцюжок підтверджень починає окупатися, коли бронювання надходять з кількох каналів одночасно і ніхто не встигає вручну.

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