Доставка съедает ресторан: когда агрегаторы больше вредят, чем помогают

Доставка начинает вредить ресторану не при «слишком высокой комиссии», а когда завершённый заказ не покрывает все переменные расходы канала и не оставляет нужного вклада. Проверять это нужно по своему договору, актам и заказам: универсальной ставки агрегатора не существует.

Если читать 30 секунд

• Не сравнивайте оборот доставки с оборотом зала. Считайте вклад одного завершённого заказа и всего канала.
• Берите фактическую стоимость услуг платформы из кабинета, договора и акта, а не процент из чужого кейса.
• Включите в расчёт еду, упаковку, промо за счёт ресторана, компенсации, переменный труд и потери из-за ошибок.
• Разделите доставку на позиции, время суток и способы получения: средняя цифра скрывает убыточные сегменты.
• Отключайте не канал целиком, а связку «позиция × период × механика промо», если именно она не проходит порог.

Главная цифра — вклад заказа, а не его чек

Управленческий P&L доставки удобно начинать с маржинального дохода, или вклада. Это деньги, которые остаются после переменных расходов и участвуют в покрытии аренды, постоянных окладов, оборудования и прибыли.

CM_delivery = P_gross − C_food − F_platform − C_pack − C_promo − C_refund − C_labor

Где:

• CM_delivery — вклад завершённого заказа, ₽/заказ;
• P_gross — сумма заказа по цене меню до скидки, оплачиваемой рестораном, ₽/заказ;
• C_food — себестоимость продуктов по фактически проданным позициям, ₽/заказ;
• F_platform — фактическая стоимость услуг платформы по условиям ресторана, ₽/заказ;
• C_pack — контейнеры, пакет, пломба, приборы и расходники, ₽/заказ;
• C_promo — часть скидки и продвижения, которую оплачивает ресторан, ₽/заказ;
• C_refund — компенсации, возвраты и списания, распределённые на завершённые заказы, ₽/заказ;
• C_labor — переменный труд на сборку и передачу, ₽/заказ.

В действующей оферте Яндекс Еды стоимость услуг определяется данными на странице партнёра и документами в личном кабинете. Оферта также относит коммерческие условия, включая стоимость услуг, к конфиденциальным. Поэтому «средняя комиссия по рынку» не годится для решения конкретного ресторана: в модель нужно подставить собственный акт за тот же период (оферта Яндекс Еды, действует с 15 июля 2026 года). Если отчёт уже показывает чистую выручку после промо ресторана, не вычитайте C_promo повторно.

Условный пример расчёта

Допустим, ресторан проверяет один завершённый заказ на 1 500 ₽. Продукты стоили 480 ₽, услуги платформы по фактическому отчёту — 360 ₽, упаковка — 85 ₽, промо за счёт ресторана — 120 ₽, резерв компенсаций — 45 ₽, переменная сборка — 70 ₽.

CM_delivery = 1 500 − 480 − 360 − 85 − 120 − 45 − 70 = 340 ₽/заказ
CM_rate = 340 / 1 500 × 100% = 22,7%

Это именно пример, а не ориентир для отрасли. Число 340 ₽ ещё не отвечает на вопрос «хорошо или плохо»: ресторан должен сравнить его со своим минимальным вкладом, ограничением кухни и альтернативой — заказом в зале или самовывозом.

Соберите P&L канала за одинаковый период

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

Сведите пять источников:

1. Выгрузку завершённых и отменённых заказов по позициям.
2. Акт и отчёт платформы с услугами, корректировками и промо.
3. Актуальные технологические карты и закупочные цены.
4. Выдачу упаковки или норматив комплекта на каждую позицию.
5. Журнал ошибок: недовложения, пересорт, протечки, жалобы и компенсации.

Затем посчитайте не только среднее, но и распределение:

Срез	Какой вопрос задаёт	Возможное решение
Позиция	Какое блюдо не выдерживает расходов канала?	новая цена, состав, упаковка или отключение
Час и день	Когда доставка перегружает кухню?	лимит, пауза, отдельное время приготовления
Промо	Какая механика покупает оборот слишком дорого?	изменить участие или ассортимент
Чек	Какие маленькие заказы не покрывают комплект и сборку?	наборы, допродажа, другой порог
Причина компенсации	Где проблема повторяется?	исправить карточку, сборку или упаковку

Чтобы разовые возвраты не исчезли из модели, рассчитайте резерв:

C_refund = (refunds + compensations + write_offs) / N_completed

