Интеграция ресторана с агрегаторами: Яндекс Еда, Купер и свой канал

Заведение может принимать заказы агрегаторов двумя способами: переписывать их руками с планшета в кассу или настроить обмен данными между системами. От выбора зависит, сколько времени уходит у персонала в час пик, как часто гость получает отмену из-за закончившейся позиции и видит ли управляющий выручку доставки в общем отчёте. Дальше — что именно синхронизируется, какие есть способы подключения, где чаще всего ломается и сколько стоит привести оба канала в порядок.

16 сентября 2026 Технологии 14 мин чтения

---

Что такое интеграция ресторана с агрегатором

Агрегатор доставки — это витрина, приём заказа и курьеры. Гость выбирает блюдо в приложении сервиса, платит там же, а заведение получает заказ и готовит его. Интеграция — это автоматический обмен данными между системами агрегатора и учётной системой ресторана, чтобы ни одну из этих операций не приходилось выполнять вручную.

Из чего состоит обмен данными

Обмен идёт в двух направлениях. Вверх, от заведения к агрегатору, уходят состав меню, цены, модификаторы, фотографии, график работы точки и стоп-листы. Вниз, от агрегатора к заведению, приходят заказы, их состав, комментарии гостя и запросы на отмену. Обратно наверх возвращаются статусы: заказ принят, готовится, готов к выдаче курьеру.

Если интеграции нет, эту работу делает человек. Заведение получает от сервиса планшет, на нём отображается входящий заказ, и сотрудник переписывает позиции в кассовую систему руками. При одном-двух заказах в час это незаметно. При трёх подключённых агрегаторах и пиковой нагрузке в обеденное время у кассы появляется отдельная зона из планшетов, а каждый перенос заказа — это возможная ошибка в модификаторе или в количестве.

По смыслу это та же задача, что и интеграция приложения с iiko, r_keeper и Poster, только внешний канал здесь не свой, а чужой, и правила обмена задаёт площадка.

Зачем она заведению: что меняется в работе

Интеграция не увеличивает поток заказов сама по себе — трафик даёт витрина агрегатора и его реклама. Она меняет то, что происходит с заказом после нажатия кнопки «Оформить». Пять эффектов, которые видно в операционной работе.

1. Заказ попадает на кухню без повторного ввода. Состав, модификаторы, комментарий гостя и время приготовления приходят в кассовую систему в том виде, в каком их оформил гость. Ручной перенос — источник ошибок в составе и в количестве порций.
2. Стоп-лист обновляется без участия персонала. Закончившаяся позиция уходит с витрины агрегатора автоматически. Иначе гость заказывает то, чего нет, а заведение оформляет отмену или замену — и то и другое ухудшает его оценку сервиса.
3. Меню и цены правятся в одном месте. Управляющий меняет карточку в учётной системе, и изменение расходится по всем подключённым каналам. Без этого правку повторяют в каждом личном кабинете отдельно, и рано или поздно один из них отстаёт.
4. Выручка доставки видна в общем отчёте. Заказы агрегаторов попадают в ту же учётную систему, что и заказы в зале. Управляющий сравнивает каналы в одной таблице, а не сводит выгрузки из нескольких личных кабинетов.
5. Персонал освобождается от планшетов. Время, которое кассир тратил на перенос заказов, возвращается в обслуживание гостей в зале.

Чего агрегатор заведению не даёт

Важно назвать и обратную сторону. Агрегатор берёт на себя витрину, оплату и логистику, но контакт с гостем остаётся у площадки: заведение не знает его номер телефона, не может отправить ему push-уведомление и не строит на нём программу лояльности. Комиссия площадки и правила её начисления фиксируются в партнёрском договоре. Поэтому интеграция с агрегаторами и собственное приложение ресторана закрывают разные задачи — подробнее это разобрано в материале своё приложение для доставки еды или агрегатор.

Три способа подключиться к агрегатору

Заведение выбирает не между «есть интеграция» и «нет интеграции», а между тремя способами обмена данными. Они отличаются тем, кто отвечает за обмен и насколько его можно настроить под себя.

Когда типового модуля перестаёт хватать

Штатный модуль закрывает большинство задач одиночного заведения и стоит дешевле разработки — это честный аргумент в его пользу. Прямая интеграция нужна там, где типовой обмен упирается в ограничение: у сети разные цены в зале и в доставке, у точек разные юрлица и разные графики, а часть позиций собирается конструктором и не укладывается в простой список модификаторов. Такие сценарии описаны на странице подключения приложения к iiko.

