Стоп-лист из кассы: как не продавать то, чего нет на кухне

Гость оформил заказ, оплатил, ждёт — а на кухне нет форели. Разбираем, как стоп-лист из кассы закрывает эту дыру и почему без синхронизации с сайтом и ботом он работает вхолостую.

Что такое стоп-лист и почему он дороже, чем кажется

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

Посчитаем на пальцах. Заведение на 60 заказов в день, «мёртвых» позиций в среднем 3–5 в сутки. Даже если на них попадают 2 гостя в день — это два конфликта, два возврата, два человека, которые в следующий раз закажут у конкурента. LTV гостя доставки — 8–15 тысяч рублей в год. Две потерянные лояльности в день превращаются в сотни тысяч убытка за год, и это без учёта отзыва на картах со звездой «2».

Продать блюдо, которого нет, дороже, чем не продать его вовсе. Первое стоит гостя, второе — только одного чека.

Стоп-лист в iiko: как это устроено

В iiko стоп-лист — штатный механизм, он живёт внутри системы и умеет закрывать позиции автоматически и вручную.

Автоматический стоп-лист по остаткам

Если вы ведёте техкарты и списание, iiko сам считает, на сколько порций хватит продукта, и ставит блюдо в стоп при обнулении остатка. Это работает только при честном складе: заведены техкарты, приходы оформляются, инвентаризация регулярная. Настраивается в разделе «Товары и склады» → контроль остатков по позиции.

Ручной стоп-лист

Быстрый путь для смены: на кассовом терминале iikoFront повар или менеджер помечает блюдо как «в стоп-лист» в пару касаний. Позиция мгновенно гаснет на кассе. Так закрывают то, что склад не видит: пригорела партия, нет газа, повар заболел.

Ключевой вопрос — доходит ли этот стоп-лист до внешних каналов. Через Transport API iiko (тот же интерфейс, что используют агрегаторы и внешние сайты) стоп-лист отдаётся наружу: метод получения меню возвращает признак стопа, а вебхуки могут уведомлять об изменении. Именно на это опираются интеграции с сайтом, ботом и ИИ-приёмом заказов.

Стоп-лист в FrontPad: проще, но требует дисциплины

FrontPad популярен у доставок и небольших сетей за счёт лёгкости. Стоп-лист здесь реализован прямолинейно: у товара есть признак доступности, который переключается в админке или через API.

• Вручную: в карточке товара снимаете галку «активен» — позиция пропадает из продажи.
• Через API: метод обновления товара позволяет менять доступность программно, а метод получения меню — читать актуальные стопы. На этом строится синхронизация с сайтом и ботами.

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

Главная ошибка: стоп-лист есть, а каналы о нём не знают

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

Причина всегда одна: каналы не подключены к кассе напрямую и не читают её стоп-лист в реальном времени. Ниже — где обычно рвётся синхронизация и что с этим делать.

Как выстроить синхронизацию: пошагово

1. Определите источник правды. Это касса (iiko или FrontPad), а не таблица в блокноте и не память менеджера. Все каналы должны читать стоп-лист оттуда.
2. Подключите каналы по API. Сайт, бот и приём заказов должны запрашивать актуальное меню кассы, а не работать по выгрузке недельной давности.
3. Настройте частоту обновления. Для доставки в пик — не реже раза в 1–5 минут, а лучше по вебхуку об изменении стопа. Раз в час — это уже дыра на весь обед.
4. Заведите правило проверки перед подтверждением. Идеально, когда система перепроверяет наличие ровно в момент, когда гость подтверждает заказ, — так закрывается разрыв «пока гость думал, блюдо ушло в стоп».
5. Пропишите сценарий отказа. Если позиция в стопе, гостю не «ошибка», а живой ответ: «сегодня закончилась форель, могу предложить сибас или дораду — оба свежие».

Где это закрывает ИИ-администратор

Ручной приём заказов ломается ровно там, где смена забыла обновить меню. Приём заказов можно завязать на кассу так, чтобы стоп-лист учитывался автоматически — это, например, умеет Людочка: она принимает заказ в чате, мессенджере или по телефону, сверяется со стоп-листом iiko или FrontPad и не даёт оформить то, чего нет. Вместо тупика гостю предлагается замена, а сам заказ уходит обратно в кассу. Плюс она отвечает 24/7 и подхватывает ночные и пиковые часы, когда никто не успевает трогать галки.

Чек-лист: наведите порядок в стоп-листе за смену

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

Стоп-лист — не про «чего у нас нет», а про доверие гостя. Настроенный один раз и синхронизированный со всеми каналами, он тихо экономит вам возвраты, нервы смены и звёзды на картах.