CRM для пиццерии: экономим 15 часов в неделю

Каждый вечер администратор Игоря открывал Excel, копировал номера телефонов и вручную рассылал сообщения. Два с половиной часа. Каждый день. В трёх точках.

При этом гости приходили второй раз, третий — и пропадали. Без объяснений, без прощания. Просто переставали появляться. Игорь знал, что пицца хорошая, персонал нормальный, цены честные. Но удержать людей не получалось — потому что не было никакой системы. Только бумажные карточки, WhatsApp-рассылки наугад и ощущение, что 280 тысяч рублей каждый месяц просто утекают сквозь пальцы.

Мы попробовали три разных подхода, чтобы это исправить. Результаты оказались неожиданными — и не там, где мы ждали.

Контекст клиента

Игорь - шеф-повар и совладелец сети пиццерий в Екатеринбурге. Три точки по 35-40 посадочных мест, общий оборот около 18 млн ₽ в месяц - примерно по 6 млн на каждую локацию. Формат - семейные пиццерии со средним чеком около 900 ₽, куда приходят постоянные гости района и офисные работники в обед.

Когда мы начали работать с Игорем, из программного обеспечения у него был ровно один инструмент: iiko на кассе. Всё остальное делалось руками. Программа лояльности существовала в виде бумажных карточек, которые гости постоянно теряли. Акции и напоминания рассылались через WhatsApp: администратор открывал список контактов, копировал текст и отправлял по одному. Три точки - три администратора, и каждый делал это немного по-своему.

Что у них болело (в цифрах)

Когда мы пришли на первичный аудит, картина оказалась вполне предсказуемой для сети общепита без нормальной автоматизации коммуникаций:

• Retention за 30 дней - 28%. Меньше трети гостей возвращались в течение месяца. Игорь это чувствовал интуитивно, но реальную цифру увидел только когда мы выгрузили данные из iiko.
• Возвраты в течение 14 дней после первого визита - 12%. Почти девять из десяти новых гостей уходили и в ближайшие две недели не появлялись.
• Средний чек - 890 ₽ - и так месяц за месяцем, без какой-либо динамики.
• Выручка в час - в среднем 2 250 ₽, с колебаниями от 2 100 до 2 400 ₽ в зависимости от дня недели. Никакого управления загрузкой не было и в помине.
• Оборачиваемость столов в обед - 2,1x.
• Ручная работа администраторов - 2,5 часа в день на каждой точке. Три точки, 20 рабочих дней - итого 150 часов в месяц на WhatsApp-рассылки и возню с бумажными карточками.

По нашей оценке, 15-20% потенциальных постоянных гостей уходили к конкурентам просто потому, что о них забывали. На трёх локациях это выливалось примерно в 280 тыс ₽ упущенной выручки ежемесячно. Как сказал Игорь: «Главным было не то, что гости уходят - главным было то, что мы даже не знали, кто именно ушёл и почему».

Что мы предложили - наш стек

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

Вариант 1: SMS-автоматизация через внешний сервис рассылок

Классика для программ лояльности в HoReCa. Подключаешь кассовую систему к SMS-шлюзу, настраиваешь триггеры - и гости получают сообщения. Плюсы очевидны: SMS читают почти все, не нужно никаких приложений. Но для Игоря минусы оказались критичными. При базе в несколько тысяч контактов и частоте 2-3 сообщения в месяц юнит-экономика становилась сомнительной. К тому же SMS - канал односторонний: гость не может нажать кнопку, выбрать оффер, ответить. Для персональных рекомендаций это тупик.

Вариант 2: готовая CRM-платформа для ресторанов со встроенной лояльностью

На рынке есть специализированные решения с модулями лояльности, push-уведомлениями и аналитикой. Мы смотрели на несколько таких продуктов. Проблема одна: все они рассчитаны на то, что гость скачает мобильное приложение. А конверсия в установку у аудитории районных пиццерий - низкая. Добавьте к этому ежемесячную подписку на три точки плюс стоимость интеграции с уже работающим iiko - и получится долго, дорого и с главным риском: гости просто не поставят приложение.

Вариант 3: iiko + Telegram Bot + собственная триггерная логика (наш выбор)

Telegram в Екатеринбурге - основной мессенджер целевой аудитории пиццерий Игоря. Бот не требует отдельного приложения. Канал двусторонний: гость может нажать кнопку, выбрать блюдо, подтвердить бронь. Для программы лояльности это принципиально - мы получаем не просто уведомление, а интерактивный оффер, на который можно отреагировать прямо здесь и сейчас.

iiko, которым Игорь уже пользовался, хранит всю историю заказов: какие позиции брал гость, как часто приходил, на какую сумму. Мы решили использовать эти данные как основу для персональных рекомендаций. Никакой новой системы учёта - только надстройка над тем, что и так работает на кухне.

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

Как мы это внедряли (шаги по неделям)

День 1-3: аудит данных и архитектура

Начали с выгрузки истории заказов из iiko за последние 6 месяцев по всем трём точкам. Нужно было понять, что реально есть по гостям: телефоны, частота визитов, любимые позиции. Выяснилось, что около 60% гостей оставляли номер при оформлении карты лояльности - уже неплохая база для старта.

