Channel manager — один контур, который держит меню, цены, остатки и заказы во всех агрегаторах синхронно с вашей POS. Без ручного дублирования, без расхождений с кассой, без потерянных заказов в час пик. Делаем на foodtech-опыте 14+ лет — кейсы Burger King, KFC, Додо, Performance Food.
Channel manager (оркестратор каналов) — это сервис между вашей POS-системой и кабинетами агрегаторов, который автоматически синхронизирует меню, цены, остатки, заказы и статусы в обе стороны. Без него каждый агрегатор обновляется руками в своём кабинете — и через три месяца в Яндекс.Еде одно меню, в Купере другое, а на кассе третье.
Без channel manager сеть платит ежедневный налог:
С channel manager эти проблемы исчезают как класс: один контур, одна правда о меню и остатках, один поток заказов в POS.
Четыре опоры одного контура: единое меню, единый поток заказов, финансовая сверка и аналитика по каналам. На MVP обычно стартуют с первых двух, остальные подключают по фазам.
Блюда, фото, описания, цены, модификаторы и стоп-листы синхронизируются из POS во все агрегаторы автоматически. Одна правда о меню — без расхождений с кассой и без отмен заказов из-за «нет в наличии». Маркетолог обновляет акцию в одном месте, а не в четырёх кабинетах.
Заказы из всех агрегаторов автоматически летят в POS, а статусы (принят, готовится, готов, выдан, отменён) уходят обратно клиенту. Никакого ручного копирования заказов с планшетов в час пик — а значит, ноль потерянных позиций.
Каждый заказ из агрегатора сверяется с его выплатой, комиссии учитываются по типам (базовая, подсветка, маркетинг, курьер), корректировки задним числом отражаются автоматически. Финансист видит чистую маржу по каждому каналу, а не живёт в Excel.
Единый дашборд: какой агрегатор сколько приносит, как меняется маржа от месяца к месяцу, где аномальный рост комиссии. Отзывы и рейтинги из всех каналов в одном месте, без переключения между кабинетами.
В крупных городах ресторан обычно работает с 3–5 каналами одновременно. У каждого своя API, свои особенности и своя модель доставки.
Каждый канал — это отдельная интеграция со своей моделью данных. Channel manager скрывает эти различия за единым контуром.
Тонкая часть интеграции не в том, что синхронизируется, а в том, в какую сторону идёт каждый поток.
Десять потоков в обе стороны — полная картина. На MVP стартуют с 4–5 базовых (каталог, остатки, заказы, статусы, комиссии), остальные подключают по фазам.
Правильная архитектура — это отдельный сервис между POS и агрегаторами, а не «прямые провода» из приложения: через прямые провода ничего не масштабируется, и при сбое одного агрегатора падает весь стек. Наши слои:
Эту архитектуру мы переносим из проектов масштаба Burger King и KFC, где интеграционный слой держит пиковую нагрузку федеральной сети.
Методы: каталог (меню, цены, фото), остатки и стоп-лист, приём заказов, статусы в обе стороны, курьеры (для собственной доставки). Авторизация — партнёрский OAuth и API-ключ, документация открыта для партнёров. Подводный камень: обновления каталога часто идут не по атрибутам, а карточкой целиком — это важно учитывать при частых ценовых изменениях.
Методы: ассортимент, остатки, заказы, статусы, точки самовывоза. Авторизация — API-ключ и список разрешённых адресов для критичных операций. Ориентирован на продукты, но поддерживает готовую еду; интеграция глубже на уровне ассортимента (десятки тысяч позиций реалистичны). Подводный камень: ассортимент проверяется модератором — нужен буфер на согласование.
Не классический агрегатор, а сеть пиццерий со своей службой; на правах прямого канала — те же потоки данных, но без комиссии 25–30%, как с собственным сайтом. Маршрутизация курьеров — на их стороне.
Методы: меню, заказы, статусы. Работает в 100+ городах, рестораны обычно возят сами. Подводный камень: в малых городах партнёрская поддержка медленнее, чем у федеральных платформ — закладывайте больше времени на выход на рабочий режим.
Каждую из них мы прошли на проектах федеральных сетей. Часть лечится архитектурой, часть — операционными правилами.
300+ реализованных проектов, 100 международных наград, №1 в мобильной разработке, 250 специалистов в команде. Интеграционный слой такого масштаба мы строили на проектах Burger King и KFC, а агрегатор знаем изнутри — делали Delivery Club.
Пользователей в приложении Burger King
Интеграционный слой на пиковой нагрузке
Ресторанов KFC автоматизировано
Распределённая сеть с несколькими каналами
В разработке приложений для крупного бизнеса
Штатных специалистов
Backend, интеграции, DevOps, QA
Пользователей в приложении Burger King
Интеграционный слой на пиковой нагрузке
Ресторанов KFC автоматизировано
Распределённая сеть с несколькими каналами
В разработке приложений для крупного бизнеса
Штатных специалистов
Backend, интеграции, DevOps, QA
Мы создаём foodtech-продукты для лидеров рынка — от стартапов до федеральных сетей. Несколько релевантных проектов из портфеля (полный — на странице foodtech-практики):
Channel manager окупается через две статьи: сэкономленное время сотрудников и уменьшение потерь от расхождений. Иллюстративный расчёт на сети из 30 точек, 4 агрегатора, 100 заказов через агрегаторы в день на точку.
Без channel manager: маркетолог обновляет каталог в четырёх кабинетах — 8–12 часов в неделю; кассиры вручную дублируют 5–15% заказов с планшетов в POS (ошибки и потери); расхождения остатков дают 3–7% отменённых заказов; сверка комиссий вручную — 2–4 дня финансиста в месяц.
С channel manager: каталог обновляется в одном месте (−6–10 часов в неделю), заказы летят в POS автоматически (0% дублирования), стоп-листы синхронны в реальном времени (отмен в разы меньше), сверка комиссий автоматическая (часы вместо дней).
На сети из 30 точек с месячной выручкой через агрегаторы 30–50 млн ₽: экономия операционных потерь и фонда оплаты — 300–700 тыс. ₽ в месяц, прирост выручки за счёт меньшего числа отмен и точного маркетинга — 2–5% агрегаторного канала, окупаемость разработки от 1,5 млн ₽ — 6–12 месяцев. Точные цифры под вашу сеть зависят от доли заказов в каналах, числа агрегаторов и уровня операционных потерь сейчас.
На сети из 30–100 точек с 4–5 агрегаторами финансовый блок становится отдельной болью: у каждого агрегатора своя модель комиссий, периодичность выплат, корректировки задним числом и возвраты. Без модуля сверки финансист живёт в Excel. Что делает модуль:
Этот модуль обычно выносят в отдельный сервис со своей базой данных и отчётностью, интегрируют с 1С или BI сети.
В iiko App Store есть готовые коннекторы для большинства агрегаторов — разумный путь для маленьких ресторанов и старта. Но у такого подхода есть пределы.
Для одиночного ресторана коннектор из App Store — очевидный выбор. Для сети с 30+ точками, нестандартными региональными агрегаторами или важностью финансового контроля кастом окупается и работает надёжнее.
1–2 недели. Аудит текущих интеграций, карта агрегаторов, карта пути заказа.
1–2 недели. Схема channel manager, выбор очередей, машина состояний, правила сопоставления.
4–6 недель. POS-адаптер и 2–3 первых адаптера агрегаторов.
2–3 недели. Сверка комиссий, дашборд по каналам.
3–4 недели. Запуск на 3–5 точках, проверка пиковой нагрузки.
4–8 недель. Подключение остальных агрегаторов и точек.
Команда: продакт (метрики каналов), системный аналитик (карта потоков и сопоставление моделей данных агрегаторов), 2–3 backend-разработчика и инженер интеграций, DevOps (очереди, наблюдаемость, инфраструктура), QA (контрактные и нагрузочные тесты на реальных API), при необходимости — финансовый аналитик для модуля сверки.
Что влияет на бюджет: число агрегаторов (каждый — отдельный адаптер и тестирование), глубина модуля сверки (базовая или с BI и дашбордами), число поддерживаемых POS (iiko, R-Keeper, Poster — все или одна), мультибренд для холдинга, уровень наблюдаемости. Для проверки гипотезы в узком сегменте — MVP foodtech.
