Доставка еды: свой сайт заказов против 30% комиссии агрегатору — точка окупаемости

MAATRIX

Вы открываете отчёт агрегатора за месяц, смотрите на строку «комиссия платформы» и понимаете, что она сопоставима с арендой помещения. С каждого заказа уходит 30% — не с прибыли, а с выручки, то есть фактически с того, что должно было пойти на еду, зарплату повару и вашу маржу. Вопрос закономерный: а если сделать свой сайт заказов, разве не станет дешевле? Ответ не «да» и не «нет» — это вопрос объёма. Ниже — не рекламная арифметика, а рабочая методика: как посчитать, при каком количестве заказов в месяц собственный сайт с сервером перестаёт быть дороже комиссии и начинает экономить деньги именно вашему заведению.

Почему агрегатор берёт 30% и куда уходят эти деньги

30% с заказа — цифра, которая на первый взгляд выглядит грабительской, но за ней стоит реальный набор услуг, за которые платформа действительно несёт расходы: показ вашего заведения в поиске и рекомендациях, приём и обработка платежа, часто — собственный курьерский парк или биржа курьеров, поддержка клиентов при проблемах с заказом, механизмы возвратов и споров, маркетинговые акции и скидки, которые агрегатор частично финансирует сам, чтобы удерживать аудиторию. Это не абстрактная плата за «использование приложения» — это готовая инфраструктура спроса, которую вам не пришлось строить самому.

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

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

Как процент агрегатора съедает маржу общепита

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

Когда с каждого такого заказа дополнительно уходит 30% выручки (а не маржи — процент берётся с полной суммы чека, а не с той небольшой части, что остаётся после себестоимости), для многих заведений заказ через агрегатор оказывается на грани рентабельности, если считать честно, с учётом упаковки и времени на сборку. Отсюда и знакомая практика: цены в приложении агрегатора выше, чем при прямом заказе, — это попытка компенсировать процент хотя бы частично.

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

Что нужно технически, чтобы запустить свой сайт заказов

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

• Витрина меню с фото и ценами — управляемая, чтобы вы сами меняли позиции и цены без разработчика на каждое изменение.
• Корзина и оформление заказа — с адресом, комментарием, выбором времени доставки или самовывоза.
• Приём онлайн-оплаты — интеграция с эквайрингом, чтобы клиент мог заплатить картой сразу на сайте, а не только наличными курьеру.
• Уведомление кухни о новом заказе — распечатка чека, звуковой сигнал на планшете на кухне или сообщение в отдельный Telegram-канал для линии — что-то, что заменяет «прилетел заказ» из приложения агрегатора.
• Логистика доставки — здесь два варианта: свои курьеры (штат или подряд) либо передача заказа стороннему курьерскому сервису по API или вручную. Если раньше доставку возил агрегатор, при переходе на свой сайт эту функцию нужно закрыть отдельно — и это отдельная статья расходов, которую нельзя забывать при расчёте.
• База клиентов и история заказов — то, чего вы вообще не видите, работая через агрегатора: кто заказывает, как часто, что берёт, и на этом можно строить свою программу лояльности и рассылки.

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

Методика расчёта точки окупаемости

Смысл точки окупаемости прост: найти объём заказов в месяц, при котором сумма, которую вы платите агрегатору в виде 30% комиссии с этого объёма, сравнивается с суммой, которую вы тратите на свой сайт и сервер. До этой точки выгоднее продолжать работать через агрегатора (или совмещать оба канала) — фиксированные затраты на свою инфраструктуру ещё не отбились. После неё — каждый дополнительный заказ, проведённый через свой сайт, а не через агрегатор, экономит вам деньги, потому что вы платите за инфраструктуру фиксированную сумму, а не растущий с оборотом процент.

Формула в базовом виде:

Точка окупаемости (заказов в месяц) =
    Фиксированные затраты на свой сайт в месяц
    ───────────────────────────────────────────
    Средний чек × 0.30

Где числитель — это сумма, которую вы платите за инфраструктуру своего сайта заказов независимо от того, сколько заказов через него прошло: аренда сервера, амортизация разработки (если сайт делался разово, разумно раскидать эту сумму на 12–24 месяца, а не считать всю сумму в первый месяц), регулярная поддержка и мелкие доработки, если они у вас на абонентской основе.

Знаменатель — это то, сколько вы теряете агрегатору с одного заказа при среднем чеке вашего заведения: 30% от чека. Именно это — «переменные потери», которые перестают начисляться, если заказ пришёл через ваш собственный сайт вместо приложения агрегатора.

Важные оговорки, без которых расчёт будет нечестным:

