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