Доставка приехала, гость открыл коробку — а там не то блюдо. Или хуже: заказ приняли, оплатили, а через двадцать минут позвонили и сказали, что позиции нет, предложили заменить или вернуть деньги. Для гостя это испорченный вечер. Для заведения — возврат, негативный отзыв, а иногда и санкции со стороны агрегатора. Всё это происходит из-за одной проблемы: стоп-лист существует на кухне, но не существует в меню. Разберём, почему так происходит, чем это опасно и как синхронизировать кухню и меню так, чтобы «фантомных» блюд не было.
Что такое стоп-лист и почему он «не существует»
Стоп-лист — это перечень позиций, которых в данный момент нет или которые нельзя приготовить. Причины разные: закончились ингредиенты, сломалось оборудование, блюдо не успевают готовить в час пик, поставщик не привёз товар.
На кухне стоп-лист существует всегда. Повар знает, что лосось закончился, и не приготовит ролл. Официант знает, что пицца с трюфелем недоступна, и не пробьёт её в зале. Но как только заказ приходит из другого канала — с сайта, из приложения, из агрегатора, из мессенджера — этот стоп-лист «исчезает». Гость видит блюдо в меню, добавляет в корзину, оплачивает. И только потом выясняется, что приготовить его не из чего.
Это и есть «стоп-лист, которого нет»: он есть в голове повара, но его нет там, где гость принимает решение о заказе.
Чем это опасно: не только возвраты
На первый взгляд кажется, что проблема решается просто: вернуть деньги или заменить блюдо. Но последствия глубже, и они накапливаются.
Прямые потери. Возврат денег, списание уже приготовленных ингредиентов, повторная доставка или компенсация. Если такое происходит регулярно, сумма становится заметной в отчёте.
Негативные отзывы. Гость, который ждал заказ и получил отказ, редко пишет «всё хорошо». Он пишет про срыв заказа. А такие отзывы на картах и в агрегаторах видят сотни потенциальных клиентов.
Санкции агрегаторов. Платформы следят за отменами. Если заведение часто отменяет заказы из-за отсутствия позиций, рейтинг падает, а в некоторых случаях агрегатор ограничивает показы или меняет условия сотрудничества.
Потеря доверия. Гость, которому один раз отказали в заказе, может не вернуться. А привлечение нового гостя стоит в разы дороже, чем удержание существующего.
Путаница внутри команды. Официант, кассир, администратор и повар работают по разным данным. Кто-то знает, что блюдо закончилось, кто-то нет. В итоге заказ пробивают, а потом отменяют.
Почему ручная синхронизация не работает
Самый частый аргумент: «Мы же говорим повару, он сообщает администратору, тот убирает блюдо из меню». На практике эта цепочка рвётся в нескольких местах.
Первое — скорость. Пока информация доходит от кухни до администратора, а тот вручную правит меню в пяти местах (сайт, приложение, агрегатор, соцсети, телефон), проходит время. За эти минуты заказ уже может поступить.
Второе — человеческий фактор. Кто-то забыл, кто-то не успел, кто-то ушёл на перерыв. В час пик, когда заказов много, синхронизация отходит на второй план — и именно тогда, когда она нужнее всего.
Третье — количество каналов. Если у заведения есть свой сайт, приложение, агрегатор и телефон, меню нужно править в каждом из них. Пять каналов — пять ручных действий. Каждое можно забыть.
Четвёртое — обратная синхронизация. Когда ингредиенты снова появились, блюдо нужно вернуть во все каналы. Об этом забывают чаще всего: гость не видит позицию, хотя она уже доступна.
Пятое — разные единицы учёта. Кухня считает в граммах и порциях, а меню — в позициях. Иногда блюдо есть «почти», но не хватает одного ингредиента. Формально оно в стоп-листе, но в меню всё ещё висит.
Как должна работать синхронизация
Правильная синхронизация — это когда стоп-лист существует в одном месте, а все каналы показывают одно и то же. Не «примерно одинаково», а именно одно и то же.
Единый источник данных. Стоп-лист должен вестись в одной системе, а не в блокноте на кухне. Как только повар отмечает, что позиция закончилась, — система фиксирует это и передаёт дальше.
Мгновенное обновление всех каналов. Сайт, приложение, агрегатор, электронное меню — всё должно обновиться автоматически. Гость, который открывает приложение через минуту после того, как блюдо закончилось, не должен видеть его в меню.
Автоматическое списание остатков. Если блюдо продаётся, ингредиенты должны списываться. Когда остаток ингредиента достигает нуля, блюдо автоматически уходит в стоп-лист. Это работает лучше, чем ручное отслеживание.
Обратная синхронизация. Когда ингредиенты снова появились, блюдо должно вернуться во все каналы так же автоматически. Не нужно ждать, пока кто-то вспомнит и вручную снимет его со стопа.
Уведомления. Администратор должен получать уведомление, когда позиция уходит в стоп-лист и когда возвращается. Это позволяет контролировать процесс и реагировать на причины.
Где чаще всего рвётся цепочка
| Место разрыва | Что происходит | К чему приводит |
|---|---|---|
| Кухня → администратор | Повар узнал, что ингредиент закончился, но не сообщил | Заказ принят, потом отменён |
| Администратор → меню | Сообщили, но забыли убрать позицию из канала | Гость видит и заказывает недоступное блюдо |
| Меню → агрегатор | На сайте убрали, в агрегаторе — нет | Заказ из агрегатора с отменой |
| Остатки → меню | Ингредиент закончился, но блюдо не ушло в стоп | Кухня не может приготовить, но заказ уже принят |
| Возврат из стопа | Ингредиенты появились, но блюдо не вернули в меню | Потерянные продажи, гость не видит позицию |
| Телефонные заказы | Оператор не видит актуальный стоп-лист | Принимает заказ на позицию, которой нет |
Что нужно настроить, чтобы стоп-лист работал
Единая система для всех каналов. Если сайт, приложение и агрегатор работают на разных платформах, между ними нужна интеграция. Идеально — когда все каналы берут данные из одного источника.
Автоматическое списание по техкартам. Когда блюдо продаётся, ингредиенты должны списываться автоматически. Это не только решает проблему стопа — это ещё и контроль расхода продуктов.
Пороговые остатки. Настройте минимальный остаток, при котором позиция автоматически уходит в стоп. Например, если остаток лосося меньше двух порций, блюдо снимается с продажи.
Роли и доступы. Повар, администратор и управляющий должны иметь возможность обновлять стоп-лист — но с разными правами. Например, повар отмечает отсутствие ингредиента, администратор подтверждает стоп, управляющий видит историю.
Уведомления на все каналы. Как только позиция ушла в стоп, администратор получает уведомление. Это позволяет проверить, что все каналы обновились корректно.
История стоп-листов. Важно видеть, какие блюда чаще всего уходят в стоп и почему. Если одно и то же блюдо постоянно заканчивается к вечеру, это сигнал о проблемах с планированием закупок.
Как это выглядит в Yooapp
В Yooapp стоп-лист работает как единый механизм, а не как отдельная запись в блокноте.
Единый стоп-лист для всех каналов. Позиция, которую отметили как недоступную, автоматически исчезает из меню на сайте, в приложении и в интеграциях с агрегаторами. Не нужно править каждый канал вручную.
Автоматическое списание ингредиентов. Когда блюдо продаётся, ингредиенты списываются по техкартам. Когда остаток подходит к нулю, блюдо уходит в стоп-лист.
Уведомления для администратора. О том, что позиция ушла в стоп или вернулась, приходит уведомление. Это позволяет быстро проверять корректность.
История и аналитика. Видно, какие блюда чаще всего уходят в стоп, в какое время, по какой причине. Это данные для планирования закупок и корректировки меню.
Обратная синхронизация. Когда ингредиенты снова появились, позиция возвращается в меню автоматически или по подтверждению администратора.
Чек-лист: как проверить, есть ли у вас проблема
| Вопрос | Да / Нет |
|---|---|
| Повар знает, что блюдо закончилось, но администратор — нет | ☐ |
| Меню в приложении и в агрегаторе обновляется вручную | ☐ |
| Были случаи, когда заказ отменяли из-за отсутствия блюда | ☐ |
| После возврата ингредиентов блюдо не сразу появляется в меню | ☐ |
| Телефонные заказы принимают без проверки стоп-листа | ☐ |
| Нет истории, какие блюда чаще всего уходят в стоп | ☐ |
| Списание ингредиентов делается вручную или «на глаз» | ☐ |
Если вы отметили хотя бы три пункта — у вас есть «стоп-лист, которого нет». И это стоит денег каждый день.
Заключение
Стоп-лист — это не бюрократическая формальность. Это инструмент, который защищает и гостя, и заведение. Гость не получает отказ после оплаты, заведение не теряет деньги на возвратах и не портит репутацию.
Проблема «стоп-листа, которого нет» решается не дисциплиной персонала, а системой. Когда кухня, меню, сайт, приложение и агрегаторы работают на одних данных, стоп-лист становится единым для всех. А значит — заказов, которые невозможно приготовить, просто не будет.
Хотите, чтобы стоп-лист синхронизировался со всеми каналами автоматически? В Yooapp есть единый стоп-лист, автосписание ингредиентов по техкартам и уведомления для администратора. Оставьте заявку — покажем, как это работает на примере вашего заведения.