• Считайте только заказы, которые реально переключатся на свой сайт. Если часть аудитории физически привязана к агрегатору и никогда не перейдёт на прямой заказ, эти заказы в расчёт точки окупаемости включать нельзя — экономии по ним не будет.
• Учтите стоимость эквайринга на своём сайте. Приём онлайн-оплаты картой напрямую тоже не бесплатен — это отдельный процент, обычно заметно ниже 30%, но не ноль. Его нужно вычесть из экономии, а не забыть.
• Учтите логистику отдельно, если раньше её обеспечивал агрегатор. Если агрегатор возил заказы своими курьерами, а вы планируете возить их сами или через стороннюю службу, стоимость доставки на заказ — ещё одна переменная статья, которая частично съедает выгоду от ухода с агрегатора.
• Маркетинг и привлечение на свой сайт не бесплатны. Агрегатор приводит новых клиентов через поиск и рекомендации в приложении. Свой сайт такого потока сам по себе не создаёт — нужны собственные усилия: QR-код на упаковке, соцсети, рассылки по базе, возможно, минимальный бюджет на локальную рекламу.

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

Пример расчёта на условных цифрах

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

Допустим, заведение решает, что часть постоянных клиентов реально переключится на прямой заказ через сайт (это отдельная оценка, о ней ниже), средний чек по заведению — условно 900 рублей, а фиксированные затраты на свой сайт заказов — аренда сервера плюс амортизация разработки плюс небольшой абонемент на поддержку — условно составляют 30 000 рублей в месяц.

Теряемая агрегатору сумма с одного заказа при таком чеке: 900 × 0.30 = 270 рублей.

Точка окупаемости: 30 000 / 270 ≈ 111 заказов в месяц, то есть примерно 3,5–4 заказа в день, которые переходят с агрегатора на прямой сайт.

Теперь скорректируем на эквайринг своего сайта: если приём платы картой напрямую обходится условно в 2,5% от чека, это ещё около 22 рублей с заказа, которые нужно вычесть из «экономии» — фактическая выгода с одного заказа тогда не 270, а примерно 248 рублей, и точка окупаемости сдвигается немного выше — до примерно 121 заказа в месяц.

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

Стоит прогнать этот же расчёт и на прогнозе роста: если поток заказов растёт, точка окупаемости, которая сегодня кажется недостижимой, через полгода-год может оказаться пройденной — и вложение в свой сайт стоит делать заранее, под будущий объём, а не постфактум.

Подводные камни перехода на свой сайт

Экономика на бумаге редко совпадает с тем, что происходит в реальности, — вот на что стоит обратить внимание отдельно от голой формулы:

• Переходный период — двойные расходы. Резко отключиться от агрегатора рискованно: часть аудитории просто не узнает о переходе и потеряется. Реалистичный сценарий — какое-то время работать на двух каналах параллельно, платить и комиссию, и содержать свою инфраструктуру, — и только по мере роста доли прямых заказов сдвигать баланс. В первые месяцы совокупные расходы временно выше, чем «просто агрегатор» или «просто свой сайт» по отдельности.
• Привычка клиента открыть привычное приложение. Заказ через агрегатор часто не осознанный выбор конкретного заведения, а привычка открыть одно приложение и выбрать знакомое. Перевести такого клиента на отдельный сайт — отдельная маркетинговая задача, которая не решается фактом существования сайта.
• Отзывы и рейтинг остаются на агрегаторе. Накопленная репутация — оценки, история заказов — не переносится на новый канал. Новый сайт стартует без этого социального доказательства, и первое время конверсия на нём обычно ниже, чем в привычном приложении с рейтингом и сотнями отзывов.
• Поддержка сайта требует ответственного человека. Сайт с устаревшим меню, забытыми акциями и зависшим модулем оплаты теряет доверие сильнее, чем просто отсутствие сайта. Фиксированные затраты на поддержку в формуле выше — не формальность, а необходимость, если вы хотите, чтобы сайт реально работал.
• Отказоустойчивость — на вас. У агрегатора инфраструктуру обслуживает его собственная команда, и её надёжность не ваша забота. На своём сервере ответственность за то, что сайт не «лёг» в пятницу вечером в разгар заказов, лежит на вас или на подрядчике по поддержке — это стоит закладывать в требования к серверу заранее.
• Не всё нужно строить с нуля. Необязательно заказывать полностью кастомную разработку — готовые движки для приёма заказов общепита и связки с эквайрингом снижают стартовые затраты и ускоряют запуск, что напрямую снижает числитель в формуле точки окупаемости и делает переход выгодным при меньшем объёме заказов. Похожий принцип — простая панель приёма заказов на своём VPS вместо тяжёлого готового решения — разобран в статье про B2B-панель заказов пекарни: там задача та же по сути, только заказчики не частные клиенты, а кафе-партнёры.

Частые вопросы