CRM для ресторана и кафе: что нужно и чем она отличается от кассы

CRM для ресторана — это не замена кассовой программы, а отдельный слой про гостей: кто приходил, что заказывал, кто забронировал стол, кому не перезвонили по банкету. Кассовая система (iiko, r_keeper, Poster и подобные) отвечает за заказ, чек и склад. Если у вас одно кафе, кассовая программа ведёт гостей и в ней есть простая лояльность, отдельная CRM может и не понадобиться. Она нужна, когда заявки приходят из нескольких каналов, а выручку приносят банкеты и повторные гости.

Что делает касса, а что — CRM

Путаница начинается там, где обе системы умеют «карточку гостя». Разница в источнике правды: касса знает про чек, CRM знает про отношения с человеком до и после чека.

Один день ресторана: где теряются деньги

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

1. Утро. Менеджер перебирает брони: часть в мессенджере, часть в тетради у хостес, часть пришла звонком. Две брони на один стол — стандартная потеря репутации.
2. День. Звонит человек насчёт банкета на 30 человек. Ему обещают «перезвонить с меню». Если перезвонить забыли, это самая дорогая потеря дня: один банкет может принести столько же, сколько целый вечер обычных заказов.
3. Вечер. Зал полный, гость не пришёл по брони и не предупредил. Без предоплаты или напоминания за три часа стол простаивает.
4. Ночь. Гость остался довольным, но контакт нигде не записан. Через месяц вы тратите деньги на рекламу, чтобы вернуть того, кого уже привели.

Эти четыре потери закрывает CRM: единая лента заявок, статусы броней и банкетов, напоминания и база гостей. Остальное — украшения.

Модули, которые окупаются первыми

Брони и банкеты

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

База гостей и согласия

Карточка гостя хранит телефон, дни рождения, аллергии, любимый стол, историю визитов. Это персональные данные, поэтому нужны согласие на обработку по 152-ФЗ и отдельное согласие на рассылки. Как собирать и хранить согласия, разобрано в материале про защиту CRM от утечки клиентской базы.

Доставка и сайт

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

Лояльность и обратная связь

Бонусы, купон на день рождения, просьба оставить отзыв после визита — это то, что обычно подключают во вторую очередь. Хорошая связка: чек из кассы приходит в CRM, система через несколько часов отправляет вопрос о визите, а плохую оценку сразу передаёт менеджеру.

Когда CRM не нужна

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

Готовая CRM или своя

Готовые решения быстро запускаются и стоят подпиской. Свои делают, когда нужна нестандартная логика: банкеты с разными схемами предоплаты, несколько юрлиц и точек, глубокая связь с кассой. Общий разбор критериев — в статье как выбрать CRM для малого бизнеса и «своя CRM или готовая». Если нужна система под вашу специфику, смотрите CRM для ресторана.

Чек-лист выбора

1. Выпишите, какими каналами приходят брони, банкеты и заказы. Всё, что не попадает в систему, считайте потерей.
2. Проверьте, как CRM получает данные кассы: через API, выгрузку или вручную. Ручной ввод умрёт через месяц.
3. Убедитесь, что есть статусы брони и напоминание гостю без участия хостес.
4. Спросите, где хранятся данные и можно ли выгрузить базу при смене системы.
5. Протестируйте на одной неделе на реальных бронях, а не по презентации.
6. Назначьте владельца данных: кто чистит дубли и отвечает за заполненность карточек.