Создание приложения для доставки начинается с описания исполнения заказа: кто принимает заявку, кто назначает курьера, как рассчитывается стоимость и что происходит при задержке или неудачном вручении. Клиентский экран заказа — только часть системы. Для работающего сервиса нужны согласованные действия клиента, диспетчера, курьера и поддержки, а также достоверные статусы. Первую версию лучше строить вокруг одного понятного типа доставки и проверять на ограниченной зоне обслуживания.
Определите модель доставки до выбора функций
Доставка собственных товаров, курьерская услуга для сторонних отправителей и агрегатор нескольких исполнителей — разные продукты. В первом случае заказ обычно связан с существующим каталогом и складом. Во втором отправитель описывает груз, точки маршрута и условия передачи. В третьем добавляются подключение партнёров, распределение заказов и расчёты между участниками. Нельзя оценивать эти модели по одинаковому набору экранов без разбора обязанностей каждой стороны.
Уточните, что именно обещает сервис. Доставку в определённый день, в выбранный интервал, после готовности товара или по согласованному маршруту? Клиент должен понимать условия до подтверждения, а сотрудники — иметь возможность выполнить обещание. Если время зависит от ручного решения диспетчера, приложение не должно автоматически показывать точное прибытие без основания. Лучше честный статус ожидания подтверждения, чем привлекательная цифра, которой никто не управляет.
Запишите ограничения груза и обслуживания: габариты, вес, условия перевозки, необходимость подъёма, передачи документов или проверки получателя. Эти сведения влияют на подбор исполнителя и стоимость. Для первой версии допустимо ограничить перечень допустимых отправлений. Важно, чтобы ограничение было видно при оформлении, а не обнаруживалось после прибытия курьера. Неоднозначное описание груза создаёт конфликт, который интерфейс отслеживания уже не исправит.
Определите географию и режим работы. Один город, несколько районов, доставка между филиалами или межгород требуют разных правил. Даже внутри города могут отличаться доступность интервалов и стоимость обслуживания. Укажите выходные, временные ограничения и способ приостановки при перегрузке. Приложение должно опираться на реальные операционные возможности, иначе удобное оформление увеличит количество заказов, которые команда не сможет исполнить.
Опишите участников и их ответственность
Клиент создаёт заявку, предоставляет сведения и получает результат. Диспетчер проверяет условия, назначает исполнителя и разбирает исключения. Курьер принимает задачу, отмечает этапы и подтверждает вручение. Поддержка помогает при изменении адреса, отмене и спорной ситуации. В небольшом бизнесе один сотрудник может совмещать роли, но система должна различать действия и права, чтобы было понятно, кто изменил заказ и на каком основании.
Для курьера определите доступные сведения. Ему нужны адрес, контакт и инструкции по конкретному заданию, но не обязательно вся история клиента и все заказы компании. После завершения задания доступ может меняться в соответствии с согласованным процессом. Эти границы важны и для безопасности, и для удобства: лишняя информация усложняет работу в дороге. Проверять права следует на сервере, а не только скрывать ненужные разделы интерфейса.
Диспетчерскому кабинету нужны функции управления, которых нет у клиента. Очередь неподтверждённых заявок, свободные исполнители, проблемные заказы и причины отклонений помогают поддерживать процесс. Не стоит автоматически включать сложную систему оптимизации маршрутов в первую версию. Иногда ручное назначение с хорошей видимостью состояния достаточно для пилота. Главное — оценить, сколько времени оно требует и при каком объёме перестаёт быть приемлемым.
У поддержки должен быть понятный источник информации. Если оператор видит только последний статус без истории, ему сложно ответить, почему заказ задержался. Полезны отметки времени и причины существенных изменений. При этом журнал не должен превращаться в бесконтрольное хранилище личных данных и переписки. Состав сведений определяется задачей, а доступ — рабочей ролью. В проекте следует заранее решить, какие действия доступны поддержке самостоятельно, а какие требуют руководителя.
Как клиент оформляет доставку
Сценарий начинается с проверки доступности услуги. Адрес, тип отправления и желаемое время могут сразу показать, возможен ли заказ. Не заставляйте человека заполнять длинную форму, если зона не обслуживается. Предусмотрите ручное уточнение для неоднозначного адреса и понятное сообщение об ограничении. Если компания готова принимать такие заявки на индивидуальное согласование, интерфейс должен отличать их от подтверждённой доставки по стандартным условиям.
Данные отправителя и получателя могут различаться. Заказчик оплачивает услугу, а груз принимает другой человек; контакт для доступа в здание может быть третьим. Опишите, какие сведения обязательны и кто может их менять. Для повторных заказов полезны сохранённые адреса и инструкции, но старые записи необходимо давать проверить. Номер офиса, пропускной режим или телефон могут измениться, а автоматическое повторение устаревших данных приведёт к потерянному времени курьера.
Покажите итоговые условия перед подтверждением: маршрут, интервал, описание груза, стоимость и существенные ограничения. Если цена предварительная, объясните, что влияет на уточнение и как клиент его подтверждает. Нельзя незаметно изменить стоимость после принятия заказа. Для сложных отправлений может быть нужен отдельный этап согласования, а для стандартных — автоматический расчёт. Выбор зависит от предсказуемости процесса и доступных данных, а не только от желания сократить число экранов.
После отправки заявки клиент должен получить понятный идентификатор и состояние. «Заявка получена» не равнозначно «курьер назначен». Эти статусы помогают сформировать правильные ожидания. Если подтверждение требует времени, укажите следующий шаг и способ обращения. Не отправляйте человека повторно нажимать кнопку при медленном ответе: система должна безопасно обработать повтор и позволить проверить, создан ли заказ. Это важнее декоративной анимации успешного оформления.
Адреса и зоны обслуживания
Адрес из подсказки, точка на карте и фактический вход в здание могут не совпадать. Предусмотрите уточнение подъезда, корпуса, этажа и ориентира в согласованном объёме. Для курьера важен удобный доступ к информации, а для диспетчера — возможность проверить неоднозначность. Не делайте координаты единственным подтверждением корректности адреса. В реальной работе встречаются закрытые территории, несколько входов и здания, которые картографический сервис отображает неполно.
Правила зон могут зависеть от расстояния, административной границы или внутренних участков. Выберите модель, которую сотрудники способны поддерживать. Если зона меняется при перегрузке, определите, как это отражается для уже созданных заказов. Нельзя просто отключить район и потерять ранее подтверждённые обязательства. Изменение доступности относится к новым обращениям или запускает отдельную процедуру пересогласования — это решение бизнеса, которое нужно явно реализовать.
Проверяйте пограничные адреса и ошибки определения. Клиент может поставить точку рядом с границей, а текстовый адрес относиться к другой зоне. Система должна иметь понятное правило разрешения такого случая. Для пилота допустимо отправлять спорные заявки диспетчеру, если клиент видит, что подтверждение ещё ожидается. Автоматическое решение полезно только тогда, когда оно достаточно надёжно для выбранных условий и его ошибки можно обнаружить.
Использование карт связано с условиями конкретного поставщика. Набор функций, лимиты и стоимость следует проверять перед интеграцией по официальной документации. Не закладывайте в бюджет произвольную бесплатность карт для любого масштаба. Разделите отображение адреса, построение маршрута и обработку координат: это могут быть разные возможности и расходы. Для заказчика полезен расчёт потребления на типовой заказ и сценарий роста числа операций.
Стоимость доставки и изменение условий
Формула стоимости должна быть воспроизводимой. Базовый тариф, расстояние, вес, ожидание, подъём и дополнительные услуги не должны появляться случайно в разных частях процесса. Укажите источник каждого параметра и момент фиксации цены. Если окончательные характеристики груза известны только при получении, заранее объясните клиенту порядок уточнения. В противном случае курьер окажется участником спора, который возник ещё на стадии оформления.
Отдельно определите правила изменения адреса после назначения. Это может менять маршрут, время и стоимость. Система должна показывать, кто запросил изменение и кто его подтвердил. Не позволяйте редактировать ключевые условия незаметно для исполнителя. Для первой версии можно направлять такие запросы через поддержку, если ручной процесс понятен и учитывается в нагрузке. Главное, чтобы интерфейс не создавал иллюзию мгновенного изменения уже выполняемой доставки.
Промокоды и бонусы добавляйте только при ясных правилах. Какая часть стоимости уменьшается, можно ли сочетать предложения, что происходит при отмене и частичном исполнении? Маркетинговая функция может затронуть расчёты с курьером и бухгалтерский учёт. Если в пилоте её можно заменить простым согласованным условием, это уменьшит количество зависимостей. Решение о лояльности принимают после оценки ценности, а не потому, что скидка есть у крупного конкурента.
Для проверки тарифа подготовьте набор примеров с ожидаемыми результатами. Короткий маршрут, адрес на границе зоны, тяжёлое отправление, изменение точки, платное ожидание. Бизнес подтверждает правильность расчётов, техническая команда проверяет реализацию. Такие примеры полезны и после запуска: при изменении правил они помогают обнаружить непредвиденное влияние на старые сценарии. Без них сотрудники могут по-разному трактовать один и тот же тариф.
Назначение курьера и рабочий маршрут
Для первой версии определите, кто назначает исполнителя и по каким признакам. Доступность, зона, тип транспорта, вместимость и специальные условия груза могут быть важнее минимального расстояния. Если назначение ручное, кабинет должен показывать необходимую информацию и предотвращать очевидные конфликты. Если автоматическое, нужно определить поведение при отказе, отсутствии кандидата и задержке ответа. Алгоритм без обработки исключений быстро возвращает работу в телефонные звонки.
Курьер должен подтвердить принятие задания или отклонить его по согласованной причине. Статус «назначен» не всегда означает, что человек увидел заказ и готов его выполнять. Для срочных операций важен процесс реакции на отсутствие подтверждения. Диспетчер видит проблему и принимает решение о переназначении. Система должна сохранять историю, чтобы клиент не получал противоречивые сведения, а два исполнителя случайно не отправлялись за одним грузом.
Маршрут может состоять из нескольких точек. Уточните порядок посещения, возможность изменения и условия завершения каждого этапа. Для простого пилота можно ограничить маршрут одной отправкой и одним получением. Если бизнес работает со сборными рейсами, такая граница может быть неприемлемой и её нужно учесть сразу. Не стоит обещать оптимизацию сложной логистики как бесплатное следствие добавления карты в приложение.
Работа курьера часто происходит при нестабильной связи. Важно понимать, какие данные доступны без интернета, как сохраняются отметки и что происходит после восстановления соединения. Если действие ещё не передано на сервер, интерфейс должен это показывать. Нельзя выдавать локально нажатую кнопку за подтверждённый системой результат. Эти условия проверяются на реальном устройстве и маршруте, а не только в офисе с устойчивой сетью.
Статусы и отслеживание без ложной точности
Создайте понятную модель состояний: заявка получена, подтверждена, исполнитель назначен, груз получен, доставка выполняется, вручено или возникла проблема. Конкретный набор зависит от процесса. У каждого перехода должны быть автор и условия. Если статус меняется автоматически, необходимо понимать событие-основание. Если вручную — кто имеет право его изменить и какие сведения обязан указать. Это помогает избежать ситуации, когда разные участники считают заказ завершённым в разный момент.
Клиенту не обязательно видеть все внутренние состояния. Ему нужна информация, которая помогает действовать: ждать подтверждение, подготовить груз, встретить курьера или обратиться в поддержку. Внутренний технический сбой можно объяснить понятным сообщением без раскрытия деталей системы. При этом нельзя скрывать существенную задержку за неизменным статусом. Предусмотрите способ сообщить обновлённые условия и получить согласие, если меняется обещанный результат.
Геолокация курьера не всегда означает точное время прибытия. Координаты могут обновляться с задержкой, а маршрут зависеть от дорожной ситуации и других задач. Если показывается прогноз, объясните его характер и условия обновления. Не используйте декоративный движущийся маркер, который не связан с реальным состоянием. Для некоторых моделей достаточно контрольных статусов и приблизительного интервала; постоянное отслеживание следует добавлять, когда оно даёт подтверждённую пользу.
Уведомления должны поддерживать процесс, а не заменять состояние заказа. Пользователь может запретить push, пропустить сообщение или открыть приложение позднее. Актуальная информация должна оставаться доступной внутри продукта. Для критичных событий определите дополнительный канал в соответствии с условиями сервиса и согласиями. Частота сообщений также требует внимания: повторные технические события не должны превращаться в серию одинаковых уведомлений клиенту.
Вручение и неудачная попытка доставки
Завершение заказа должно подтверждаться согласованным способом. Это может быть отметка курьера, код получателя, подпись или другой предусмотренный процесс. Выбор зависит от груза и требований бизнеса. Не собирайте дополнительные фотографии и документы без понятной необходимости и условий обработки. Чем чувствительнее подтверждение, тем важнее ограничить доступ и срок хранения, согласовав требования с ответственными специалистами.
Опишите ситуации отсутствия получателя, отказа, неверного адреса и невозможности связаться. Курьеру нужен понятный порядок действий, а диспетчеру — информация для решения. Повторная попытка, возврат отправителю и ожидание могут иметь разные условия и стоимость. Эти правила должны быть известны до оформления или пересогласованы в установленном порядке. Иначе приложение лишь фиксирует конфликт, не помогая его разрешить.
Если груз возвращается, возникает отдельная цепочка: где он находится, кто принял решение, кому передаётся и как закрывается операция. Нельзя просто поставить первоначальному заказу статус «отмена» и потерять фактическое местоположение отправления. Для первой версии допускается ручная обработка возврата, но она должна иметь журнал и ответственного. Клиенту важно видеть, что происходит с его отправлением, а сотрудникам — не терять незавершённые обязательства.
Подготовьте способ разбирательства спорного вручения. В системе должны сохраняться достаточные сведения о действиях без избыточного сбора данных. Кто изменил статус, когда, с какого задания и какое подтверждение приложено. Не обещайте, что цифровая отметка исключает любые споры. Она помогает восстановить последовательность событий, а условия ответственности и доказательств определяются правилами сервиса и применимыми договорённостями.
Платежи и взаиморасчёты
Определите, кто принимает оплату и в какой момент. Заказчик услуги может платить заранее, после подтверждения или по договорённости с компанией. Для разных моделей меняются риски отмены и возврата. Если приложение связано с продажей товара, следует разделить стоимость товара и доставки в согласованном учёте. Не переносите все денежные процессы в приложение без необходимости: иногда пилот использует существующую схему расчётов, сохраняя ясный статус оплаты.
При интеграции оплаты проверяется не только успешная операция, но и задержка, отказ и повторный запрос. Сервер должен получать достоверное подтверждение выбранного платёжного сервиса. Например, документация ЮKassa описывает требования к запросам и механизмы идемпотентности, предназначенные для корректной обработки повторов. Конкретное поведение необходимо реализовать и проверить по документации используемого поставщика, а не полагаться на сообщение об успехе на телефоне. ЮKassa: API.
Расчёты с курьерами или партнёрами могут быть отдельной сложной системой. Вознаграждение, удержания, отмены и корректировки требуют правил и юридического оформления. Не включайте автоматические выплаты в первую версию только потому, что сервис оплаты технически предоставляет API. Сначала определите модель отношений и учёта с профильными специалистами. Техническая возможность выполнить перевод не заменяет правильную организацию расчётов.
Сверка должна позволять найти расхождения между заказом и платёжной операцией. У каждого события нужны согласованные идентификаторы и понятный источник состояния. Если клиент оплатил, а заказ не подтвердился, поддержка должна иметь способ установить факт и действовать по процедуре. Такие исключения особенно важно проверить до широкого запуска: они влияют одновременно на доверие клиента, работу сотрудников и финансовый учёт.
Какие интеграции нужны первой версии
Начните с существующей системы заказов, если она уже используется. Определите, какие сведения приложение читает и какие записывает. Если данные ведутся в нескольких местах, выберите источник для каждого объекта. Адрес, клиент, тариф и статус не должны бесконтрольно изменяться в разных системах. Для пилота допустимо ограничить обмен необходимым набором, но его границы должны сохранять работоспособность основного процесса.
Затем рассмотрите карты, сообщения и платежи. У каждого подключения есть тариф, ключи, лимиты и правила ошибок. Составьте перечень владельцев аккаунтов и ответственных за оплату. Если закончились средства на отправку кодов входа, клиент не сможет оформить заказ, хотя само приложение исправно. Такие зависимости входят в эксплуатацию и должны быть видимы команде, а не обнаруживаться случайно по жалобам пользователей.
Если используются внешние службы доставки, проверьте согласованность статусов и отмен. У партнёра может быть более подробная или другая модель состояний. Нельзя механически отображать внутренние коды без объяснения. Нужно определить, как они переводятся в понятные клиенту события и что происходит при неизвестном значении. Изменения внешнего API требуют сопровождения, поэтому оценка интеграции включает не только первоначальное подключение.
Не пытайтесь сразу соединить все сервисы, которыми компания когда-либо планирует пользоваться. Выберите минимальный рабочий набор и сохраните понятные границы для развития. Лишняя интеграция увеличивает число точек отказа и объём проверки. При этом критичный обмен нельзя заменять ручной операцией без оценки нагрузки. Решение принимают по процессу: сколько действий выполняет сотрудник, как быстро нужны данные и что произойдёт при ошибке.
Что включить в пилот доставки
Пилот можно ограничить одной зоной, одним типом груза и небольшой группой исполнителей. В нём должны работать создание заявки, подтверждение условий, назначение, выполнение и закрытие заказа. Для клиента нужны понятные статусы и контакт поддержки. Для команды — возможность увидеть проблемы и вручную вмешаться в согласованных пределах. Ограниченный объём делает наблюдение управляемым, но не оправдывает потерю заказов или неясные расчёты.
Выберите участников, способных дать содержательную обратную связь. Курьер должен пройти настоящий маршрут, диспетчер — обработать несколько разных ситуаций, клиент — самостоятельно оформить обращение. Не ограничивайтесь сотрудниками разработки, которые знают все скрытые условия. Записывайте затруднения и причины ручного вмешательства. Они покажут, какие части процесса требуют доработки до увеличения числа пользователей.
Для оценки пилота полезны доля заявок, потребовавших уточнения, число неназначенных заказов, задержки между этапами и причины неудачного вручения. Сами показатели не гарантируют успеха бизнеса, но помогают увидеть узкие места. Сравнивайте их с исходным процессом и условиями конкретного периода. Изменение загрузки, района или состава отправлений может влиять на результат, поэтому не приписывайте любое улучшение только приложению.
Сформулируйте условия расширения. Например, основные сценарии проходят без критичных ошибок, сотрудники понимают исключения, данные не расходятся, поддержка успевает разбирать обращения. Затем постепенно добавляйте зоны или группы клиентов. Масштабирование без проверки операционной готовности способно увеличить не эффективность, а очередь проблем. Продукт и работа команды должны развиваться согласованно.
Проверки перед публичным запуском
Пройдите заказ целиком в рабочем окружении по согласованному безопасному плану. Проверьте адрес вне зоны, отказ курьера, потерю связи, повторную отправку и отмену после назначения. Сверьте состояние в клиентском приложении и кабинете диспетчера. Если используются настоящие платежи, заранее определите контрольную операцию и возврат. Проверка должна быть управляемой и не создавать случайных обязательств перед реальными клиентами.
Проверьте права между исполнителями и клиентами. Курьер не должен получать чужие задания через изменение идентификатора, а клиент — просматривать сведения других получателей. Убедитесь, что завершение сеанса и отзыв роли работают согласно требованиям. Для чувствительных данных необходима профильная проверка соответствующего уровня. Визуальный просмотр экранов не подтверждает безопасность серверной части.
Проверьте уведомления и доступность поддержки. Куда приходит сообщение о зависшем заказе, кто видит отсутствие подтверждения курьера, как клиент сообщает об ошибке адреса? Если эти вопросы не решены, приложение оставляет сотрудников с теми же звонками, но добавляет ещё один источник заявок. У каждой проблемной ситуации должен быть владелец следующего действия, а не только цветная отметка в интерфейсе.
Наконец, подготовьте инструкции, аккаунты, резервирование и план обновлений. Доставка работает в конкретные часы и часто зависит от текущих заказов, поэтому выпуск новой версии требует осторожности. Команда должна понимать, как наблюдать за состоянием и что делать при ухудшении. Создание приложения для доставки заканчивается не красивой картой, а проверенным процессом от заявки до вручения, который компания способна поддерживать каждый день.