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

Из чего состоит автоматизация кафе и ресторана

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

Что закрывает DELICIO, а что остаётся за учётной системой

DELICIO работает на уровне гостевых сервисов: мобильное приложение и веб-заказ, электронное и QR-меню, программа лояльности с бонусами и кэшбэком, push-рассылки, аналитика поведения гостей. Мы не заменяем учётную систему и не ведём за вас бухгалтерию, складской учёт и калькуляцию — это остаётся за iiko, r_keeper, Poster или тем, что уже стоит у вас на кассе. Приложение подключается к учётной системе и берёт из неё номенклатуру, цены и стоп-лист, а обратно передаёт заказы и данные о начислении бонусов. Такое разделение честнее и дешевле: заведение не переезжает с работающей кассы ради приложения, а получает дополнительный канал продаж поверх того, что уже настроено. Как устроена такая связка на практике, разобрано на странице интеграции с iiko. Если учётной системы нет вообще, начинать нужно с неё, а не с приложения. Границы стоит проговорить на берегу: если нужен полноценный складской учёт с инвентаризациями и актами, это задача учётной системы и её партнёра по внедрению, а не мобильного приложения.

Порядок внедрения, стоп-лист и работа нескольких точек

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

Типичные ошибки и с чего начать небольшому заведению

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

Несколько точек добавляют к автоматизации отдельный слой. Гость должен видеть меню и цены той точки, из которой заказывает, а не общий список сети. Стоп-листы у точек разные, график работы разный, иногда различается и сам ассортимент. Поэтому в приложении нужен выбор заведения — по карте, по адресу или по геолокации — и привязка заказа к конкретной кассе. Бонусный счёт при этом обычно делают общим: гость копит баллы в одной точке и тратит в другой, и это одна из причин, ради которых сети вообще запускают приложение. Аналитику имеет смысл смотреть и по сети, и по каждой точке отдельно — структура заказов в спальном районе и в центре различается настолько, что усреднённая цифра не объясняет ничего. Заведения, с которыми мы работали, собраны в разделе клиентов. Ещё один вопрос по сети — единые ли цены: если они различаются между точками, это нужно поддержать и в учётной системе, и в приложении, иначе гость увидит одну сумму, а на кассе получит другую.

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

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