Здесь числитель — ₽ за период, N_completed — число завершённых заказов, а результат — ₽/завершённый заказ. Если компенсацию полностью несёт платформа, не списывайте её на ресторан второй раз; сверяйте начисления с актом.

Установите порог до того, как увидите результат

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

• минимальный вклад, ₽/заказ;
• минимальную долю вклада, % от выручки;
• допустимое время сборки, минут/заказ;
• максимум компенсаций, ₽ на 100 заказов;
• предел опозданий по вине ресторана, заказов на 100.

Порог не обязан совпадать с залом. Доставка может загружать простаивающую кухню днём, но мешать дорогим посадкам вечером. Поэтому один и тот же вклад в 15:00 и 20:00 имеет разную ценность.

Для переговоров с площадкой полезно заранее вычислить два разных предела расходов на её услуги:

F_platform_max_zero = P_gross − C_food − C_pack − C_promo − C_refund − C_labor
F_platform_max_target = P_gross − C_food − C_pack − C_promo − C_refund − C_labor − CM_target

F_platform_max_zero — максимум ₽/заказ при нулевом вкладе: канал лишь покрывает перечисленные переменные расходы. F_platform_max_target — максимум ₽/заказ при требуемом вкладе CM_target. Для управленческого решения используйте второй предел; первый показывает только границу прямого минуса. Если фактический F_platform выше выбранного предела, заказ не проходит соответствующий сценарий break-even.

Полезно посчитать чувствительность к одному фактору:

CM_after = CM_delivery − Δcost

Если упаковка подорожает на 15 ₽/заказ, то Δcost = 15 ₽/заказ. Если участие в промо добавляет 90 ₽ расходов, подставьте 90. Не меняйте одновременно комиссию, цену и себестоимость — иначе не увидите источник риска.

Красные флаги: когда канал действительно ест ресторан

Канал требует вмешательства, если повторяются несколько признаков:

• положительный общий вклад держится на двух хитах, а остальной ассортимент в минусе;
• промо увеличивает заказы, но снижает суммарный вклад смены;
• в пик доставка вытесняет более выгодные заказы зала;
• упаковка и компенсации не разнесены по позициям и выглядят «мелочами»;
• акт платформы не сверяется с внутренней выгрузкой;
• стоп-лист обновляется поздно, поэтому команда заменяет или отменяет заказы;
• меню обещает то, что кухня или упаковка стабильно не сохраняют.

Актуальные стандарты Яндекс Еды требуют корректной упаковки, поддержания информации об ассортименте и доступности и точной комплектации заказа. Это не доказывает размер финансового ущерба, но показывает, какие процессы ресторан обязан контролировать в канале (стандарты для партнёров, с 15 июля 2026 года). Ошибки комплектации стоит разбирать отдельно — по протоколу из статьи «Ошибки в заказах: сколько они стоят и как их снизить».

Не выключайте доставку одним движением

Сначала применяйте самое узкое изменение:

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

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

Эксперимент на 14 дней: одна связка, одна гипотеза

Выберите один сегмент, например горячие закуски в будни после 18:00. Зафиксируйте семь дней базы, затем внесите одно изменение на следующие семь дней: отключите промо, замените комплект упаковки или уберите одну позицию.

Сравнивайте:

• завершённые заказы, шт.;
• выручку, ₽;
• суммарный вклад, ₽;
• вклад, ₽/заказ;
• компенсации, ₽/100 заказов;
• время сборки, минут/заказ;
• задержки зала в то же окно.

Если заказов стало меньше, а суммарный вклад вырос и кухня стабилизировалась, это не провал. Цель P&L — не максимальный поток, а управляемый денежный результат.

Решение на одной странице

В конце месяца у владельца должен остаться не массив выгрузок, а короткий протокол:

Сегмент	Вклад, ₽/заказ	Суммарный вклад, ₽	Операционный риск	Решение
Хиты без промо	факт	факт	низкий/средний/высокий	оставить
Позиции с промо	факт	факт	низкий/средний/высокий	изменить
Пиковое окно	факт	факт	низкий/средний/высокий	ограничить

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

Финальный принцип: канал обязан покупать не оборот, а вклад

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

Чтобы увидеть, насколько понятно гостю собирать заказ без интерфейса агрегатора, откройте демо цифрового меню: там можно проверить категории, карточки, добавление блюд в корзину и оформление заказа. Договоры, комиссии, P&L и доставочную логистику демо не рассчитывает.

Обсудить подключение собственного меню и сценарий заказа.