Разработка мобильного приложения для курьерской службы (курьер)

Мобильное приложение курьера: где ломается доставка

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

Отдельная история — работа без связи. Подземный паркинг, лифтовая шахта, склад из металлических панелей: приложение теряет сеть вместе с открытой заявкой. Курьер не может подтвердить вручение, статус остаётся прежним, заказ висит «в пути», а клиент звонит в поддержку. Без хранения состояния на устройстве и отправки его при восстановлении сети теряется не отметка, а сам факт доставки.

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

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

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

Измеримый эффект: время смены и точность адреса

Метрики фиксируем до старта, иначе эффект нечем подтвердить. Базовая линия снимается на текущем контуре за две-три недели: по каждой смене считаем время смены курьера — от первого перехода в статус «на смене» до закрытия последнего заказа, с вычетом простоев по вине склада. Тот же интервал потом сравниваем один в один.

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

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

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

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

Варианты доставки заказов на устройство курьера

Выбор определяется тем, насколько сильно ваш процесс доставки отличается от типового и как быстро курьеры должны получить заказы в поле. Ниже — четыре варианта, между которыми реально выбирают: они отличаются не «качеством», а тем, какую часть работы берут на себя и что оставляют вам.

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

Этапы проекта: аудит, схема, сборка, проверка, передача

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

1. Аудит процессов доставки. Выезжаем с курьерами, фиксируем приём наряда, связь с диспетчером, подтверждение вручения, возврат и передачу смены. Отдельно проверяем покрытие сети, старые устройства и работу в перчатках — от этого зависит, какие действия вообще можно вешать на экран.
2. Схема маршрутов и статусов. Описываем состояния заказа и допустимые переходы между ними, правила сборки точек в маршрут, поведение при отказе, переносе доставки и повторном вручении. Схема согласуется со службой до начала сборки, чтобы логика диспетчера и приложения не расходились.
3. Сборка. Навигация, офлайн-режим для подвалов и подъездов, отправка фото-подтверждения, обмен данными с учётной системой службы. Первый прототип проходит проверку на обезличенных нарядах прошлых смен — нагрузка и маршруты берутся реальные, а не выдуманные.
4. Пилотная смена. Несколько курьеров в ограниченном районе, диспетчер работает в обоих контурах одновременно. Смотрим долю нарядов, закрытых без звонка диспетчеру, время на точку и число расхождений с учётной системой.
5. Разбор результатов. Правки по горячим точкам, повторный прогон на той же группе, фиксация целевых значений метрик. Если пилот не сходится с расчётными показателями, контур откатывается на бумажную схему — служба не остаётся без рабочего процесса.
6. Передача проекта. Схема развёртывания, доступы, регламент обновлений, инструкции для курьеров и диспетчеров, обучение ответственного со стороны службы. Дальше — согласованный период сопровождения и обновления после изменений в тарифах или зонах доставки.

Комплект передачи: сборки, схемы, регламенты, доступы

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

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

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

Кейс: служба доставки сократила смену на треть

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

Замер до пилота: смена длилась в среднем 9 часов 40 минут при норме маршрута 7 часов. Без звонка диспетчеру закрывалось 46% заказов — курьер не мог отметить статус, если адрес недоступен или клиент просит перенести доставку. Повторные выезды составляли 11%: адрес в листе расходился с фактическим, а правку вносили через диспетчера только к следующему дню.

Что изменили в приложении

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

Что стало по метрикам

Смена сократилась до 7 часов 15 минут — минус треть при том же числе заказов на курьера. Доля заказов без звонка диспетчеру выросла с 46% до 89%, повторные выезды упали с 11% до 3%: правки адреса вносятся в момент доставки, а не на следующий день. После пилота на приложение перевели весь парк, а контрольная группа перешла на него без доработок.

Что делать, если служба уже работает в готовом сервисе доставки?

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

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

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

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

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

Частые технические сомнения перед стартом проекта

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

Как обновлять приложение, если курьер уже в смене?

Обязательные версии выкатываются в окне между заказами: приложение проверяет обновление при возврате на главный экран и не даёт взять новый заказ на устаревшей сборке. Активные заказы при этом доводятся до конца — обновление не выбивает курьера из смены на середине доставки.

Как приложение стыкуется с учётной системой заказчика?

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

Какие данные курьера и клиента доступны диспетчеру?

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

Обсудим задачу и вернёмся с оценкой и планом

Точность оценки приложения курьера зависит не от числа экранов, а от полноты описания текущих процессов: как распределяются заказы, кто меняет статусы, как считается вознаграждение. Если эти данные есть на старте, мы сразу видим объём интеграций и не переделываем логику в середине работы.

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

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

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