Антон Дегтярёвбитрикс24 для horeca: рестораны, доставка, кухни
В HORECA CRM обычно внедряют неправильно: пытаются посадить официанта в интерфейс с двадцатью полями и получают саботаж за неделю. На моих проектах в ресторанном сегменте рабочая схема — три экрана максимум для персонала, и вся сложность прячется в автоматизацию, которую никто руками не трогает.
что делает битрикс24 в ресторане, а что нет
Битрикс24 — не касса и не система учёта кухни. Он не считает себестоимость блюда, не ведёт складские остатки продуктов и не печатает чеки. Для этого у вас уже стоит касса и, скорее всего, r-keeper, iiko или похожая система — трогать её не нужно, и я не предлагаю клиентам замену.
Зона CRM в HORECA — всё, что связано с гостем и заказом до момента, пока блюдо не начали готовить: приём заявки, бронь стола, банкет, повторный контакт после визита. По сути Битрикс24 берёт на себя работу с клиентом снаружи кухни, а всё, что происходит на кухне и на кассе, остаётся в специализированном ПО.
Разделение звучит очевидно, но в 7 из 10 случаев на аудите вижу попытку затащить в CRM учёт продуктов или расчёт стоимости порции — это лишняя работа, которая ломается при первом обновлении меню.
три воронки: доставка, бронь стола, банкет
Для ресторана с доставкой нужна отдельная воронка «Заказ на доставку»: новый заказ → подтверждён → готовится → курьер выехал → доставлен → оплачен. Каждый статус меняет кухня или диспетчер одним кликом с телефона, без лишних полей.
Бронь стола — вторая воронка, короче: заявка → подтверждена → гость пришёл / гость не пришёл. Ключевое поле здесь — дата и время, а не сумма чека, поэтому карточка сделки для брони намеренно урезана до пяти полей.
Банкеты и корпоративы — третья воронка, и она самая длинная: запрос → расчёт меню → согласование бюджета → предоплата → мероприятие → закрывающие документы. На банкетах решение принимается не за один звонок, а за несколько итераций с клиентом, поэтому здесь нужны задачи с дедлайнами и напоминаниями, а не автоматика.
заказы из разных каналов в одну точку
Типичная картина в ресторане без CRM: заказы идут с сайта, из инстаграма, по телефону, через агрегаторы доставки — и половина из них теряется, потому что администратор физически не успевает всё записать. На моих внедрениях первая задача — свести все каналы в одну очередь заявок в Битрикс24.
Открытые линии подключают сайт, мессенджеры и соцсети напрямую — сообщение из любого канала создаёт сделку в нужной воронке автоматически, без ручного переноса. Телефонные звонки идут через интеграцию с АТС: пропущенный звонок сразу становится задачей «перезвонить», а не повисает в блокноте администратора.
С агрегаторами доставки типовой интеграции через Битрикс24 нет — их API закрытые и разные у каждого сервиса, поэтому туда обычно подключают отдельный сервис-коннектор или обрабатывают заказы вручную в личном кабинете агрегатора, а в CRM попадают уже как факт продажи для аналитики и повторного контакта.
чат-бот на приёме заказа
Ночью и в пиковые часы администратор физически не успевает отвечать всем одновременно. Рабочее решение — бот первой линии в открытой линии: уточняет тип обращения (заказ, бронь, вопрос по меню), для простого заказа доставки может сразу собрать состав и адрес, а дальше передаёт диалог живому оператору без потери контекста.
Важный нюанс: бот не должен пытаться закрыть весь диалог сам — в ресторанном бизнесе гость часто хочет уточнить состав блюда или заменить ингредиент, и это живой разговор, а не сценарий с кнопками. Задача бота — не потерять заявку в ночное время и отсеять типовые вопросы («работаете ли сегодня», «какой адрес»), а не заменить администратора.
На проектах, где я ставил такую схему, доля заявок, зафиксированных в CRM в первые пять минут после обращения, выросла с 40–50% до 90%+ — раньше эти сообщения администратор видел с задержкой в переписке и часть теряла актуальность (гость уже заказал у конкурента).
карточка гостя и повторные заказы
Ресторан живёт повторными визитами сильнее, чем разовыми продажами: средний чек редко растёт быстро, а вот частота визитов — управляемая метрика. В карточке контакта фиксирую предпочтения (аллергии, любимые блюда, средний чек), дату последнего визита и канал первого обращения.
Автоматический сценарий: если гость не появлялся 30–45 дней (порог зависит от формата — для доставки короче, для ресторана с полным циклом длиннее), система ставит задачу на персонализированное предложение — не массовую рассылку всем подряд, а обращение с учётом истории. Подробный разбор механики повторных продаж — в отдельной статье, принципы там применимы и к HORECA почти без изменений.
Программу лояльности (баллы, кэшбэк) обычно ведёт отдельный сервис или модуль кассы — CRM здесь только видит статус клиента (новый / постоянный / VIP) и использует его как фильтр для сегментации, не дублируя расчёт баллов.
работа с жалобами и рекламациями
Жалоба на качество блюда или опоздание доставки — момент, где теряют клиента навсегда, если реакция затягивается. Отдельная воронка «Рекламации» с коротким SLA — не больше двух часов до первого ответа — и обязательным полем «что предложили взамен» (замена блюда, скидка на следующий заказ, возврат).
Ошибка, которую вижу часто: жалобы падают вперемешку с обычными заказами в общую воронку, и администратор физически не видит их среди типовых статусов. Разделение потоков — простое решение, которое ничего не стоит в настройке, но снимает риск, что критичное обращение потеряется среди тридцати обычных.
мобильный доступ для смены персонала
В HORECA высокая текучка, и обучать нового администратора сложному интерфейсу за один день нереально. Мобильное приложение Битрикс24 с урезанной до трёх статусов воронкой — рабочий вариант: новый сотрудник разбирается за 15–20 минут, а не за неделю.
Для мобильных сценариев критичны права доступа: официант или курьер должен видеть только свои заказы и адрес доставки, но не общую выручку или контакты всех гостей. Настраивается через роли на уровне полей и воронок, а не отдельным приложением — до внедрения стоит явно проговорить с владельцем, кто и что видит.
аналитика, которая реально нужна владельцу
Из всей стандартной аналитики Битрикс24 владельцу ресторана обычно важны три вещи: доля повторных гостей от общего потока, средний срок между визитами и конверсия из заявки на бронь в подтверждённую бронь. Остальные отчёты (воронка по менеджерам, план продаж) — из B2B-логики, которая здесь почти не применима, потому что решение о заказе гость принимает сам за минуты, а не менеджер за недели переговоров.
Отдельно смотрю на распределение заказов по каналам — сайт, соцсети, телефон, агрегаторы: это прямой аргумент для маркетингового бюджета на следующий квартал, а не абстрактная цифра для отчёта.
своя доставка или курьерская служба
Часть ресторанов с доставкой держат собственных курьеров, а не отдают всё агрегаторам — это дешевле на объёме, но добавляет заботу: нужно видеть, кто из курьеров свободен, сколько заказов у него в очереди и сколько по факту занимает маршрут. Логика здесь близка к обычной курьерской логистике, и я обычно переношу в ресторанный проект те же принципы, что и для служб доставки — воронку по статусам заказа, привязку курьера к заказу, расчёт нагрузки по сменам. Подробный разбор настройки для логистических и доставочных компаний — в отдельной статье, механика воронок там применима почти без изменений.
Разница с классической логистикой в одном: в ресторане критично время «от готовности блюда до выезда курьера», а не только «от выезда до доставки». Поэтому в карточке заказа держу отдельную метку «блюдо готово» — курьер видит её в мобильном приложении и понимает, что можно забирать, без звонка на кухню.
с чего начинать, если ресторан один и бюджет ограничен
Не пытайтесь закрыть все девять пунктов выше сразу — большинство моих проектов в HORECA стартуют с двух вещей: воронка заказов на доставку и открытая линия, которая сводит сайт и мессенджеры в одну точку. Остальное — бронь стола, банкетная воронка, автоматизация повторных визитов — добавляется поэтапно, когда первая часть уже работает и персонал к ней привык.
Если не уверены, с чего начать именно для вашего формата — проще один раз посчитать объём работ и стоимость, чем гадать по чужим кейсам. Полный список услуг по внедрению — если решите, что настройку удобнее доверить интегратору, а не разбираться самостоятельно силами администратора.