Что синхронизируется между агрегатором и кассой

Интеграция — это не один обмен, а несколько независимых потоков данных с разной частотой. Каждый из них ломается по-своему, поэтому их удобно разбирать по отдельности.

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

Стоп-листы: как выбрать интервал обновления

Частота обмена стоп-листами — это компромисс между нагрузкой на учётную систему и риском продать то, чего нет. В нашем проекте для сети кофеен One Price Coffee, а это более 350 точек, стоп-листы обновляются каждые 15 минут по всем организациям сети, а каталог синхронизируется инкрементально — приложение забирает только изменившиеся позиции, а не весь список. Та же логика работает и для внешних каналов.

Модификаторы и матрица цен

Одна и та же добавка может стоить по-разному в зависимости от объёма порции. Если эта матрица не переносится в агрегатор целиком, сумма в приложении сервиса разойдётся с суммой на кассе, а расхождение придётся разбирать вручную по каждому заказу.

Путь заказа: от витрины агрегатора до кухни

Чтобы понять, где интеграция экономит время, полезно разложить один заказ по шагам. Ниже — маршрут при настроенном обмене данными.

1. Гость открывает карточку заведения в приложении сервиса. Он видит меню, которое пришло из учётной системы ресторана, без позиций из стоп-листа.
2. Гость собирает заказ и платит. Оплата проходит на стороне площадки, по её правилам.
3. Заказ уходит в кассовую систему заведения. Состав, модификаторы, комментарий и адрес доставки приходят готовым документом.
4. Заведение подтверждает заказ и называет время приготовления. Статус возвращается в сервис, гость видит его в своём приложении.
5. Заказ печатается на кухне. Позиции расходятся по цехам по тем же правилам, что и заказы из зала.
6. Заведение отмечает готовность. Сервис направляет курьера, ориентируясь на этот статус, — поэтому от его точности зависит, будет ли курьер ждать заказ или заказ курьера.
7. Заказ закрывается. Выручка попадает в отчёты учётной системы вместе с заказами зала и доставки в своём канале.

Без интеграции шаги 3, 4 и 6 выполняет сотрудник у планшета. В спокойное время это минуты, в пик — очередь из непринятых заказов и расхождение между тем, что видит гость, и тем, что происходит на кухне.

Яндекс Еда и Купер: что учесть в каждом сервисе

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

С технической стороны разница для заведения меньше, чем кажется: в обоих случаях нужно передать меню, держать актуальными стоп-листы и принимать заказы. Разница — в форматах данных, в требованиях к карточкам блюд и в том, какие поля площадка считает обязательными. Поэтому меню, которое отлично выглядит в одном сервисе, во втором часто приходится дополнять: другими размерами фотографий, отдельными описаниями, иной группировкой категорий.

Что меняется для сети из нескольких точек

У каждой точки сети свой набор данных — адрес, график, зона доставки, ассортимент и нередко своё юрлицо. Мы столкнулись с этим в проекте One Price Coffee — федеральной сети из более чем 350 кофеен, где точки принадлежат разным франчайзи: реквизиты, налогообложение и доступы к лояльности пришлось хранить по каждой кофейне отдельно. Для внешних каналов действует то же правило — подключение сети это не одна настройка, а столько настроек, сколько точек.

Типичные ошибки интеграции

Семь ошибок, которые чаще всего всплывают уже после запуска, когда заказы идут потоком.

• Позиции не сопоставлены между системами. Блюдо в кассе и блюдо на витрине связываются по внутреннему коду. Если сопоставление сделано по названию, любая правка названия рвёт связь, и заказ приходит с неопознанной позицией.
• Стоп-лист обновляется слишком редко. Обмен раз в час означает, что до часа гости могут заказывать то, чего на кухне уже нет.
• Цены доставки не отделены от цен зала. Если в доставке действует отдельный прайс, а обмен переносит цены зала, расхождение придётся править вручную в каждом канале.
• Часовой пояс точки берётся из настроек сервера. Для сети в нескольких регионах это приводит к заказам вне графика работы точки. В проектах мы берём часовой пояс из настроек терминальной группы конкретной точки, а не из общих настроек.
• Не отслеживается состояние кассовой смены. Заказ приходит на закрытую кассу и повисает. Решение — мониторинг смен и скрытие точки из выдачи, когда смена не открыта.
• Статусы проставляются задним числом. Если готовность отмечают не в момент готовности, а пачкой в конце часа, курьерская логистика сервиса работает по неверным данным.
• Нет разбора расхождений. Суммы заказов в кабинете площадки и в учётной системе сверяются вручную и нерегулярно, поэтому ошибки в матрице модификаторов находят через недели. Регулярную сверку стоит закладывать в процесс с первого дня.

