Автоматизация ресторана вокруг iiko: свой код связывает кассу, закупки и отзывы

Начните с того, что уже умеет ваша система. Документация iiko описывает рекомендации закупки по продажам и складской учёт; часть задачи может закрыть настройка.

DocsInBox предлагает ИИ-закупщика рядом с iiko. На 7 октября 2026 вендор описывает расчёт потребности и сравнение предложений. Это описание продукта, не наш замер.

Свой код нужен для разрыва между отделами. Управляющий проверяет жалобу на отсутствующее блюдо, закупщик получает причину и поручение. Отчёт такого действия не заменяет.

Условный пример: кафе продаёт завтраки, ингредиент закончился, гость жалуется на замену блюда. До сводки надо подтвердить связь жалобы с нехваткой.

Свяжите точку, блюдо и ингредиент по справочникам. Упаковка поставщика и единица складского учёта должны совпасть после пересчёта. Совпадения названий для этого мало.

Покажите время данных рядом с выводом. Старый остаток не годится для текущей потребности. Сорванная загрузка должна отображаться как сбой, а не ноль на складе.

API позволяет программе обмениваться данными с iiko. В публичной схеме iikoCloud на 7 октября 2026 есть складские остатки, отчёты по продажам и события заказов.

Но наличие метода в документации ещё не даёт доступ вашей сети. До сметы подрядчик должен проверить права и лицензию, получить реальные ответы и сверить их с учётом точки.

Для создания доставки iiko требует проверить состояние команды. Отправка не означает исполнение. Ваша связка тоже должна получить подтверждение результата.

Для закупок сначала нужны учёт и правила расчёта. Потребность зависит от продаж, остатка и уже заказанного товара. Ошибку в единицах измерения модель не исправит.

ИИ полезен там, где вход написан словами. Он может подготовить сопоставление строки прайса с товаром или объяснение отклонения. Подозрительное совпадение подтверждает закупщик.

В условном кафе программа готовит заявку с расчётом. Закупщик сверяет поставку и подтверждает отправку. Фраза модели «должно хватить» расчёт не заменяет.

Начните с черновиков заявок рядом с привычным способом закупки. Сравнивайте их с решениями закупщика. Частые расхождения означают, что рано включать отправку заказов.

Каждая заявка должна хранить источник расчёта и статус отправки. При обрыве связи сначала выясняют, принят ли заказ. Слепой повтор может отправить поставщику дубль.

Выбор модели не заменит этот порядок. Правила расходов остаются в программе и правах доступа; границы ответственности за ошибки ИИ разобраны в соседней статье.

В условном кафе ИИ отмечает тему «блюда нет». Управляющий проверяет смену, закупщик получает подтверждённую нехватку. Один ответ гостю причину жалобы не исправит.

Жалоба с названием точки и временем сужает поиск. Она не доказывает, какой чек оплатил гость. Для связи с заказом нужен подтверждённый ключ сопоставления.

Сбор отзывов начинается с разрешённого доступа. В справке Яндекс Бизнеса описаны кабинет и модерация ответов. Универсальную автопубликацию подрядчик должен подтвердить отдельно.

ИИ может подготовить тему и черновик ответа. Управляющий подтверждает факты и публикует ответ штатным способом. Новые обещания компенсации модель сама не назначает.

В карточке жалобы нужен ответственный и срок. Общий экран показывает невыполненное поручение, даже если ответ гостю уже опубликован.

Для сводки причин не нужны контакты гостей. Если проект обрабатывает данные людей, до подключения прочитайте разбор персональных данных и ИИ-агентов.

Уведомление в Telegram ещё не означает выполненную закупку. В курсе «Агентная разработка» мы собираем бот, события, права и оплату. Из этого опыта берём порядок связки.

Урок «Устройство админки» собирает состояние машины на одном экране. В ресторане нужен тот же принцип: видны последнее успешное действие и место остановки.

На vibecoding.ru инженер ведёт машину агентов. Её тихие остановки научили нас проверять выход процесса. Ниже истории нашего сайта, а не ресторанного внедрения.

Экран отличает отсутствие жалоб от недоступного источника. Отсутствие ответа склада не превращается в «продуктов нет». Сбой получает собственный статус.

Сторож зовёт ответственного, если загрузка сорвалась или задача просрочена. После исправления та же проверка подтверждает восстановление.

Назначьте того, кто отвечает за сбой после запуска. Подписка на разработку не означает ночное дежурство у кассы. Режим сопровождения связки надо согласовать отдельно.

Пилот берёт один разрыв процесса на выбранной точке. В примере это нехватка ингредиента и жалоба. Приложение доставки требует отдельного проекта.

«Экран показывает время остатка, заявку и ответственного» можно проверить. «Нужен ИИ для ресторана» оставляет исполнителю догадки. Заказывайте проверяемый результат.

Форму задачи ИИ-агенту мы разбирали отдельно. Здесь заказчику нужен перечень приёмки: рабочий путь, сбои и способ продолжить работу вручную.

Для условного кафе связка принята, когда ингредиент поступил, блюдо доступно, а управляющий проверил результат и закрыл поручение.

Запишите до пилота время ручной сверки и число несогласованных заявок. После запуска меряйте их тем же способом. Пользу связки оценивают по работе сети.

Если доработки идут постоянно, «Один проект» на /services стоит 250 000 ₽ в месяц на 7 октября 2026. В тарифе один поток: следующая задача ждёт завершения текущей.

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

1. Проверьте готовые модули и интеграции до заказа кода. Пишите связку для оставшегося разрыва процесса.
2. Покажите источник и время данных. Старый остаток и недоступный источник должны различаться на экране.
3. Дайте ИИ подготовку решения. Отправку закупки и публичный ответ подтверждает ответственный сотрудник.
4. Закрывайте жалобу проверкой результата. Принимайте связку вместе с защитой от дублей, сторожем и способом работать вручную.