Почему мобильное приложение курьерской службы буксует в поле
Курьер принимает заказ в подвале или за городом: приложение показывает «принято», а на диспетчерском экране заказа нет. Слабый канал оборвал отправку, локальная очередь запись не удержала, повтор не предусмотрен — и клиент ждёт курьера, который уже уехал по другому адресу. Формально заказ принят — для системы он не существует; так выглядит потеря заказов при слабой связи.
Статусы доставки зависают до конца смены. Офлайн-режим курьера работает только на чтение: последние данные показать можно, отправить новое состояние — нет. Отметки «доставлено», «отказ», «перенос» пишутся поверх предыдущего состояния без очереди и повторной отправки, поэтому при переключении между сетями часть событий теряется, а при возврате связи приходит дублями. Диспетчер видит «в пути» там, где заказ закрыт час назад, и обзванивает курьеров, чтобы восстановить картину дня.
Третий источник сбоев — ручной ввод адреса. Курьер набирает улицу и дом текстом, ошибка в одну цифру превращается в выезд не туда и повторную доставку. Поддержка тонет в уточняющих звонках: в час пик они идут потоком и вытесняют разбор реальных сбоев, а нагрузка на диспетчера растёт вместе с числом курьеров на линии.
Цена этих дефектов — потерянные заказы, недостоверные статусы и диспетчер, который вручную склеивает данные по звонкам. Разбираем, как это закрывается.
Что меняется в смене курьера: четыре измеримых эффекта
Эффект виден в смене, а не в отзывах: сколько адресов курьер закрывает за час, сколько заказов уходит в поддержку и что происходит, когда пропадает связь. По каждому пункту ниже есть метрика, которую можно снять до внедрения и после.
Скорость закрытия заказа
Вручение отмечается одним касанием, статус уходит в диспетчерскую сразу — без звонка и вечернего сведения накладных. Разрыв между фактической передачей заказа и его закрытием в системе сжимается с часов до секунд, а освободившееся время уходит на дополнительные адреса.
Офлайн-синхронизация: связь пропала, смена продолжается
Подвал, лифт, загородный участок — отметки, фото и подписи ложатся в локальную очередь, и работа не прерывается. При появлении сети очередь уходит на сервер по порядку, без дублей и потерянных статусов, поэтому после сбоя связи не нужен ручной разбор смены.
Контроль статусов доставки без обращений в поддержку
Каждый переход — «в пути», «на месте», «вручено» — фиксируется со временем и позицией, а движение курьера диспетчер и клиент видят на карте в сервисе Яндекс Карты. Вопрос «где мой заказ» закрывается экраном отслеживания, и доля заказов без звонков в поддержку растёт кратно.
Ручных операций меньше, ошибок ввода нет
Адрес и состав заказа подтягиваются из накладной, вручение подтверждается сканом вместо перепечатывания номера. Расхождения ловит система на входе, а не разбор в конце дня, — класс ошибок ручного ввода уходит целиком.
Варианты разработки: готовая платформа, конструктор, своя сборка
На старте все четыре пути выглядят похоже: карта, статусы заказа, уведомление о назначении курьера. Разница проявляется на объёме заказов, при смене схемы расчёта с курьерами и когда к приложению нужно подключить собственный диспетчерский контур.
Как выбрать под размер парка и логику заказов
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовая платформа доставки | Парк до 50 курьеров, типовые заказы, запуск в сжатые сроки | Маршруты и тарифы заданы вендором, свои правила — только через общую очередь доработок |
| Конструктор приложений | Нужен быстрый выпуск и простая витрина заказов | Экраны собираются из чужих блоков, нестандартный шаг оформления требует внешнего модуля |
| Разработка под задачу | Своя логика распределения заказов, обмен с учётной системой, парк растёт | Дольше вход, нужен свой релизный контур и постоянная поддержка |
| Доработка текущего решения | Приложение работает, но упирается в потолок по функциям | Зависимость от кода прежнего подрядчика, сначала ревизия и перенос сборки |
Где упираются на второй год
У платформы потолок наступает, когда появляется второй тип курьера или зона с другими правилами — ядро под них не перестраивается. Конструктор начинает тормозить на числе экранов и связок, а обновления чужих модулей идут по чужому графику. Своя сборка требует держать совместимость с актуальными версиями систем и проверять работу на слабой связи и старых устройствах. Доработку чужого кода без ревизии почти всегда ждёт второй виток переделок.
Этапы внедрения: от разбора процессов до передачи проекта
Пока приложение не собрано, процессы доставки живут в голове диспетчера и в переписке. Поэтому начинаем не с кода, а с разбора маршрута заказа: какие статусы меняются, где появляется бумага, где курьер звонит в офис, чтобы уточнить адрес.
- Разбор процессов доставки — идём в смену и фиксируем реальный путь заказа: приём, распределение, выдача, подтверждение, возврат. Отмечаем места, где данные вводят дважды.
- Схема обмена данными — описываем сущности заказа, адреса, интервала доставки, статуса и подписи получателя, направления синхронизации и поведение приложения без сети.
- Роли и права — курьер, диспетчер, логист, администратор: что каждый видит и меняет, какие действия требуют подтверждения.
- Сборка и связка с учётной системой — интерфейсы под работу одной рукой, очередь неотправленных отметок, журнал действий.
- Полевая проверка на реальных сменах — слабая связь, старые устройства, вечерние адреса.
- Передача и обучение — инструкции, регламент разбора сбоев, доступы, порядок обновлений.
Пилот на одной смене
Запускаем на одном экипаже и одной смене с ограниченным числом заказов. Считаем время на отметку статуса, смотрим, где рвётся синхронизация и сколько курьер зовёт диспетчера. Так сырая сборка не уходит на весь парк.
Критерии приёмки
Приёмка идёт по измеримым показателям: доля заказов, закрытых без звонка в офис, время на одну доставку, доля отметок, дошедших до системы без ручной правки, число отказов за смену. Пока сходимости нет, этап не закрыт.
Артефакты проекта: сборки приложения, схемы, регламенты
Проект сдаётся не папкой с исходным кодом, а комплектом, по которому приложение можно развивать без нас. Всё, что создаётся по ходу работы, остаётся в хранилищах и учётных системах заказчика вместе с описанием, как этим пользоваться.
- готовые сборки для магазинов приложений — подписанные, с описанием версии, которую можно выкатить повторно;
- схема обмена с учётной системой: какие сущности синхронизируются, как часто и что происходит при обрыве связи;
- матрица ролей и прав: курьер, диспетчер, логист, администратор — что каждый видит и меняет;
- регламент поддержки: каналы обращений, время реакции по классам сбоев, порядок эскалации;
- инструкция для курьеров: установка, вход, работа с заказом, действия при потере сети;
- порядок выпуска обновлений: кто согласует, как проверяется сборка, как выполняется откат;
- описание сборки и окружений — чтобы релиз воспроизводился на чистой машине без нас.
Права доступа и матрица ролей
Матрица задаёт не только видимые экраны, но и доступ к данным: курьер видит лишь свои заказы и не правит накладную, логист распределяет и переназначает, администратор ведёт справочники. Отдельно описаны ограничения по точке выдачи и территории.
Порядок выпуска обновлений
Сборка сначала идёт в тестовый контур и проверяется на реальных сценариях маршрута, затем выкатывается постепенно — сперва на группу курьеров, потом на всех. Откат расписан пошагово: как вернуть предыдущую версию, если в смену выросла доля ошибок.
Кейс: как сократили потери заказов в час пик
Курьерская служба с парком в несколько сотен исполнителей пришла с проблемой в вечерний час пик: часть заказов оставалась без курьера. Заказ висел в очереди, клиент звонил в поддержку, а исполнитель отказывался от предложения, не понимая реального объёма работы.
Метрики до и после на действующем парке
Считали не средние по дню, а отдельно пиковые два часа — именно там терялись заказы. Замеры снимали до запуска и через месяц работы на том же парке, без выделенных «эталонных» курьеров:
- доля потерянных заказов в час пик — 11% → 2%;
- время закрытия адреса — 8,5 → 5 минут;
- обращения в поддержку по статусу заказа — сократились втрое;
- заказов на исполнителя в час пик — на 20% больше.
Что меняли в процессах, а не только в приложении
Приложение не было единственной точкой правки: переписали правила распределения — приоритет ближайшему курьеру с учётом времени закрытия адреса, а не порядкового номера заказа. Ввели понятную статусную модель, чтобы диспетчер видел зависший заказ до звонка клиента, и обучили смену работать с ней. Прогноз времени прибытия пересчитали на данных картографического сервиса Яндекс.Карты с учётом пробок.
Результат внедрения держится на этих двух слоях: интерфейс снимает лишние действия, а правила распределения не дают заказу остаться без исполнителя. Через полгода после запуска доля потерянных заказов в час пик осталась на уровне 2-3% при выросшем объёме.
Чем доработка готового решения отличается от сборки с нуля
Доработка готового решения сохраняет работающий контур: справочники, историю заказов, учётные записи курьеров и настроенные обмены с учётным контуром 1С. Перенос данных здесь — предсказуемая операция: выгрузка, сопоставление полей, загрузка в новую схему, занимает дни, а не месяцы. А вот логика переносится редко — расширения, написанные в обход ядра, живут по своим правилам и часто не имеют точки подключения в чужой сборке.
Упоры готовой платформы начинаются там, где требование расходится с заложенной моделью. Офлайн-работа курьера, фоновая передача геопозиции, нестандартная очередь распределения заказов, тонкие права на подмену и передачу смены — если это закрыто внутри модуля, доработка превращается в надстройку над чужим кодом. Она держится до первого крупного обновления.
Совместимость версий — второй ограничитель. Обновление ядра меняет контракты, и каждое расширение проходит повторную проверку. Два-три выпуска подряд с поломками доработок — сигнал, что стоимость владения растёт быстрее, чем продукт.
Сборка с нуля выигрывает, когда больше трети ключевых сценариев упирается в закрытые модули или сроки перезапуска короче, чем путь последовательных доработок. Тогда мы фиксируем состав данных для переноса, проектируем схему под реальные сценарии смены и выводим первый рабочий выпуск раньше, чем надстройка над платформой дошла бы до того же объёма. Опишите вашу ситуацию — вернёмся с оценкой и планом, где именно проходит точка разворота.
Частые сомнения: связь, батарея, учётная система
Сомнения здесь не про интерфейс, а про смену целиком: связь в подъездах и подвалах, заряд к вечеру, старые аппараты в парке и уже работающая учётная система. Ниже — как эти места закрыты архитектурно, а не обещаниями.
Что будет с нарядом при перебоях связи?
Курьер работает в локальной очереди: статусы, отметки о вручении и фото пишутся на устройство, а уходят при появлении сети. У каждой операции свой ключ-идентификатор, поэтому повторная отправка не создаёт дубль наряда.
Потянет ли приложение бюджетный аппарат?
Экран нарядов — лёгкий список без тяжёлой карты, фоновая активность ограничена, данные приходят порциями. На аппаратах прошлых лет смена идёт без подвисаний при большой истории заказов.
Сколько заряда уходит за смену?
Координаты уходят пакетами с адаптивной частотой: в движении чаще, на стоянке реже; в фоне опроса сервера нет — события приходят уведомлением. Типовой смартфон выдерживает смену без внешнего аккумулятора.
Как приложение стыкуется с учётной системой?
Приложение не пишет в учётную систему напрямую: операции идут через слой интеграции по описанным правилам. Это даёт сверку статусов, повтор при сбое и разбор расхождений, если учётная система недоступна.
Обновление остановит смену?
Нет: версии выкатываются поэтапно, установка откладывается до конца смены, а прежний клиент работает с сервером до принудительного порога. Курьер не остаётся без наряда из-за выпуска обновления.
Старт работ: состав смен, схема обмена, порядок оценки
Чтобы вернуться с оценкой и планом по этапам, а не с широким диапазоном, нужен минимальный, но конкретный набор входных данных. Приложение курьера живёт на стыке устройств в поле и учётной системы в офисе — почти вся трудоёмкость определяется тем, насколько подробно описан этот стык.
- Состав ролей и смен: курьер, диспетчер, сортировщик, руководитель смены — и как заказы передаются между сменами, включая ночные окна.
- Примеры обмена с учётной системой: 3–5 реальных выгрузок — заказ, статус, отмена, закрытие наряда. По ним видны обязательные поля и поведение при недоступности сервиса.
- Ограничения по устройствам: модели и версии операционных систем в парке, нужен ли офлайн-режим и на сколько часов, есть ли сканеры и принтеры этикеток.
- Правила работы с данными: где хранятся персональные данные получателей, нужно ли подтверждение доставки фото и подписью.
- Точки контроля и порядок согласования: какие этапы принимаете лично — схема обмена, прототип, сборка, тестовый контур, выпуск; под каждую точку — критерий приёмки.
- Контур решений: кто со стороны заказчика отвечает на вопросы и в какой срок — это влияет на план не меньше объёма работ.
Из этого собираем план по этапам с оценкой трудозатрат и явными допущениями: видно, что делается на каждом шаге и где вы принимаете результат.
