Мобильная разработка
27 августа 2026
Один статус «готовится» запускает цепочку потерь: где ломается экономика приложения доставки
Клиент оформляет ужин, видит обещание «доставим за 35 минут» и через час всё ещё смотрит на статус «готовится». Для бизнеса такой заказ создаёт возврат, обращение в поддержку, компенсационный промокод и риск потерять следующую покупку.
Мы разрабатываем мобильные продукты и e-commerce-системы. Экономику доставки нужно считать по всей цепочке: меню, кухня, оплата, курьер, поддержка и повторные покупки. От состава MVP зависят стартовый бюджет и переменные потери после запуска.
Разберём, какие решения раздувают постоянные расходы, где появляются переменные потери на каждом заказе и как проверить гипотезу до разработки большого контура.
В смете одно приложение, в работе — четыре продукта
Покупатель видит каталог, корзину, оплату, карту и статусы. Команде проекта приходится собрать ещё три рабочих места.
Заведению нужен интерфейс, где сотрудник принимает заказ, сверяет стоп-лист, меняет время приготовления и подтверждает готовность. Курьеру — адрес, маршрут, связь с получателем и понятный порядок действий при проблеме. Администратору и поддержке — управление точками, меню, зонами, промокодами, возвратами и спорными заказами.
Все четыре продукта опираются на общий серверный контур — по сути, на e-commerce-систему с каталогом, корзиной, оплатой, заказами и интеграциями. Этот контур хранит актуальную цену, фиксирует оплату, не создаёт второй заказ после повторного нажатия кнопки и проводит заявку по статусам. Здесь полезен идемпотентный запрос: повторная команда с тем же ключом не дублирует оплату или заказ. Термин звучит так, будто его придумали для собеседования, но защищает он вполне понятные деньги.
Первый перекос появляется, когда оценка охватывает приложение покупателя, а операционные интерфейсы записаны одной строкой «админка». Чем короче эта строка в смете, тем чаще после запуска заказ приходится спасать звонками и сообщениями.
Маржа заканчивается раньше, чем едет курьер
У цифрового контура есть постоянные расходы: разработка, инфраструктура, мониторинг, обновления iOS и Android, поддержка интеграций. У каждого заказа возникают переменные: эквайринг, упаковка, скидка, последняя миля, компенсация за ошибку и время поддержки.
Для первого расчёта хватает простой модели:
вклад одного дополнительного заказа = выручка минус себестоимость блюда, упаковка, платёжные расходы, скидка, доставка и ожидаемые потери на сбоях.
Свежий пример — «Додо Пицца» вернулась к выбору платформы для расчётов с самозанятыми курьерами. По тендерной документации, которую изучил CNews, через неё планируют проводить 378 млн рублей и почти 1,7 млн транзакций в месяц. Целевая комиссия — до 0,5%; в контур входят документы и интеграции с 1С и ФНС. Предыдущую попытку внедрения отложили в том числе из-за масштаба изменений в «Додо ИС»: они затрагивали много компонентов и могли занять до года. Ещё одно ограничение касалось использования формы курьера как маркетингового элемента.
При заявленном объёме выплат курьерам одна десятая процентного пункта комиссии стоит около 378 тысяч рублей в месяц. Так строка «расчёты с курьерами» превращается в отдельную статью экономики продукта.
Ожидаемые потери считают через частоту проблемы. Например, стоимость одного опоздавшего заказа умножают на долю таких случаев. В стоимость входят возврат, промокод, повторная поездка курьера и время сотрудника, который разбирает обращение. Если данных пока нет, это отдельная причина начать с ограниченного пилота и собрать их.
Маржа заканчивается раньше, чем едет курьер, когда продукт привлекает заказ скидкой, а кухня и логистика обрабатывают его дороже, чем предполагала модель. Рост числа установок в такой ситуации ускоряет проблему. Получается бодрый график, который лучше не показывать финансовому директору без второй оси.
Карта обещает 35 минут, кухня работает по другой карте
Время на экране складывается из нескольких отрезков: заведение принимает заказ, кухня готовит его, курьер добирается до точки, ждёт выдачу и едет к клиенту. Приложение должно оценивать всю цепочку, учитывать загрузку кухни, зону доставки и доступных исполнителей.
Если система показывает одно фиксированное время, обещание быстро расходится с реальностью. Пятничный вечер, большой заказ и курьер на другом конце района выглядят для таймера одинаково. Для клиента разница обнаруживается уже после оплаты.
Статусы связывают операционную работу с обещанием на экране. Для каждого перехода заранее определяют владельца и допустимое время: кто принимает заказ, когда кухня может увеличить срок, что происходит при недоступной позиции, кто назначает курьера, после какого порога подключается поддержка. Такая статусная модель помогает увидеть задержку до того, как её сформулирует клиент в отзыве.
Тот же принцип действует для меню. Если стоп-лист обновляется с опозданием, приложение продаёт блюдо, которого уже нет. После этого система возвращает деньги и предлагает замену. Бизнес оплачивает лишнюю операцию, а гость выбирает ужин дважды.
Пилот должен проехать один денежный маршрут
Первая версия проверяет прохождение заказа от оплаты до вручения. На старте задают одну зону, короткое меню, несколько точек, один способ оплаты и понятную схему назначения курьеров. Ограничения делают данные сравнимыми: видно, где теряется время и сколько стоит каждый сбой.
Если бизнес проверяет предзаказ и повторные покупки, первую версию можно начать с самовывоза. Если в центре гипотезы доставка, в неё входят реальные адреса, назначение курьера, ожидание у точки, отмены и повторные попытки. Иначе цифры покажут экономику другого продукта.
У каждой функции в первом релизе должна быть работа: сократить время, уменьшить число ошибок или увеличить вклад заказа. Программа лояльности, рекомендации, чаевые, подписка и десяток способов оплаты могут подождать, пока основной маршрут не проходит без ежедневного спасения в чатах.
Пропущенный заказ дороже отдельного рабочего интерфейса
Рабочее место заведения и диспетчера влияет на маржу напрямую. Если сотрудник должен заметить новый заказ во вкладке браузера, он может пропустить обновление или звук. Курьер приедет раньше готовности, клиент получит опоздание, а поддержка — обращение. Экономия на отдельном интерфейсе быстро оборачивается возвратами и компенсациями.
Для критических событий задают подтверждение получения, повторную отправку и эскалацию. Заказ не должен молча переходить дальше, пока кухня или диспетчер не взяли его в работу. После заданного таймаута система дублирует сигнал или подключает менеджера. Такой механизм стоит дороже обычного уведомления, но дешевле цепочки «опоздание — возврат — промокод — поддержка».
То же касается курьера: адрес, телефон, маршрут и следующий статус должны оставаться доступны при нестабильной связи. Сбой сети для курьера — штатная ситуация. Поэтому локальный кэш, очередь синхронизации и журнал событий входят в рабочий контур, если без них заказ нельзя завершить.
Пять чисел нужно получить до первого макета
До первого макета нужны пять чисел:
Вклад одного дополнительного заказа — ₽. Выручка минус себестоимость блюда, упаковка, платёжные расходы, скидка и доставка. Отдельно учтите каннибализацию: часть заказов может переехать в приложение из другого канала. Вклад создают новые и более частые покупки, а также снижение операционных потерь.
Плотность спроса — заказов на зону в час. Общая аудитория города почти ничего не говорит о том, сколько курьер успеет доставить за вечер.
Стоимость неуспешного заказа — ₽. Возврат, компенсация, повторная доставка и время поддержки. Сумму разделяют по причинам: кухня, платёж, адрес, курьер, интерфейс.
Доля повторных заказов — %. Собственный канал окупается быстрее, когда люди возвращаются. Для разовой покупки установка приложения добавляет дорогой шаг перед корзиной.
Постоянная стоимость цифрового контура — ₽ в месяц. Серверы, мониторинг, поддержка, публикация обновлений, аналитика и команда, которая принимает решения после релиза.
Порог окупаемости = ежемесячные постоянные расходы / вклад одного дополнительного заказа. Пилот заменяет допущения фактическими значениями этих пяти показателей.
Своя доставка сходится, когда считается весь заказ
Перед разработкой мы раскладываем путь от выбора блюда до завершения заказа и отмечаем четыре вещи: кто отвечает за каждый статус, где меняются деньги, какие сбои требуют вмешательства и какую метрику получит команда. После этого становится виден состав первого релиза.
Результат этого разбора — карта статусов, список аварийных сценариев и набор метрик для пилота. По ним видно, какие интерфейсы входят в первый релиз, а какие функции можно отложить без ущерба для проверки.
Практический критерий простой: собственное приложение оправдано, когда бизнес контролирует предложение, операционные процессы и повторный спрос, а вклад заказа покрывает развитие цифрового контура. При слабой плотности заказов или неустойчивой кухонной операции приложение добавляет ещё одно место, где процесс может разойтись.
Если вы планируете собственный канал доставки или предзаказа, мы можем разложить его на клиентский, операционный и логистический контуры, собрать состав MVP и проверить экономические допущения до полной разработки. Подробнее — на странице разработки мобильных приложений.
