Уйти от агрегаторов и не упасть в чёрную пятницу: как мы построили приложение доставки «Смузи Go»

Контекст: комиссия агрегаторов и хрупкий мобильный сайт

Сервис доставки «Смузи Go» работал по двум каналам — через сторонние агрегаторы доставки, забиравшие 30% с каждого заказа, и через собственный сайт с низкой мобильной конверсией. Проблема была не только в деньгах, которые уходили агрегаторам с каждой продажи, — это фиксированная и предсказуемая издержка, с которой можно жить. Настоящей проблемой было отсутствие контроля: без собственного приложения у «Смузи Go» не было своей программы лояльности (без которой в фудтех-доставке конкурировать почти невозможно), не было прямого канала для push-уведомлений о статусе заказа, и не было устойчивости к пиковым нагрузкам — обеденное время и распродажи создавали резкие скачки трафика, которые старая инфраструктура не была спроектирована выдерживать.

Что сделали

Спроектировали и разработали собственное мобильное приложение для iOS и Android с прицелом на два конкретных сценария. Первый — скорость повторного заказа: для сегмента постоянных клиентов, который в доставке едой формирует основную выручку, добавили функцию «заказать как в прошлый раз» в два тапа — без повторного прохождения всей корзины. Второй — устойчивость под нагрузкой: разработали backend с очередью обработки заказов, спроектированной специально под резкие скачки, а не под равномерный средний трафик, плюс push-уведомления о статусе доставки в реальном времени.

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

Почему именно так: методология

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

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

Результат в цифрах

Через приложение сейчас проходит 54% всех заказов сервиса — то есть больше половины продаж уже не зависит от комиссии агрегаторов. Это дало примерно 19% экономии на комиссиях агрегаторов в месяц. В «чёрную пятницу» приложение выдержало 12-кратный скачок нагрузки без единого сбоя — именно тот сценарий, ради устойчивости к которому изначально проектировался backend. Retention на 30-й день составил 24% — заметно выше среднего по нише показателя в 12–15%, что подтверждает: функция быстрого повторного заказа реально работает на удержание, а не осталась просто удобной фичей на бумаге.

Вывод: что это значит для похожих задач

Для любого бизнеса, который сейчас зависит от маркетплейса или агрегатора, но при этом имеет узнаваемый бренд и постоянных клиентов, собственное приложение — это в первую очередь способ вернуть контроль над экономикой повторных продаж, а не просто более удобная витрина. Отдельный практический вывод для e-commerce и доставки: если у бизнеса есть предсказуемые пики нагрузки (распродажи, обеденное время, сезонность), архитектуру нужно закладывать под пик, а не под средний день — иначе самый прибыльный момент года становится и самым рискованным.