Параллельно проектировали архитектуру. Polling-сервис каждые 30 секунд опрашивает iiko на предмет новых заказов и событий, передаёт данные в event processor, тот пишет в CRM-базу на PostgreSQL и отправляет в триггерный движок. Триггерный движок решает, нужно ли отправить сообщение через Telegram Bot API.

Важный момент, который мы учли сразу: в iiko нет нативных вебхуков - только polling. Это значило, что нужен надёжный сервис с обработкой ошибок и автообновлением сессионного токена. Токен живёт 15 минут, и если его не обновлять вовремя, интеграция молча падает.

День 4-7: настройка бота и базовые триггеры

Развернули Telegram-бота, настроили inline-клавиатуры для интерактивных офферов. Гость получает сообщение с кнопками «Хочу попробовать» / «Не сейчас» - и мы видим реакцию. Это важно для дальнейшей персонализации.

Запустили три базовых триггера: приветственное сообщение после первого визита с оффером на второй, реактивационное - при паузе больше 21 дня, поздравление с днём рождения (данные брали из карты лояльности iiko).

К этому моменту к работе подключился управляющий каждой из точек - нужно было согласовать тексты и офферы. Формулировки Игорь правил сам: «Мы хотели, чтобы бот звучал как мы, а не как робот».

День 8-14: персональные рекомендации

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

Настроили лимиты: не больше одного сообщения в неделю на гостя. Это решение приняли вместе с Игорем после тестовой рассылки на 200 контактов - при более высокой частоте часть людей сразу отписывалась.

День 15-21: тест, правки, запуск на все три точки

Первую неделю работали только на одной точке - смотрели на отписки, конверсию кнопок, нагрузку на бота. После правок развернули на все три локации. Администраторам показали дашборд: кому отправлено, кто отреагировал, кто пришёл после сообщения.

Что получили в цифрах

За 4 месяца прирост выручки составил +520 тыс ₽ в месяц. Не «было 18 млн - стало 25 млн», а вполне конкретная прибавка от канала коммуникации с гостями, который раньше попросту не существовал.

Коротко по трём вариантам, которые мы рассматривали:

• SMS-автоматизация дала бы рост retention, но без интерактива и с ощутимой стоимостью на масштабе. Персональные рекомендации через SMS технически реализуемы, но для гостя это неудобно.
• Готовая CRM-платформа закрыла бы аналитику, но уткнулась бы в низкую установку приложения. Для районных пиццерий это реальный барьер - не абстрактный.
• iiko + Telegram Bot + триггерная логика - дала полный контроль над сценариями, нулевой порог входа для гостя (Telegram уже стоит) и масштабируемость на три точки без роста операционных затрат.

Что бы мы сделали иначе

1. Раньше договориться о частоте сообщений. Мы стартовали с двух сообщений в неделю и за первые три дня получили волну отписок. Пришлось откатиться до одного сообщения и заново согласовывать всё с Игорем. Потеряли около 8% базы, которую вполне можно было сохранить. Теперь мы всегда начинаем с консервативной частоты и наращиваем постепенно.

2. Подключить аналитику атрибуции с самого начала. Первые две недели мы не могли точно сказать, пришёл ли гость после сообщения или сам по себе. Связку «сообщение - визит» настроили только на третьей неделе, сопоставив время отправки и время визита. Это стоило нам части данных для первичного отчёта.

3. Обучить администраторов работе с дашбордом до запуска, а не после. На двух из трёх точек администраторы первую неделю в дашборд вообще не заходили - не понимали зачем. Достаточно было короткой инструкции и живой демонстрации заранее.

Можем повторить у вас

Эта схема подходит для сетевых заведений от 2 точек, которые уже работают на iiko или похожих POS-системах и хотят перестать терять гостей после первого-второго визита.

Что нужно с вашей стороны: действующий iiko с историей заказов за 3+ месяца, база гостей с телефонами (хот

Что делать прямо сейчас

Если вы дочитали до этого места и узнали в описании свою ситуацию — вот четыре конкретных шага, которые можно сделать сегодня:

1. Выгрузите из iiko отчёт по возвратности за последние 90 дней. Посмотрите, какой процент гостей вернулся хотя бы дважды. Если цифра ниже 30% — у вас есть прямая точка роста без привлечения новой аудитории.
2. Посчитайте, сколько гостей было один раз и больше не вернулось. Умножьте на средний чек. Это деньги, которые уже лежат в вашей базе — просто никто за ними не пришёл.
3. Проверьте, есть ли у вас телефоны хотя бы 60% гостей. Если да — база готова к работе. Если нет — начните собирать через бонусную механику прямо сейчас, это займёт 2-3 недели.
4. Решите, кто на вашей стороне будет отвечать за коммуникацию с гостями. Не обязательно отдельный человек — достаточно администратора с понятной инструкцией.

Когда зовут нас

FlowFrame занимается именно такими проектами — когда база есть, POS работает, но между гостем и рестораном нет нормального диалога. Мы не продаём коробочные решения, каждый раз разбираем конкретную ситуацию.

Если хотите понять, что реально применимо у вас — поговорите с нашим AI-ботом на сайте, он задаст несколько вопросов и поможет сориентироваться ещё до живого звонка.