Автоматизация ресторана и кафе: что закрывает касса

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

Всё, что происходит до того, как гость сел за стол, и после того, как он ушёл, касса не видит. Заявка на банкет, пришедшая в директ соцсети. Просьба забронировать стол на восьмерых в пятницу. Вопрос про детское меню в WhatsApp в одиннадцать вечера. Отзыв на две звезды на карте через сутки после визита. Корпоративный клиент, который третий год возит к вам партнёров и о котором знает один администратор. Ни одно из этих событий не оставляет следа в кассовой системе, а деньги в них есть — иногда более крупные, чем в среднем чеке.

Поэтому вопрос «нужна ли ресторану CRM» стоит переформулировать. Вторая касса не нужна. Нужен контур вокруг кассы, который держит три вещи: длинные сделки (банкеты, кейтеринг, корпоративные договоры), общение с гостями во всех каналах и репутацию. В CRM это обычные объекты — сделка, клиент, задача, канал связи, — просто в общепите у них отраслевые названия. Касса остаётся источником правды по залу, чеку и складу, CRM отвечает за клиента, заявку и деньги вне чека.

Небольшой кофейне на две точки такой контур, скорее всего, не нужен: поток заявок помещается в голову владельца. Он начинает окупаться там, где есть банкетное направление, несколько залов или точек, доставка и заметный поток сообщений мимо телефона. Если банкеты вы не продаёте, а отзывы разбирает лично управляющий и успевает — честный ответ в том, что автоматизировать пока нечего. Такой ответ на аудите мы тоже говорим.

Банкет — это не заказ, а сделка. Между первым сообщением «здравствуйте, у вас можно отметить юбилей на тридцать человек?» и самим вечером проходят недели: расчёт, отправка вариантов меню, предоплата, согласование тайминга, вопросы про торт и звук, изменение числа гостей за два дня до даты. Это длинный процесс с деньгами и обязательствами — ровно то, для чего CRM и придумана. Касса увидит банкет только вечером мероприятия, в виде чека.

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

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

Первое — повторные продажи. Корпоративные праздники, дни рождения компании и семейные даты повторяются с годовым циклом, и напоминание «в прошлом сентябре вы отмечали у нас день рождения компании» даёт повод для нового обращения, который иначе не возник бы. В переписке эта информация теряется за месяц, в карточке клиента она остаётся вместе с меню, которое ему понравилось, и суммой прошлого заказа.

Второе — понятные цифры вместо ощущений. Когда заявки лежат в воронке, видно, сколько их было за месяц, сколько дошло до просчёта, сколько до предоплаты и на какой стадии чаще всего срывается. Управленческий вывод из этого разный: если отваливаются после просчёта — вопрос к цене и скорости ответа, если после предоплаты — к согласованию и сервису. Без воронки обе ситуации выглядят одинаково: «банкетов стало меньше».

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

Гость пишет туда, где ему удобно: WhatsApp, Telegram, директ соцсети, чат на сайте, карты, звонок. Заведение отвечает из того приложения, которое в этот момент открыто у администратора. В результате часть сообщений остаётся без ответа — обычно ночью и в час пик, то есть ровно тогда, когда человек выбирает, куда пойти сегодня. Потерянное сообщение в общепите нередко означает, что гость ушёл к соседям, и вы об этом даже не узнаете.

Единое окно — это один интерфейс, в котором видны все каналы сразу, с историей по каждому гостю. Администратор не переключается между пятью приложениями, а работает с очередью обращений. У каждого обращения есть статус и при необходимости ответственный, поэтому сообщение перестаёт быть «прочитал и забыл»: оно либо закрыто ответом, либо превращено в задачу или в сделку на банкет.

Поверх окна ставится AI-бот на базе знаний заведения: меню и стоп-лист, часы работы, парковка, детская комната, можно ли с собакой, условия депозита на большую компанию, как добраться. Бот отвечает по вашим документам, а не общими фразами, и работает ночью, когда администратора нет. Всё, что выходит за рамки базы знаний — изменение брони в последний момент, жалоба, нестандартный запрос по мероприятию, — он передаёт человеку вместе с историей диалога. Человек остаётся в контуре, бот снимает с него повторяющееся.

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

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

Это операционный процесс со своим ответственным и сроком, а не задача «когда-нибудь займёмся маркетингом». Для ресторана отзыв на карте — это витрина: человек выбирает, куда пойти ужинать, по оценке и по последним нескольким отзывам, а не по вашему сайту. Отзыв без ответа читается как «им всё равно», и видит это не один автор, а все, кто открыл карточку заведения перед бронью.

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

Второй слой — не ответы, а причины. Когда отзывы лежат в системе размеченными по темам, видно повторяющееся: не «люди недовольны», а «за месяц несколько упоминаний долгой подачи в пятницу вечером». Это уже не маркетинг, а управленческие данные — вопрос к расписанию смены и к кухне, а не к тому, кто ведёт соцсети. Здесь помогает AI: он разбирает текст отзыва, определяет тему и тональность и готовит черновик ответа, который сотрудник правит перед отправкой.

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

