Единое меню сети в приложении без сбоя стоп-листов
Как объединить меню всех точек сети в одном приложении и не сломать стоп-листы: пошаговый гайд для ресторатора с разбором ошибок и расчётом окупаемости.
Коротко: Главная ошибка при объединении меню сети — общий стоп-лист на все точки. Отключили позицию на одной кухне — и гость на другом конце города видит, что блюда нет вообще нигде. Правильная архитектура другая: единое меню-каталог, но с индивидуальными остатками и стоп-листами по каждой точке сети. Это вопрос настройки платформы, а не программирования. Окупаемость приложения сети считается отдельно от логики меню.
Объединение меню сети — это перенос всех позиций из разных точек в единый каталог приложения, который при этом сохраняет за каждой точкой самостоятельное управление остатками и доступностью блюд. Задача простая: гость видит актуальное меню именно своей точки, а администратор не боится тронуть стоп-лист на одной кухне сети.
По опыту внедрения таких сценариев в сетевых проектах на платформе Foodonaut, большинство сбоев с меню возникает не из-за технических ограничений. Причина в другом: архитектуру каталога изначально проектируют как для одного ресторана, а не для сети с десятками точек.
Что понадобится
Перед тем как объединять меню сети, соберите три вещи: сведённый прайс-лист по всем точкам, понимание, какие позиции общие, а какие уникальны для конкретного филиала, и доступ к панели управления приложением с правами на настройку точек.
- Единый прайс-лист — таблица со всеми блюдами сети, ценами и точками, где они продаются.
- Карта уникальных позиций — список блюд, которые есть не во всех точках (сезонные, локальные, тестовые).
- Доступ администратора к настройке точек в приложении — без этого разграничить стоп-листы не получится.
- Ответственный за стоп-листы на каждой точке — сотрудник, который вносит отключения в реальном времени.
Общий стоп-лист на всю сеть — это не экономия времени, это гарантированная потеря заказов на точках, где блюдо есть.
Шаг 1. Создать единый каталог, но развязать точки по остаткам
Заведите все блюда сети в общий каталог приложения, но привязку доступности каждой позиции сделайте к конкретной точке, а не к меню целиком. Тогда одно и то же блюдо может быть в стоп-листе на одной кухне и в продаже на другой — одновременно.
Технически это выглядит так: у блюда есть общая карточка (название, фото, описание, состав) и отдельный параметр «доступность» для каждого филиала сети. Когда администратор точки отключает позицию, система меняет статус только для этой точки — карточка в каталоге остаётся, у остальных точек ничего не меняется.
Если платформа позволяет привязать блюдо сразу к нескольким точкам через один товар в каталоге — это экономит время: не придётся создавать дубликаты карточек для каждого филиала.
Шаг 2. Настроить стоп-листы по точкам, а не по сети
Убедитесь, что стоп-лист физически изолирован на уровне точки. Проверьте это до запуска: отключите тестовое блюдо на одной точке и посмотрите, видно ли оно на других точках сети.
На практике встречаются три варианта разграничения:
| Уровень разграничения | Что происходит при отключении | Риск |
|---|---|---|
| Общий стоп-лист на сеть | Блюдо пропадает у всех точек | Высокий — теряете заказы там, где блюдо есть |
| Стоп-лист по точке (правильно) | Блюдо пропадает только на одной точке | Низкий — гости других точек видят блюдо |
| Стоп-лист по точке + автоуведомление менеджеру | Блюдо пропадает локально, менеджер получает сигнал | Минимальный — контроль в реальном времени |
Настройте роли сотрудников так, чтобы менеджер точки видел и мог менять стоп-лист только своей точки. Это исключает случайное отключение блюда на чужом филиале сети.
Шаг 3. Проверить синхронизацию цен и позиций перед запуском
Сделайте тестовый прогон: заказать одно и то же блюдо с трёх разных точек и сверить цену, состав и время готовности. Разница в цене между точками — нормальная практика для сети (разная аренда, разная логистика), но приложение должно отражать её корректно, а не «съедать» единым прайсом.
Что проверить перед стартом:
- Совпадает ли цена блюда в приложении с ценой в кассовой системе конкретной точки.
- Отображается ли у гостя точка, к которой привязан его заказ, а не абстрактное «меню сети».
- Обновляется ли стоп-лист в приложении сразу после отметки на точке, без задержки на синхронизацию.
- Не появляются ли задвоенные карточки одного блюда из-за ручного создания дубликатов на разных точках.
Если после отключения позиции на одной точке блюдо пропало у всех — это архитектурная ошибка настройки, а не сбой платформы. Решается перенастройкой привязки блюда к точкам, без остановки продаж.
Частые ошибки при объединении меню сети
Большинство проблем возникает не из-за платформы, а из-за того, что сеть переносит логику одиночного ресторана на несколько точек без адаптации. Вот три ошибки, которые повторяются чаще всего.
- Один стоп-лист на всю сеть. Самая частая ошибка из вопроса читателя: администратор отключает позицию, думая, что делает это локально, а блюдо исчезает у всех точек сети. Решение — заранее проверить, что стоп-лист настроен по точкам, а не глобально.
- Дублирование карточек блюда вместо привязки к нескольким точкам. Возникает видимость разных блюд, путаница в отчётах и риск, что цену обновят в одной карточке, а не в другой.
- Нет ответственного за стоп-лист на конкретной точке. Если обновлять доступность блюд должен «кто-то из смены», это происходит с опозданием — и гости заказывают то, чего физически нет на кухне.
Итог
Объединить меню сети в одном приложении без риска для стоп-листов можно. Но строить каталог нужно сразу по принципу «одна карточка блюда — множество точек с независимой доступностью», а не «одно меню на всех». Проверка синхронизации цен и стоп-листов перед запуском экономит недели разбора жалоб от гостей.
Экономику самого приложения считают отдельно от логики меню: агрегаторы удерживают 25–35% с заказа (vc.ru, данные рынка 2026), тогда как тариф Foodonaut за своё приложение — 4% от выручки. Себестоимость собственной доставки ресторана при этом оценивается экспертами примерно в 25–27% от суммы заказа, что делает разницу между агрегатором и своим приложением ещё заметнее. При потоке 600 заказов в месяц со средним чеком 1200 ₽ разница между 30%-й комиссией агрегатора и 4%-м тарифом своего приложения — это сотни тысяч рублей ежемесячно. Их сеть либо отдаёт посреднику, либо оставляет себе на развитие каждой точки.
Ключевые выводы
- Комиссия агрегаторов доставки в России составляет 25–35% от суммы заказа, по оценке рынка за 2026 год (vc.ru).
- Экспертная оценка Data Insight («Доставка готовой еды», сентябрь 2025) называет комиссию агрегаторов около 35% с транзакции.
- Себестоимость собственной доставки ресторана, по экспертным оценкам, составляет примерно 25–27% от суммы заказа — это ориентир при сравнении с тарифом собственного приложения.
- Тариф Foodonaut за собственное приложение сети — 4% от выручки, что кардинально меняет финансовую модель доставки при масштабировании на несколько точек.
- Главная техническая ошибка объединения меню сети — общий стоп-лист на все точки вместо привязки доступности блюда к конкретному филиалу.
- Проверка синхронизации цен, стоп-листов и дубликатов карточек перед запуском — обязательный шаг, который экономит недели разбора претензий гостей.
Источники
- Рестораны отказываются от агрегаторов из-за высоких комиссий
- Почему в России подорожала доставка еды: мнение ресторатора - 9 мая 2026 | МГОРСК.ру
Читайте также
- Разработка приложения для сети кафе: цена и окупаемость
- Приложение для доставки без разработчика: 4% против 35%
- Блюдо не в стопе, но не отображается: 5 причин
- Какую CRM выбрать для сети кафе: без 30% комиссии
Своё приложение — 4% от выручки, а не комиссия 25–35%
Фудонавт даёт ресторану собственное приложение и сайт доставки за 4% от выручки — без фикса 20–25 тыс ₽/мес и без комиссии агрегатора с каждого заказа. Считайте экономику на своих цифрах.
