Автор статьи: Максим Новиков
У ресторанов, кафе, пекарен, кулинарий и служб доставки часто есть товары, которые нельзя просто “готовить бесконечно”.
Это может быть:
- готовая продукция на день;
- блюда с ограниченной заготовкой;
- полуфабрикаты;
- витринные позиции;
- позиции с коротким сроком реализации;
- товары, которые продаются со склада;
- продукция, которая заканчивается в течение дня и не доготавливается.
В обычной доставке логика достаточно простая: гость выбирает блюдо, оформляет заказ, ресторан готовит и отдаёт его в доставку или самовывоз.
Но если бизнес работает с ограниченными остатками, появляется более сложный вопрос:
как принимать заказы онлайн с сайта и мобильного приложения так, чтобы не продать больше, чем реально есть в наличии?
Особенно если ресторан или доставка работает на iiko, использует складской учет, остатки по позициям и хочет, чтобы сайт или мобильное приложение показывали актуальную доступность товаров.
Именно такой сценарий мы сейчас прорабатываем в одном из проектов РЕСТОЦРМ / RESTOCRM: как корректно связать онлайн-витрину, остатки iiko и путь клиента от выбора товара до оплаты и оформления заказа.
Почему обычной логики “меню на сайте” здесь недостаточно
Если у ресторана классическое меню, позиции обычно доступны постоянно: пицца, роллы, салаты, напитки, горячие блюда. Если ингредиенты есть, кухня готовит заказ.
Но в модели с ограниченными остатками всё иначе.
Представим, что утром на точке есть:
- 12 порций готового блюда;
- 8 наборов;
- 5 десертов;
- 20 единиц товара;
- 3 позиции, которые больше не будут доготавливаться сегодня.
Если сайт просто показывает меню без учета остатков, сразу возникают риски:
- гость может заказать товар, которого уже нет;
- несколько клиентов могут одновременно положить последнюю позицию в корзину;
- товар может закончиться в офлайне, но остаться доступным онлайн;
- оператору придется звонить и заменять позицию;
- клиент оплатит заказ, а ресторан не сможет его выполнить;
- команда начнет решать проблему вручную, вместо того чтобы обрабатывать заказы.
Для гостя это выглядит как плохой сервис.
Для ресторана — как операционная ошибка, потеря времени и риск негатива.
Поэтому в таких проектах важно не просто “сделать сайт”, а правильно спроектировать логику работы с остатками.
Ключевая задача: показать гостю реальные остатки
Первая задача — связать онлайн-витрину с фактическими данными.
Если ресторан работает на iiko и ведет остатки, сайт или приложение должны не просто показывать каталог, а учитывать, какие позиции доступны на текущий момент.
В рамках текущей проработки мы уже реализовали важный технический шаг: подтягиваем данные с iiko-сервера по текущим остаткам.
Это позволяет строить более точную онлайн-витрину:
- показывать доступные позиции;
- скрывать или ограничивать недоступные товары;
- учитывать остатки по конкретной точке или складу;
- обновлять данные не вручную, а на основании учетной системы;
- снижать риск продажи того, чего уже нет.
Но получение остатков — это только первая часть задачи.
Дальше начинается самое важное: нужно определить бизнес-логику.
Главный вопрос: когда товар должен резервироваться или списываться
В проектах с ограниченными остатками всегда возникает несколько принципиальных вопросов.
1. Когда товар считается занятым?
Варианты могут быть разные:
- когда гость открыл карточку товара;
- когда добавил товар в корзину;
- когда перешел к оформлению заказа;
- когда подтвердил заказ;
- когда оплатил заказ;
- когда заказ был успешно создан в iiko;
- когда ресторан принял заказ в работу.
Каждый вариант влияет на бизнес-процесс.
Если резервировать товар слишком рано, можно столкнуться с ложными резервами: клиент положил товар в корзину и ушел, а позиция стала недоступна для других гостей.
Если резервировать слишком поздно, можно получить другую проблему: два клиента одновременно оформляют последнюю позицию, и одному из них придется показывать сообщение, что товар закончился.
Поэтому здесь нельзя дать универсальный ответ. Нужно проектировать сценарий под конкретную модель бизнеса.
2. Что делать, если товар закончился в момент оформления заказа?
Это один из самых важных клиентских сценариев.
Гость мог открыть сайт, увидеть доступную позицию, добавить ее в корзину, но пока он выбирал другие блюда, остаток изменился.
В этот момент система должна корректно обработать ситуацию.
Возможные сценарии:
- показать уведомление, что позиция закончилась;
- предложить удалить товар из корзины;
- предложить замену;
- пересчитать заказ;
- не дать перейти к оплате;
- если оплата уже началась — корректно остановить оформление;
- если заказ уже создан — передать понятный статус оператору.
Важно, чтобы гость не попадал в тупик.
Он должен понимать, что произошло и что делать дальше.
3. Когда принимать оплату
Оплата — отдельная чувствительная зона.
Если товар может закончиться в течение дня, нужно заранее решить:
когда безопасно брать оплату с гостя?
Например, если оплата проходит до финальной проверки остатков, есть риск: деньги списались, а товара уже нет. Тогда ресторану придется делать возврат, звонить клиенту, заменять позицию и тратить время команды.
Поэтому в таких проектах нужно внимательно проектировать связку:
корзина → проверка остатков → подтверждение заказа → оплата → передача в iiko
И здесь возможны разные архитектуры:
- сначала проверка остатков, потом оплата;
- сначала создание предварительного заказа, потом оплата;
- резерв на короткое время;
- финальная проверка перед оплатой;
- финальная проверка перед отправкой заказа в iiko;
- комбинированный сценарий.
Какой вариант выбрать — зависит от того, как устроен бизнес: насколько быстро меняются остатки, сколько одновременных заказов, есть ли офлайн-продажи, как работает кухня или склад, какие требования к оплате и возвратам.
4. Что делать с корзиной, если остаток изменился
Отдельный вопрос — поведение корзины.
Например, гость положил в корзину 3 позиции, а через несколько минут одна из них закончилась.
Система должна решить:
- удалить позицию автоматически или попросить гостя подтвердить;
- пересчитать сумму;
- сохранить остальные товары;
- показать понятное сообщение;
- предложить альтернативу;
- не сбросить весь заказ.
Хорошая корзина в таком сценарии не должна “ломать” путь клиента.
Она должна аккуратно провести его через изменение остатков и сохранить максимум удобства.
5. Что делать с несколькими точками, складами и зонами доставки
Если у бизнеса несколько точек или складов, задача становится ещё сложнее.
Клиент выбирает адрес доставки — и только после этого становится понятно, с какой точки или склада его обслуживать.
Значит, остатки должны зависеть от выбранного адреса или зоны доставки.
Логика может быть такой:
- Гость заходит на сайт или в приложение.
- Указывает адрес.
- Система определяет зону доставки.
- Зона связывается с конкретной точкой или складом.
- Онлайн-витрина показывает остатки именно этой точки.
- Гость выбирает только те позиции, которые доступны для его адреса.
Это важно для проектов, где ассортимент может отличаться по локациям.
Например, в одной точке товар есть, а в другой уже закончился.
Если не учитывать эту логику, сайт будет показывать “среднее меню”, которое не соответствует реальной доступности.
Почему такие сценарии нужно прорабатывать вместе с клиентом
Работа с остатками — это не только техническая интеграция.
Это совместная проработка бизнес-правил.
Технически можно получить остатки, передать заказ, обновить витрину, проверить позиции. Но бизнес должен ответить на вопросы:
- когда товар резервируется;
- сколько живет резерв;
- что делать с неоплаченным заказом;
- когда проводить финальную проверку;
- что делать при расхождении остатков;
- как обрабатывать частично недоступный заказ;
- какие сообщения показывать гостю;
- какие действия должен видеть оператор;
- что важнее: минимизировать отказы или не блокировать остатки слишком рано.
Именно поэтому в таких проектах мы не обещаем “одну кнопку”, которая решит все сценарии.
Мы сначала разбираем реальную модель работы, а затем проектируем логику под неё.
Что уже можно реализовать в такой интеграции
В проектах на базе РЕСТОЦРМ / RESTOCRM и iiko можно прорабатывать следующие сценарии:
- получение текущих остатков с iiko-сервера;
- отображение доступности товаров на сайте;
- отображение доступности товаров в мобильном приложении;
- скрытие недоступных позиций;
- ограничение количества товара для заказа;
- проверка остатков перед оформлением;
- проверка остатков перед оплатой;
- связь ассортимента с точкой или складом;
- логика “адрес → зона доставки → точка/склад → остатки”;
- передача заказа в учетную систему;
- клиентские уведомления при изменении доступности.
Список может меняться в зависимости от конкретной конфигурации iiko, бизнес-логики проекта и требований клиента.
Почему это важно для ресторанов, пекарен, кулинарий и доставок
Если вы продаете блюда или товары с ограниченными остатками, онлайн-заказ должен быть точным.
Иначе сайт и приложение начинают создавать проблемы:
- принимают заказы на отсутствующие позиции;
- перегружают операторов;
- создают возвраты;
- портят клиентский опыт;
- увеличивают ручной труд;
- вызывают негатив у гостей.
Правильно настроенная интеграция помогает сделать иначе:
- гость видит актуальную доступность;
- команда получает меньше спорных заказов;
- оператор меньше звонит по заменам;
- онлайн-канал становится надежнее;
- бизнес лучше контролирует продажи;
- сайт и приложение работают как продолжение учетной системы, а не как отдельная витрина.
Важный вывод: остатки — это часть клиентского сервиса
Иногда остатки воспринимают как внутренний складской вопрос.
Но для онлайн-продаж это уже часть сервиса.
Если товар доступен на сайте, гость ожидает, что он действительно сможет его купить.
Если товар закончился, гость должен узнать об этом до оплаты, а не после звонка оператора.
Поэтому качественная работа с остатками — это не только про склад.
Это про доверие к бренду, удобство заказа и снижение операционного хаоса.
Как РЕСТОЦРМ / RESTOCRM подходит к таким задачам
Мы сейчас прорабатываем такой сценарий совместно с клиентом: получение остатков с iiko-сервера, отображение актуальных данных на онлайн-витрине и дальнейшую логику резервирования, списания и оформления заказа.
Это не типовая “галочка в настройках”, а проектная задача, где важно правильно согласовать путь клиента и внутреннюю операционную модель.
Если у вас похожий кейс — вы работаете на iiko, продаете товары или блюда с ограниченными остатками, хотите принимать заказы с сайта или мобильного приложения и боитесь перепродаж — такую задачу можно отдельно разобрать.
Мы посмотрим вашу модель, проверим, какие данные доступны, какие сценарии можно реализовать и как лучше выстроить интеграцию. Если технически и архитектурно сценарий реализуем, поможем проработать его под ваш бизнес.