Если интеграция уже работает, но ведёт себя непредсказуемо, начать стоит с разбора того, что происходит между системами, — это задача аудита кода, а если вопросы к самому интерфейсу заказа, то аудита UX/UI.

Метрики: как измерить эффект

Интеграцию оценивают не ощущением «стало удобнее», а несколькими показателями, которые можно снять до работ и через месяц после. Значения у каждого заведения свои — важна динамика, а не абсолютная цифра.

С какой метрики начинать

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

Чек-лист внедрения

Двенадцать пунктов, которые стоит пройти до того, как канал откроется для гостей.

1. Заключён партнёрский договор, заведение заведено в кабинете площадки.
2. Выбран способ обмена: планшет, штатный модуль кассы или прямая интеграция.
3. Номенклатура выгружена и сопоставлена по внутренним кодам, а не по названиям.
4. Перенесены модификаторы и матрица цен, включая зависимость цены добавки от размера порции.
5. Для доставки настроен отдельный прайс, если он отличается от прайса зала.
6. Фотографии и описания блюд приведены к требованиям площадки.
7. Настроен обмен стоп-листами и выбран интервал обновления.
8. Указаны график работы, зона доставки и время приготовления по каждой точке.
9. Часовой пояс берётся из настроек конкретной точки, а не из общих настроек сервера.
10. Настроен мониторинг кассовых смен и автоматическое скрытие точки при закрытой смене.
11. Проверены сценарии отмены и возврата с обеих сторон.
12. Назначен ответственный за еженедельную сверку сумм и разбор расхождений.

Для сети к этому добавляется тринадцатый пункт: отчёт о готовности по каждой точке — где заполнены реквизиты, где открыты смены, где активны терминалы. В проекте One Price Coffee, где сеть насчитывает более 350 точек, управляющая компания получает такой отчёт перед запуском, и это снимает основную часть проблем первой недели.

Агрегаторы и свой канал: как собрать оба

Разумная конфигурация для заведения с доставкой — оба канала одновременно, с разными ролями. Агрегаторы приводят новых гостей и закрывают логистику. Свой сайт и приложение работают с теми, кто уже пришёл: там живут программа лояльности, предзаказ, бронирование столов и прямая связь с гостем.

Технически они опираются на один и тот же фундамент — учётную систему заведения. Меню, цены, модификаторы и стоп-листы должны быть едиными для всех каналов, иначе гость увидит разные цены в приложении сервиса и в приложении бренда. Поэтому порядок работ обычно такой: сначала приводится в порядок номенклатура в кассе, затем настраивается обмен с внешними каналами, и только после этого собирается собственный канал продаж.

На чём собирается свой канал

Для собственного канала мы используем модульную Flutter-платформу FITTIN: каталог, корзина, оплата, программа лояльности, push-уведомления и интеграции с учётными системами — готовые модули, которые настраиваются под бренд, а уникальные сценарии дописываются на исходном коде. Из одной кодовой базы выходят приложения для App Store, Google Play и RuStore, а при необходимости и сайт — как устроен сам фреймворк, разобрано в материале что такое Flutter.

Сколько стоит свой канал

Модель оплаты состоит из трёх частей. Первое — единоразовая интеграция платформы под бренд, до 30 рабочих дней. Второе — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности; для базового сопровождения своя команда разработки не требуется. Третье — новый функционал и доработки оплачиваются отдельно, по модели Time & Materials, с оценкой в часах и сметой до старта задачи. Актуальные суммы по каждому пакету — на странице тарифов, ориентир под свой сценарий можно посчитать на калькуляторе.

Отдельная работа по внешним каналам — настройка обмена с площадками — оценивается по объёму: сколько сервисов подключается, сколько точек, насколько меню отличается от типового. Такие задачи идут по Time & Materials, со сметой перед стартом. Профильные страницы: приложения для доставки еды, приложения для кофеен и сетей кофеен, интеграция приложения с CRM.

