iiko
Как спроектировать цифровой контур ресторана с iiko
Практический разбор: как определить роль iiko и внешних сервисов, описать обмен данными и проверить интеграцию до запуска.

Цифровой контур ресторана складывается не из максимального числа подключенных сервисов, а из понятного распределения задач между ними. iiko может быть связана с сайтом, доставкой, CRM, программой лояльности, учетом, бронированием, киосками и аналитическими решениями. Официальный каталог iiko предусматривает интеграционные модули для этих направлений, но состав доступных сценариев зависит от конкретного коннектора, лицензий, региона, версии системы и настроек.
Начинать стоит с бизнес-сценария: например, приема заказа с сайта, передачи данных в программу лояльности или сверки продаж с учетной системой. Такой подход помогает не дублировать данные в нескольких программах и заранее определить, где сотрудники будут исправлять ошибки.
Что подготовить до выбора интеграции
- Список систем, которые уже используются: iiko, сайт, доставка, CRM, учетная система, сервис лояльности или аналитики.
- Описание процесса от действия гостя до закрытия заказа: кто принимает заказ, где меняется статус, где фиксируется оплата и кто обрабатывает отмены.
- Перечень данных для обмена: меню, стоп-лист, модификаторы, заказ, статус, клиент, бонусы, оплата, документы учета.
- Ответственных за справочники и исправление ошибок: меню, номенклатуру, цены, клиентские данные и статусы заказов.
- Тестовые сценарии, включая отмену, возврат, повторную отправку заказа, недоступность внешнего сервиса и расхождение данных.
Определите источник каждого типа данных
Для каждого процесса нужно назначить одну систему-источник. Если меню редактируется одновременно в iiko, на сайте и в агрегаторе доставки, сотрудники могут увидеть разные цены или состав блюд. Если статусы заказа меняются в нескольких системах без согласованного правила, управляющему будет сложнее понять, где возникла ошибка.
| Задача | Что зафиксировать | Что проверить до запуска |
|---|---|---|
| Онлайн-заказ | Где создается заказ и какая система меняет его статус | Передачу состава заказа, модификаторов, отмены и возврата |
| Меню и стоп-лист | Кто отвечает за цены, доступность и состав блюд | Соответствие меню в подключенных каналах и расписание доступности |
| Лояльность | Какие данные о госте и бонусах передаются | Правила начисления, списания и обработки дублей |
| Учет и отчетность | Какие документы и показатели нужны вне iiko | Периодичность обмена, сверку сумм и ответственного за расхождения |
Проверьте путь данных, а не только наличие коннектора
Наличие модуля в каталоге не означает, что он решит конкретную задачу без настройки. До подключения полезно описать маршрут каждого важного объекта: откуда он появляется, какие поля передаются, когда обновляется информация и что считается успешным результатом. Для внешнего меню важны не только названия блюд и цены, но и доступность позиций: в iikoWeb расписание доступности меню задается в настройках, поэтому внешняя система может получать меню только в установленный период.
Отдельно стоит проверить способ подключения. iiko сообщала, что старый способ авторизации API был полностью отключен 29 августа 2026 года. Для новых интеграционных сервисов требуется актуальная схема регистрации на портале разработчика. Не стоит использовать старые инструкции или передавать доступы подрядчику без проверки выбранного способа интеграции.
Согласуйте контрольные точки
Контрольные точки позволяют заметить проблему до того, как она превратится в потерянные заказы или расхождения в учете. Для каждого обмена определите, кто видит ошибку, сколько времени допустимо ждать обновления и какое действие выполняется при сбое. Это особенно важно для заказов, оплат, бонусов и документов, которые нельзя без последствий создать дважды.
Условный пример: заказ с сайта передается в iiko, но подтверждение оплаты приходит с задержкой. До запуска команда фиксирует, может ли кассир закрыть такой заказ вручную, как исключить повторное списание и где затем сверить статус заказа с данными платежного сервиса. Это учебный сценарий, а не описание работы конкретной интеграции.
Типичные ошибки и ограничения
- Подключать сервис по названию функции, не проверив поддерживаемую версию iiko, лицензию и доступные методы обмена.
- Считать, что все данные синхронизируются автоматически, не согласовав состав полей, расписание обновления и правила обработки ошибок.
- Оставлять несколько владельцев одного справочника: например, менять цены одновременно в разных системах.
- Проверять только успешный заказ и не тестировать отмены, возвраты, дубли и недоступность внешнего сервиса.
- Оценивать аналитику без сверки первичных данных: отчет может быть точным технически, но опираться на неполные или неверно переданные сведения.
С чего начать
- Выберите один процесс, в котором ошибка или ручная работа заметнее всего: доставка, меню, лояльность, учет или отчетность.
- Опишите участников процесса и данные, которые должны передаваться между системами.
- Назначьте систему-источник для каждого ключевого объекта и ответственного за его корректность.
- Согласуйте тестовые сценарии и критерии успешной передачи до настройки обмена.
- Проверьте выбранный коннектор, API-доступ, права, лицензионные условия и совместимость именно для вашей конфигурации.
Что это значит для ресторатора
Интеграция полезна, когда для каждого процесса заранее определены источник данных, правила обмена и проверка сбоев. Возможности конкретного сценария нельзя считать универсальными: их нужно подтверждать по версии iiko, условиям лицензии, API-доступу и документации выбранного сервиса.
Обсудить с экспертомОбсудим вашу задачу
Поможем разобраться с автоматизацией, учетом и настройкой iiko.
Обсудить с экспертом