Приложение для курьеров: задания, офлайн и подтверждение доставки

Что включить в приложение собственной доставки: остановки, очередь команд без сети, повторное подтверждение и разбор изменений.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

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

С какой задачи начинать приложение для курьеров

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

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

Задание, отправление и остановка

В одной остановке может быть несколько отправлений, а одно задание иногда включает забор и передачу в разных местах. Если хранить всё одной строкой «адрес доставки», приложение быстро столкнётся с исключениями. Курьер передал часть посылок, но общий статус не умеет это выразить. В офисе тогда появляется неясная отметка, которую приходится разбирать вручную.

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

Какие сведения нужны курьеру в точке

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

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

Экран списка важнее декоративной карты

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

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

Жизненный цикл задания

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

Важно различать действие курьера и принятие системой. Нажатие «Передано» может сначала сохранить локальную команду, затем отправить её, а затем получить подтверждение. Если все этапы показываются одной зелёной галочкой, сотрудники начинают считать неподтверждённую запись окончательным результатом. Офлайн-состояния должны быть частью обычной модели, а не случайной ошибкой внизу экрана.

Подтверждение передачи: какая именно информация нужна

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

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

Частичная передача и недоступный получатель

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

Разделите фактическое действие, причину и решение о продолжении. Например, курьер отмечает отсутствие доступа, а диспетчер решает, переносить ли визит. Приложение не должно самостоятельно назначать новую дату от имени клиента, если такого правила нет. Все демонстрационные причины нужно заменить или подтвердить на обследовании конкретной службы доставки.

Офлайн-режим: локально сохранено не значит принято

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

В руководстве Android об offline-first подходе локальный источник данных рассматривается отдельно от сетевого. Для курьерского сценария этого недостаточно без предметных правил: просроченное или отозванное задание может конфликтовать с локальной командой. Подробная общая модель описана также в статье об офлайн-режиме приложения.

Одна команда и несколько попыток отправки

При нестабильной сети телефон может отправить одну команду несколько раз. Каждая попытка должна ссылаться на исходное действие, а не создавать новое завершение. Сервер возвращает уже известный результат либо объясняет конфликт. Идентификатор команды сохраняется вместе с локальными данными; автоматический повтор не должен заменять его новым.

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

Конфликт между телефоном и диспетчером

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

Сообщение для курьера может объяснять: «Задание изменилось. Действие сохранено и передано на разбор». Это пример для обсуждения. Конкретная формулировка зависит от того, что система действительно умеет сохранять. Нельзя показывать успешное завершение, а затем незаметно откатывать его после синхронизации: пользователь должен понимать, какие последствия ещё не подтверждены.

Геолокация без ложной уверенности

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

Для каждого сценария определите, когда нужна геолокация и есть ли альтернативный путь. Не включайте постоянный фоновый сбор «на всякий случай». Он затрагивает разрешения, батарею, эксплуатационные правила и доверие сотрудников. Отдельный материал о геолокации и разрешениях поможет подготовить вопросы, а выбранную модель нужно проверить на реальных устройствах и условиях работы.

Фоновые ограничения и расход батареи

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

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

Уведомление о задании и получение актуальных данных

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

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

Диспетчерский экран и разбор исключений

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

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

Обмен с магазином, ERP и сервисом доставки

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

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

Работа с файлами и служебными фотографиями

Если вложения необходимы, задайте ограничения и понятный порядок повторной загрузки. Большой файл не должен блокировать весь список заданий без объяснения. У пользователя должна быть возможность увидеть, что сохранено локально, что принято сервером и что требует внимания. Для технических ошибок нужен журнал без избыточного раскрытия содержимого файлов.

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

Интерфейс для одной руки и сложных условий

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

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

Матрица испытаний приложения курьера

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

Как ограничить первую версию

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

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

Какие показатели наблюдать на пилоте

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

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

Частые вопросы

Можно ли начать с Android?

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

Обязательна ли постоянная геолокация?

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

Что значит «сохранено на устройстве»?

Приложение удержало действие локально, но сервер ещё не подтвердил результат. После восстановления связи команда отправляется и проверяется. Если задание изменилось, возможен конфликт. Такой статус должен отличаться от завершения в системе, чтобы курьер и диспетчер не считали неизвестный результат окончательно принятым.

Можно ли просто встроить карту в существующий кабинет?

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

Что предоставить для оценки приложения?

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

Следующий шаг к мобильной разработке

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