Помимо коммерческого контура у общепита есть обязательный государственный, и закрывает его не CRM. Расчёты с гостями проходят через контрольно-кассовую технику с передачей данных оператору фискальных данных — это требование 54-ФЗ о применении ККТ. Розничная продажа алкоголя фиксируется в государственной системе ЕГАИС. Приёмка сырья животного происхождения — мяса, рыбы, молочной продукции — сопровождается электронными ветеринарными сертификатами, которые гасятся в системе «Меркурий» (ФГИС ВетИС).

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

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

Что действительно попадает в нашу зону ответственности — персональные данные гостей. Имя и телефон в брони, контакты заказчика банкета, переписка в мессенджерах — это персональные данные, и обрабатывать их нужно с согласием и на серверах в РФ по 152-ФЗ. Мы закладываем это в архитектуру с первого дня: где лежат данные, у кого есть доступ, что видит и что сохраняет бот. Переделывать контур после проверки дороже, чем спроектировать его правильно сразу.

Главное правило связки — один источник правды на каждый факт. Если одна и та же цифра живёт в двух системах и обе могут её менять, вы рано или поздно получите расхождение и спор о том, какая права. Поэтому до начала интеграции мы раскладываем данные по владельцам: что остаётся в кассе, что переезжает в CRM и что вторая система только читает, но не редактирует.

Здесь важно сразу развести два разных случая. Первый и основной для ресторана — у вас стоит сторонняя кассовая система: R-Keeper, iiko или аналог. Тогда обмен идёт через API этой кассы, а не ручной выгрузкой файлов раз в месяц, и первое, что мы проверяем на аудите, — открыт ли её API и отдаёт ли он нужные данные. Второй случай устроен иначе: в нашем проекте для сети банных комплексов сторонней кассы нет вообще. POS-касса кафе там — часть нашей собственной сборки на коробочном Битрикс24, работающая по REST API самого Битрикс24, то есть она изначально живёт внутри общего контура портала, а не подключается к нему снаружи. Это пример нашего собственного контура, а не интеграции со сторонним кассовым ПО, и ресторану с уже установленным R-Keeper или iiko предстоит именно первый сценарий.

Что дублировать не нужно ни при каких условиях: меню в двух местах, вторую сетку броней, ручной перенос выручки в таблицу. Каждое такое дублирование — источник расхождений и лишней работы для администратора, который в итоге начинает доверять своей тетради больше, чем обеим системам. Если обмен по какой-то причине невозможен — закрытый API, старая версия продукта, — честный вывод состоит в том, чтобы оставить участок ручным и не делать вид, что он автоматизирован.

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

Публичных кейсов именно по ресторанам у нас нет — говорим об этом прямо. Но техническая задача «касса плюс CRM в одном контуре» у нас собрана и работает в проде в смежной отрасли услуг. Для сети из пяти банных комплексов в Санкт-Петербурге мы построили на коробочном Битрикс24 единый портал: «шахматку» бронирования, рабочее место сотрудника с ролями, механику лояльности с выпуском сертификатов и абонементов — и POS-кассу кафе внутри комплекса, работающую на REST API Битрикс24. Решение работает в проде, мы ведём действующее сопровождение; клиент в публичной подаче анонимен.

Баня — не ресторан, и переносить выводы один в один мы не станем: у общепита своя кухня, свой товароучёт и своя регуляторика. Важна и вторая оговорка: касса кафе в том проекте изначально жила внутри контура портала — мы собирали её сами, а не подключали снаружи чужое кассовое ПО. У ресторана, где уже установлен R-Keeper или iiko, задача другого типа и сложнее по интеграции: подключить существующую кассу через её API. Общее у двух ситуаций одно — требование, чтобы касса была частью общего контура, а не отдельным островом, из которого данные переносят руками.

Так же устроена и вторая половина — бронирование ресурса по времени. «Шахматка» кабинок по сути мало отличается от сетки столов и банкетных залов: те же слоты, те же роли сотрудников, те же конфликты двойной брони и то же требование, чтобы занятость жила в одном месте. Эту часть мы делали как отдельное приложение поверх портала, потому что такой функциональности не было в коробке.

Контур для ресторана мы обычно строим на Битрикс24: воронка банкетов, карточка гостя, подключённые мессенджеры и соцсети, задачи с ответственными, автоматизации по срокам. Сверху — AI-бот для типовых вопросов гостей и черновиков ответов на отзывы, при необходимости собственное приложение под специфику заведения и отчёты поверх данных кассы и CRM. Что из этого нужно именно вам и в каком порядке, зависит от формата: кофейне, сети из трёх ресторанов и загородному комплексу с банкетным залом нужны разные объёмы работ.

Начните с трёх вопросов. Можете ли вы прямо сейчас назвать, сколько заявок на банкеты пришло в прошлом месяце и сколько из них состоялось? Есть ли ответственный за ответы на отзывы и срок, за который отзыв должен получить ответ? Что происходит с сообщением гостя, которое пришло в соцсеть в полночь? Три неуверенных ответа означают, что проблема не в кассе — она у вас, скорее всего, в порядке.

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

Обратный порядок — сначала интеграция с кассой, потом всё остальное — мы не советуем. Это трудоёмкая часть работ, и без выстроенных вокруг процессов она даёт красивые отчёты и ноль изменений в том, как заведение работает с гостем. Сначала процесс и ответственный, потом автоматизация процесса, и только потом обмен данными между системами.

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