Управление сетью ресторанов: три заведения, один экран и общие цифры для владельца

Проблема начинается при сравнении, а не на кухне

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

Масштаб этого виден уже на уровне одного ресторана, прежде чем дело доходит до сети. Среди 245 ресторанов и кейтеринговых компаний в Варшаве, чьи сайты открылись и были автоматически проанализированы, 112 не имеют ни формы запроса, ни формы записи. Это 45,7% этой группы. Запрос от гостя тогда нигде не записывается, поэтому не с чем сравнивать между заведениями.

Как цифры из заведения попадают на экран владельца

Запрос с телефона, с визитки в Google, из Messenger или из WhatsApp попадает в одно место, а не в блокнот одного менеджера. Каждое заведение логирует событие одним и тем же способом, поэтому менеджер уже не решает сам, что считается бронированием. Административная панель показывает все три точки рядом друг с другом, на одном экране, с теми же столбцами. Весь механизм основан на общей системе CRM для всех заведений — без нее каждая точка возвращается к собственному формату.

Эта унификация основана на нашей практике внедрений, а не на исследовании рынка общепита. Если через месяц менеджеры все еще присылают цифры в старых форматах, унификация не сработала и нужно вернуться к определению событий, а не добавлять еще один отчет. Показатель, за которым нужно следить, - это количество запросов, которые не попали в общий CRM, а остались в телефоне или в Messenger менеджера.

Кто это ведет ежедневно: роли, инструменты и ответственность за цифры

Сеть нуждается в четком разделении, кто за что отвечает. Иначе экран с цифрами никому не поможет. Менеджер зала в каждой точке отвечает за то, чтобы один и тот же процесс регистрации событий работал одинаково. Закупщик заказывает товары у поставщика через тот же CRM, поэтому снабжение трех точек видно рядом, а не в трех отдельных сообщениях. Бухгалтер рассчитывает выручку дня на основе тех же отчетов, а не на основе того, что пришлет ему менеджер по почте. Владелец смотрит на панель раз в день и принимает решение на основе фактов, а не памяти одного из менеджеров.

На практике эти потоки соединяет автоматизация. n8n или Make принимает запрос с визитки Google Business Profile, из Messenger или из WhatsApp, и вносит его в CRM с меткой заведения. SMSAPI отправляет гостю подтверждение бронирования, а Google Calendar хранит даты банкетных залов, чтобы два заведения не забронировали один и тот же зал на свадьбу в один день. Больше об этом механизме в одной точке вы найдете в отдельном тексте о бронированиях, поставщиках и отзывах в одном ресторане. За соединение этих источников отвечают интеграции, которые соединяют кассу, календарь и мессенджеры.

Интеграция иногда ломается, чаще всего после смены пароля или после обновления API платформы. Запросы тогда не исчезают, а возвращаются в старый режим и лежат в почтовом ящике менеджера, пока кто-то их не заметит. Администратор панели получает уведомление об ошибке, и именно он, а не менеджер зала, исправляет соединение.

Та же проблема видна еще до того, как сеть начнет расти. Среди 359 ресторанов и кейтеринговых компаний в Варшаве, чьи сайты мы проанализировали автоматически, 66 видны исключительно на чужой платформе. Это 18,4% этой группы. Такая платформа - это каталог, портал бронирования или профиль в социальных сетях. У такого заведения нет собственного места, где гость мог бы оставить запрос, поэтому нечего вносить в общий CRM сети.

Сколько стоит общий экран для нескольких заведений: от чего зависит стоимость

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

Интеграция с e-mail открывает первый канал, интеграция с Telegram или WhatsApp — второй: каждый канал отдаёт данные по-своему, поэтому каждый это отдельный кусок работы. CRM-автоматизации соединяют эти источники в один поток, и только тогда панель показывает всю сеть, а не её кусок. Объём определяем после разговора о том, чем сегодня пользуется ваша сеть.

При этом мы не обещаем конкретное количество запросов или конкретный рост загрузки. Честно этого никто не гарантирует. Окупаемость зависит от того, сколько запросов сеть теряет сегодня, а это видно только после подключения общего CRM.

Когда общий экран для нескольких заведений - это плохая идея

Общий экран не имеет смысла для одного заведения, которое владелец видит каждый день своими глазами. Там проблема сравнения просто не существует, потому что не с чем сравнивать. Не стоит также внедрять его в сети, которая только тестирует вторую точку и через полгода может ее закрыть. Стоимость поддержки интеграции тогда превысит выгоду от одного отчета. Иногда у заведений совершенно разные меню, разные гости и разная бизнес-модель - одно это столовая для сотрудников, другое ресторан à la carte. Тогда общие цифры все равно не скажут ничего осмысленного без отдельного анализа для каждой точки.

Мы также не обещаем, что сам экран улучшит отношения между заведениями. Это все еще зависит от того, хотят ли менеджеры использовать один источник правды, а не от самого инструмента. AI-отчеты помогают читать цифры, но решение все равно принимает владелец.

Часто задаваемые вопросы

Нужно ли каждому заведению иметь отдельный CRM, или достаточно одного общего?

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

Что если у заведений разные владельцы, например, по модели франшизы?

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

Сколько длится внедрение общей панели для двух или трех заведений?

Время зависит от того, сколько систем нужно соединить - касса, бронирования, визитка Google. Это слишком индивидуально, чтобы указать одно число недель без знания сети. Вместо срока мы указываем порядок работ: сначала интеграция источников, потом панель, в конце первые отчеты — именно в таком порядке, потому что отчёт считает только то, что предыдущие звенья успели записать. Реальный график устанавливается только после просмотра того, что использует каждое заведение сегодня.

Нужно ли менять систему POS в каждом заведении, чтобы это работало?

Нет, интеграция обычно соединяется с тем, что уже стоит на кассе, вместо того чтобы ее менять. Исключение - касса, у которой нет никакого API и физически из нее ничего нельзя вытащить. Тогда нужно отдельно оценивать, окупится ли замена. Мы не обещаем, что каждую кассу можно подключить без изменений. Это зависит от конкретного производителя.

Давайте обсудим один экран для вашей сети ресторанов в Варшаве.