Кейсы: «Сыроварня» и One Price Coffee

Два проекта FITTIN в сегменте HoReCa, где собственный канал строился поверх учётной системы заведения. Данные — со страниц кейсов.

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

Итог: интеграция с агрегаторами на одной странице

Сводка, по которой можно быстро спланировать работу.

Материалы по теме:

• Каналы: своё приложение или агрегатор доставки еды, как устроен сайт-агрегатор.
• Интеграции: интеграция приложения с iiko, r_keeper и Poster, ERP-интеграция.
• Бюджеты: приложение для ресторана, приложение для кафе и кофейни, приложение для доставки еды.

Что делать дальше:

• Зафиксировать сценарии доставки и ограничения кассы — разработка технического задания; проверить, что уже работает, — аудит кода.
• Посчитать бюджет своего канала — калькулятор стоимости и тарифы.
• Обсудить проект — приложения для ресторанов и кафе, контакты или форма ниже.

Часто задаваемые вопросы

Можно ли работать с агрегатором без интеграции, только на планшете?

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

Сколько времени занимает подключение к агрегатору?

Срок складывается из двух частей, и они идут параллельно. Первая — на стороне площадки: заявка партнёра, проверка документов, подписание договора и заведение карточки. Сроки здесь устанавливает сам сервис. Вторая — на стороне заведения: выгрузка и сопоставление меню, настройка модификаторов, стоп-листов, зон и графика. Если меню типовое и используется штатный модуль кассовой системы, вторая часть занимает дни. Для сети с разными юрлицами и отдельным прайсом доставки — больше, и срок оценивается по объёму.

Заказы агрегатора будут видны в моей кассовой системе?

При настроенной интеграции — да. Заказ приходит в учётную систему готовым документом, печатается на кухне по обычным правилам и попадает в отчёты вместе с заказами зала. Это и есть главный практический смысл интеграции: управляющий видит все каналы в одной системе, а не сводит выгрузки из нескольких личных кабинетов. Без интеграции заказ появится в кассе только после того, как его перенесёт сотрудник.

Как часто нужно обновлять стоп-листы?

Интервал подбирается под скорость, с которой у заведения заканчиваются позиции. Для сети кофеен в нашем проекте это 15 минут по всем организациям сети — при таком темпе гость почти не успевает заказать закончившийся напиток. Для ресторана с широким меню и большими остатками интервал может быть больше. Ориентир простой: если в отмены по причине стоп-листа уходит заметная доля заказов, интервал стоит сократить.

Можно ли поставить в доставке цены выше, чем в зале?

Технически да — для доставки настраивается отдельный прайс, и обмен переносит в канал именно его. Это распространённая практика, потому что в цену доставки закладывается комиссия площадки и упаковка. Важно, чтобы отдельный прайс был заведён именно в учётной системе, а не правился руками в кабинете сервиса: иначе при следующей выгрузке меню цены перезапишутся ценами зала. Коммерческая сторона вопроса — условия партнёрского договора с площадкой.

Нужно ли своё приложение, если заказы уже идут через агрегаторы?

Это зависит от доли повторных заказов. Агрегатор приводит нового гостя и закрывает логистику, но контакт остаётся у площадки: заведение не знает телефон гостя, не отправляет ему push-уведомление и не строит на нём программу лояльности, а комиссия платится с каждого заказа, включая повторные. Если гость возвращается регулярно, свой канал начинает окупаться. Если заказы разовые и поток небольшой, разумнее сначала выжать максимум из агрегаторов.

Что нужно от заведения, чтобы начать работу по интеграции?

Четыре вещи. Доступы партнёра в кабинеты подключённых сервисов. Доступ к учётной системе и понимание её версии. Актуальная номенклатура с модификаторами и ценами — включая отдельный прайс доставки, если он есть. И список точек с графиками, зонами доставки и, для сети, с реквизитами по каждому юрлицу. С этими данными объём работ оценивается по часам, а состав задач фиксируется в смете до старта.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Условия партнёрства, состав функций кабинетов и требования к данным сервисы доставки устанавливают самостоятельно и могут менять — актуальные условия приведены на их официальных сайтах. «Яндекс Еда», «Купер», iiko, r_keeper и Poster — товарные знаки правообладателей; упоминаются для описания каналов продаж и систем автоматизации.