Для покупателя доставка выглядит просто: открыть каталог, положить товар в корзину и нажать кнопку. Но за этой кнопкой нет одного приложения. Есть несколько людей с разными задачами, а ещё оплата, каталог, карты и учётная система. Наша работа начинается с одного вопроса: что происходит с заказом после каждого нажатия и кто отвечает за следующий шаг.
1. Что на самом деле скрывается за кнопкой «Заказать»
Для первой рабочей версии нужны четыре роли. Их не обязательно выпускать четырьмя отдельными приложениями, но права и действия должны быть разделены с первого дня.
Покупатель
Видит каталог, итоговую цену, адрес, оплату и понятное состояние заказа.
Магазин
Принимает заказ, подтверждает наличие, готовит его и передаёт курьеру.
Курьер
Получает только свои доставки, маршрут, контакты и нужные кнопки статуса.
Администратор
Управляет магазинами, заказами, товарами, промокодами, платежами и спорными ситуациями.
Хороший MVP не пытается сразу повторить весь большой агрегатор. Он без ручной путаницы проводит один заказ от выбора товара до вручения и умеет честно пережить отмену, плохую сеть, отсутствие курьера и ошибку оплаты.
2. Homi: реальный проект доставки 13FOX для корейского рынка
Мы делали Homi как сервис класса крупных агрегаторов доставки. Внутри есть покупатель, магазин, курьер и веб-админка. Система рассчитана на несколько магазинов, а интерфейсы учитывают корейский рынок: адреса Сеула, номера с кодом +82, воны, банковские реквизиты и отдельное рабочее место магазина.
Это важнее красивой главной страницы. Заказ можно принять или отклонить, передать курьеру, провести по маршруту от магазина к клиенту, связать с оплатой и увидеть в общей панели. Настройка языка есть прямо в рабочих профилях. Точный список локализаций и цифры на тестовых экранах мы не выдаём за показатели запущенного бизнеса.
Реальный проект 13FOX
Одна панель для всей доставки
Администратор видит магазины, клиентов, курьеров, заказы, товары, промокоды, поддержку, уведомления, платежи и расчёты. Не нужно собирать картину из пяти таблиц и чатов.
Один заказ, разные роли
Покупатель выбирает, магазин решает, курьер везёт
Каждый человек видит только то, что нужно ему сейчас. При этом все работают с одним заказом и одинаково понимают его состояние.
3. Путь одного заказа: шесть шагов, которые нельзя перепутать
Допустим, покупатель выбрал блюдо и указал адрес. Дальше система не просто меняет подпись на экране. На каждом шаге конкретный человек принимает решение, а сервер проверяет, разрешено ли оно.
| Шаг | Кто действует | Что важно бизнесу |
|---|---|---|
| 1. Заказ создан | Покупатель | Адрес обслуживается, товар есть, итоговая цена не изменилась |
| 2. Заказ принят | Магазин | Точка действительно может собрать заказ |
| 3. Нужен курьер | Магазин или оператор | Заказ не теряется в общей очереди |
| 4. Курьер назначен | Оператор или правило | Исполнитель видит магазин, клиента и контакт |
| 5. Заказ в пути | Курьер | Покупатель и магазин видят тот же статус |
| 6. Заказ завершён | Курьер | Вручение, оплата и расчёты не расходятся |
Отмена идёт рядом с этим путём, но не одной кнопкой для всех. До приготовления покупатель может иметь одно право, после передачи курьеру другое. Возврат денег тоже не равен отмене заказа: это отдельное действие с собственным результатом.
4. Покупатель: сначала честное обещание, потом красивая корзина
Самая неприятная ошибка случается в конце: человек потратил время на выбор, а приложение только перед оплатой сообщает, что адрес вне зоны или половины товаров нет. Мы проверяем адрес, часы магазина и доступность как можно раньше.
- Каталог: поиск, категории, карточки, модификаторы и актуальное наличие.
- Цена: товары, скидка, доставка и полный итог до подтверждения.
- Адрес: карта плюс ручной ввод, подъезд, этаж и комментарий.
- После заказа: статус, связь, история и понятные правила отмены.
Представьте, что GPS поставил метку на соседний дом. Человек должен спокойно поправить адрес, а система заново проверить зону и стоимость. Без этого одна маленькая ошибка превращается в звонок оператору, лишний маршрут курьера и опоздание следующего заказа.
5. Магазин, курьер и администратор: три разных рабочих дня
Магазину важно быстро принять или отклонить заказ. Курьеру нужен маршрут и минимум кнопок. Администратор должен видеть исключения, а не читать весь поток подряд. Мы не объединяем эти задачи в один перегруженный кабинет только потому, что так быстрее нарисовать первый макет.
Магазин
Новые заказы, подтверждение, отмена, замена позиции, передача курьеру и профиль точки.
Курьер
Назначения, два адреса, маршрут, связь, способ оплаты и подтверждение вручения.
Администратор
Магазины, пользователи, каталог, промокоды, платежи, расчёты и спорные заказы.
Если связь пропала в лифте, нажатие курьера нельзя терять или отправлять дважды. Мы сохраняем действие на телефоне и повторяем отправку, когда сеть вернулась. Курьер видит понятный результат, а бизнес не получает два одинаковых события.
6. Сервер, 1С и другие системы: где хранится правда
Четыре интерфейса должны показывать один и тот же заказ. Поэтому цену нельзя считать отдельно в каждом телефоне, а оплату нельзя подтверждать по красивому экрану «Готово». Сервер проверяет права, хранит историю и связывает приложения с внешними системами.
| Что меняется | Где обычно хранится | Что проверяем |
|---|---|---|
| Товары, цены, остатки | 1С или другая учётная система | Коды, стоп-лист, частоту обновления и конфликт цены |
| Заказ и его статус | Сервер доставки | Единый номер, допустимые шаги и историю |
| Деньги | Платёжный сервис | Подтверждение, отмену, возврат и повтор запроса |
| Клиент и обращение | CRM | Согласие, связь с заказом и отсутствие дублей |
У нас есть отдельный опыт интеграций доставки с 1С. Мы начинаем не с большого документа, а с одного тестового заказа: получаем товар и цену, оформляем покупку, меняем статус, отменяем и сверяем результат по одному номеру. Homi показывает ширину системы доставки, но мы не приписываем этому проекту связь с 1С, которой нет на показанных материалах.
7. Malling: как опыт с amoCRM и Битрикс24 помогает проектам доставки
Для CRM у нас есть отдельный проект Malling. Мы сделали сервис коммуникационных кампаний, который интегрируется с amoCRM и Битрикс24. Данные о клиентах, сделках и истории остаются в CRM, а команда получает отдельное рабочее место для рассылок и выбранных групп клиентов.
В доставке этот опыт полезен, когда нужно связать заказ с обращением клиента, не потерять историю и не заставлять менеджера копировать данные руками. Мы не называем Malling продуктом доставки и не приписываем ему интеграцию с 1С. Он доказывает другую часть работы: мы умеем строить отдельный сервис поверх amoCRM и Битрикс24.
Проект 13FOX для CRM-коммуникаций
Кампании и клиенты в одном сервисе
Два экрана показывают рабочую часть Malling без рекламных процентов и выдуманных результатов.
8. Оплата и геолокация: две функции, где нельзя надеяться на авось
Еда и доставка являются физическими товарами и услугами. Для них используют внешний эквайринг, а не встроенную покупку цифрового контента Apple или Google. Приложение может показать успешный экран только после того, как сервер получил подтверждение платёжного сервиса. Отмена заказа и возврат денег остаются двумя разными действиями.
С геолокацией похожее правило: брать только то, что нужно сейчас. Покупателю достаточно выбрать адрес и видеть движение курьера. Курьерскому приложению фоновые координаты могут понадобиться во время активного маршрута. После вручения или окончания смены сбор нужно остановить.
- Повторный запрос не создаёт второй платёж или возврат.
- Способ оплаты проверяется для страны, валюты и юридического лица проекта.
- Курьер понимает, когда приложение передаёт геопозицию и зачем.
- Оператор видит время последнего обновления, если связь пропала.
9. Как мы проверяем заказ до того, как это сделает покупатель
Обычного сценария «выбрал, оплатил, получил» недостаточно. На пилоте мы специально создаём неудобные ситуации и смотрим, остаётся ли у каждого человека понятный следующий шаг.
Начинать лучше с одной зоны, ограниченного меню и понятного графика. Так команда может разобрать каждый сбой, исправить причину и только потом подключать новые магазины. Если сразу открыть весь город, ошибки продукта смешаются с ошибками процесса и станет непонятно, что чинить первым.
10. Какие цифры смотреть на пилоте
Универсальная цель вроде «доставлять за 30 минут» мало помогает: кухня, радиус, транспорт и трафик у всех разные. Мы сначала снимаем собственную исходную картину, а затем сравниваем одинаковые недели и одинаковые зоны. Для небольшого пилота достаточно шести показателей.
| Показатель | Какой вопрос он закрывает |
|---|---|
| Минуты до принятия | Магазин вообще видит новый заказ вовремя? |
| Минуты на сборку | Где возникает очередь: в продукте или на точке? |
| Ожидание курьера | Хватает ли исполнителей в выбранной зоне и часы? |
| Время в пути | Реалистичны ли радиус и обещание клиенту? |
| Отмены по причинам | Что ломается чаще: наличие, адрес, оплата или назначение? |
| Ручные правки на 100 заказов | Какая часть процесса всё ещё держится на звонках? |
Важно считать не только среднее. Один заказ, который ждал курьера час, легко спрячется среди быстрых. Поэтому мы отдельно смотрим самые долгие случаи и читаем их историю: кто нажал кнопку, где пропала сеть и какое решение увидел покупатель. Так цифра приводит к конкретной правке, а не просто попадает в отчёт.
11. От чего зависит цена разработки
Два проекта с одинаковым числом экранов могут отличаться по объёму в несколько раз. Главная работа часто находится между экранами: права ролей, правила отмены, многомагазинность, оплата, карты, плохая сеть, 1С, CRM, касса и публикация приложений.
Для первой оценки мы просим пять вещей:
- Один реальный заказ от выбора товара до вручения.
- Список ролей: покупатель, магазин, оператор, курьер, бухгалтерия.
- Меню, города, зоны, часы и правила стоимости доставки.
- Список систем: 1С, CRM, касса, эквайринг, карты и аналитика.
- Причины отмены и ситуации, которые сейчас решаются звонком или таблицей.
После этого можно честно отделить первую версию от следующих этапов. Общий подход к оценке мы подробнее разобрали в статье о стоимости мобильного приложения.
Самый полезный результат первой встречи не общая цифра, а список допущений рядом с ней. Например: один город, два типа оплаты, ручное назначение курьера и обмен только товарами и заказами. Если позже добавится автоматическое распределение, несколько стран или сложные расчёты с магазинами, будет видно, почему изменилась оценка и какая новая работа появилась.
12. Когда собственное приложение пока не нужно
Если у бизнеса одна точка, маленькое меню и несколько заказов в день, полноценная система может быть лишней. Иногда разумнее начать с мобильного сайта, готового сервиса или простого кабинета оператора. Собственная разработка становится полезной, когда типовой сервис мешает вашим правилам, интеграциям, нескольким магазинам или контролю клиентского опыта.
13. Что проверить перед релизом
Правила платформ меняются, поэтому перед публикацией мы заново открываем первичные страницы по оплате и геолокации. Для этой версии статьи они проверены 31 июля 2026 года.
- Правила проверки App Store: оплата физических товаров и правила доступа к данным.
- Правила платежей Google Play: доставка еды не относится к обязательной встроенной оплате.
- Правила геолокации Google Play: фоновый доступ должен быть частью основной функции.
- Обмен данными с 1С:Фреш: возможности чтения и записи зависят от конфигурации.
- ЮKassa: процесс платежа: серверные состояния и подтверждение результата.
FAQ
Что обязательно входит в MVP приложения доставки еды?
Минимум включает путь покупателя от каталога до статуса заказа, рабочее место магазина или оператора, приложение курьера и сервер, который не даёт четырём экранам спорить о состоянии заказа. До запуска отдельно проверяют отмену, неверный адрес, повторное нажатие, сбой оплаты и потерю сети.
Нужны ли отдельные приложения покупателю и курьеру?
Не всегда. Покупательское приложение обычно публикуют отдельно, а курьеру и магазину можно дать второе приложение или защищённый веб-кабинет. Главное, чтобы покупатель не видел служебные действия, а курьер получал только назначенные ему заказы.
Как связать приложение доставки с 1С?
Сначала определяют, какие данные приходят из 1С в приложение: товары, цены, остатки и стоп-лист. Затем фиксируют, что возвращается назад: заказ, оплата, отмена и статус. Точный обмен зависит от конфигурации 1С, поэтому его проверяют на тестовом заказе до оценки всей разработки.
Нужна ли фоновая геолокация?
Покупателю обычно достаточно выбрать адрес и видеть движение курьера. Постоянный доступ к его геопозиции не нужен. Курьерскому приложению фоновая геолокация может понадобиться только во время активного маршрута, с понятным объяснением и остановкой после доставки или смены.
Как принимать оплату и делать возвраты?
Для физической еды и доставки используют внешний эквайринг, а не встроенную покупку цифрового контента. Сервер ждёт подтверждение платёжного сервиса. Отмена заказа и возврат денег остаются разными действиями, а повторный запрос не должен списать сумму второй раз.
Сколько стоит и сколько времени занимает разработка?
Оценка зависит не от числа красивых экранов, а от ролей, правил заказа, количества магазинов, способов оплаты, карт и интеграций. Для первой оценки достаточно показать меню, одну зону доставки, путь реального заказа и список систем, с которыми нужно обмениваться данными.
Покажите нам один реальный заказ
Пришлите меню, зоны доставки, роли сотрудников и список систем, которые уже используются. На первой встрече мы пройдём путь заказа от корзины до вручения, найдём самые дорогие ошибки и скажем, какие приложения и интеграции действительно нужны в первой версии.
Вы получите понятную схему продукта и список вопросов для оценки. Большой заказ разработки для этого не требуется.