Синхронизация стоп-листа: касса, сайт и бот в одном месте

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

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

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

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

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

Три места, где стоп-лист должен совпадать

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

• Касса (iiko, FrontPad, СБИС Presto, r_keeper). Это источник правды. Именно здесь повар или менеджер ставит позицию в стоп, и именно отсюда данные должны расходиться дальше.
• Сайт и приложение доставки. Витрина, где гость выбирает. Стоп лист на сайте должен либо прятать позицию, либо показывать её серой с подписью «нет в наличии».
• Бот и мессенджеры (Telegram, WhatsApp, VK), а также голосовой приём заказов. Самый коварный канал: тут гость общается «вживую», и предложить ему то, чего нет, — особенно неловко.

Правило простое: стоп-лист заводится в одном месте — в кассе. Все остальные каналы только читают его и подчиняются. Как только появляется второй «источник правды», начинается хаос.

Как работает синхронизация стоп-листа технически

Есть два принципиально разных способа связать системы. От выбора зависит, насколько быстро сайт узнает, что кальмар закончился.

Вариант 1. Опрос по расписанию (polling)

Сайт или сервис раз в N минут спрашивает у кассы: «покажи текущий стоп-лист». Получил — обновил витрину. Просто в реализации, но есть задержка: если опрос раз в 5 минут, то ровно столько времени гость может заказывать уже несуществующее блюдо.

Вариант 2. Вебхуки (push)

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

Вот как это выглядит по популярным кассам в реальности — без прикрас:

Честно: «мгновенной» синхронизации из коробки почти нигде нет. Реальная задержка — от нескольких секунд (вебхук) до нескольких минут (опрос). Задача — сделать её предсказуемой и короткой, а не нулевой.

Пошаговая настройка синхронизации

Порядок действий, который работает для большинства заведений на доставке.

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

Самое слабое звено — бот и голос

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

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

Здесь как раз закрывает боль ИИ-администратор. Наша Людочка держит связь с кассой и перед подтверждением заказа сверяется с актуальным стоп-листом: если позиция ушла в стоп, она не примет заказ вслепую, а предложит гостю альтернативу человеческим языком — «Филадельфии сегодня нет, но есть очень похожая Калифорния, взять её?». Тем же контуром пользуется и голосовой приём заказов: правило доступности одно на все каналы, а не отдельное для чата и отдельное для телефона.

Чек-лист: что проверить, чтобы стоп-лист не подводил

• Идентификаторы блюд совпадают в кассе, на сайте и в боте.
• Есть один источник правды — касса, остальные каналы только читают.
• Интервал опроса не больше 2 минут (или настроен вебхук).
• Витрина корректно показывает недоступные позиции.
• Бот и голос сверяются со стопом в момент заказа, а не по старому кэшу.
• Возврат позиции из стопа отрабатывает так же быстро, как постановка.
• Модификаторы и топпинги тоже уходят в стоп (нет сыра — нет и опции «добавить сыр»).
• Есть уведомление менеджеру, если синхронизация оборвалась.

Отдельно про последний пункт: если интеграция «легла» и данные перестали обновляться, вы должны узнать об этом первым, а не от разгневанного гостя. Настройте простой алерт «данные о наличии не обновлялись N минут».

Сколько это стоит в деньгах

Прикинем на пальцах. Заведение на доставке с 40 заказами в день. Даже если рассинхрон стоп-листа портит 2–3 заказа в сутки — это около 70–90 испорченных заказов в месяц. При среднем чеке 900 рублей и отмене хотя бы трети из них вы теряете 20–25 тысяч рублей выручки ежемесячно. Плюс отзывы, которые бьют по новым гостям ещё месяцами.

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