Как спроектировать мобильное приложение для курьеров цветов: события доставки, обязательные подтверждения, маршрут, фото вручения и офлайн очередь отправки.
Мобильное приложение для курьеров цветов нужно не ради «удобства», а чтобы закрыть типовые спорные ситуации: клиент говорит, что букета не было, курьер уверен, что передал; фото осталось «где-то в чате», но его не найти; статусы каждый отмечает по-своему, и менеджер не понимает, что реально происходит.
Курьеру важно пройти смену быстро и без лишних действий, а менеджеру - видеть одну правду по каждому заказу. Поэтому в одном приложении должны жить и простые действия «в полях», и понятная картина для офиса.
Курьеру нужны маршрут по точкам, быстрый старт доставки, подсказки по адресу (подъезд, этаж, домофон) и простое подтверждение вручения без лишних экранов.
Менеджеру нужны текущий статус каждого заказа, причина задержки, наличие подтверждения (фото, код, подпись) и история событий по времени, чтобы разбирать спорные случаи без обзвона всех подряд.
Хорошее правило: фиксируйте сразу только то, что влияет на спор и деньги. Остальное можно дополнять позже, когда появится связь и время.
На месте обычно достаточно зафиксировать событие (в пути, на адресе, вручено, не удалось), время и геометку (хотя бы приблизительно), обязательное подтверждение (например, фото и короткий комментарий) и причину, если вручить не получилось (не отвечает, неверный адрес).
Доставка часто проходит там, где интернет пропадает: подъезды, лифты, подвалы, дворы-колодцы. Если приложение не умеет хранить события и фото локально, вы получите «пустые» статусы и потерянные доказательства.
Нормальный сценарий такой: курьер делает фото, добавляет комментарий, отмечает статус, а приложение кладет это в офлайн-очередь и отправляет автоматически, когда связь появится. Менеджер видит ход доставки, а подтверждения не теряются.
Чтобы мобильное приложение для курьеров цветов было удобным с первого дня, полезно мыслить ролями.
Курьер видит только свои доставки и подтверждает вручение. Диспетчер распределяет заказы, следит за статусами и помогает, если адрес проблемный. Администратор настраивает справочники (зоны, причины отмены, типы оплат), права и доступы.
В данных лучше держаться простого ядра: заказ (номер, время, сумма), адрес (строка, подъезд, этаж, домофон), получатель (имя, телефон), букет (название, состав, заметки по упаковке), оплата (оплачено онлайн, наличные, терминал), комментарии (для курьера и для диспетчера). Этого хватает, чтобы не утонуть в деталях и закрыть большинство реальных ситуаций.
У курьера должен быть небольшой набор экранов, без лишних меню: список доставок на смену (время, район, краткий статус), маршрут на день (хотя бы простой порядок точек), карточка заказа (адрес, контакты, инструкции, кнопки действий), камера для фото вручения с быстрым комментарием и история событий по заказу.
Важно заранее решить, что хранится на телефоне, а что только на сервере. Иначе офлайн-работа превращается в хаос: курьер заходит в лифт или подвал, связь пропадает, а фото и статусы теряются.
Локально на устройстве обычно держат активные заказы на сегодня и их последние статусы, очередь несинхронизированных событий (время, тип, примечание), черновики фото подтверждения (файл и привязка к заказу) и минимальные справочники (причины отмены, типы оплат).
На сервере храните полный журнал, оригиналы фото, права доступа и историю смен. Пример: курьер сделал фото у двери и добавил комментарий «получатель попросил оставить у консьержа». Даже если сеть появится через 20 минут, приложение должно показать, что действие уже принято и будет отправлено.
Чтобы курьер и диспетчер не спорили по телефону, в приложении важны две вещи: короткие статусы (что происходит прямо сейчас) и события (что именно случилось по дороге). Чем меньше вариантов, тем быстрее ими пользуются.
Для доставки цветов обычно хватает пяти статусов, которые видны в списке заказов и в карточке:
Статус - это итог на текущий момент. События - журнал действий, который объясняет, почему статус именно такой. Например, заказ может быть «На месте», но с событием «Ожидание 10 минут».
Держите список событий коротким и понятным. Чаще всего нужны:
События помогают разбирать спорные случаи. Пример: курьер приехал, поставил «На месте», добавил «Звонок: не ответил» и «Ожидание 15 минут». Диспетчер видит картину, а не просто «Не вручено».
Правило простое: все, что влияет на деньги и ответственность, должно иметь подтверждение. Обычно подтверждения нужны для «Вручено», «Не вручено» и «Отказ».
Ставить их должен курьер, но некоторые события лучше ограничить ролью диспетчера. Например, изменение адреса или официальный перенос на другой день. Так меньше путаницы.
Чтобы не перегружать курьера, время и координаты фиксируйте автоматически при каждом статусе и важном событии. Координаты часто достаточно сохранять для «На месте» и финальных исходов («Вручено» и «Не вручено») - это дает контроль без лишней детализации.
Статус «вручено» должен означать одно и то же всегда. Если в одном заказе есть фото, а в другом только слово курьера, споры неизбежны: клиент говорит «не получал», диспетчер не может доказать обратное. Поэтому лучше заранее задать обязательный набор подтверждений.
Рабочая механика простая: курьер не может нажать «Вручено», пока не заполнит обязательные поля. Это дисциплинирует и делает отчеты понятными.
Базовый набор, который хорошо работает в доставке букетов:
Качество фото лучше проверять сразу, а не в офисе вечером. Простые правила: кадр не должен быть размытым, букет должен быть виден целиком, а в идеале - в руках получателя или рядом с ним. Если вы сохраняете фото локально и отправляете позже, храните вместе с фото время, заказ и автора события.
Комментарии не стоит превращать в длинные сочинения. Удобнее дать 5-7 коротких шаблонов («не дозвонился», «ждал 10 минут», «охрана не пустила») и поле свободного текста на 1-2 предложения. Так диспетчер быстрее видит причины, а курьер не тратит время.
Иногда фото сделать нельзя: получатель против, место режимное, букет передали через консьержа. Тогда нужен запасной сценарий, чтобы «вручено» все равно было подтверждено и объяснимо:
Маршрут в приложении должен помогать доставлять, а не отвлекать. Курьеру важнее всего видеть следующую точку и что именно там нужно сделать. Для доставки цветов это особенно критично: время идет, цветы чувствительны, а руки часто заняты.
Хороший экран маршрута выглядит просто: наверху следующая доставка (адрес, имя получателя, окно времени), ниже - остальные точки в порядке выполнения. Рядом с каждой точкой полезно показывать краткий статус (запланировано, в пути, у двери) и оценку времени прибытия. Если оценка плавает, лучше честно писать диапазон или пометку «зависит от пробок», чем создавать ложную точность.
Иногда порядок точек нужно менять вручную. Не прячьте это в настройки: сделайте понятное действие прямо в списке, а после перестановки попросите выбрать причину. Причины помогают диспетчеру и аналитике, а курьеру дают ощущение контроля.
Обычно покрывают большую часть случаев такие причины: получатель попросил другое время, пробка или перекрытие дороги, не дозвонился и переношу на позже, срочный заказ и вставляю раньше, ошибка адреса и уточняю.
С навигацией лучше не соревноваться с картами. Кнопка «Открыть навигатор» должна передать адрес и комментарий (если поддерживается), а при возврате курьер сразу попадает обратно в карточку заказа, а не ищет ее в списке. Еще момент: фиксируйте факт «выехал к точке» перед переходом во внешнее приложение, чтобы событие не потерялось.
Адресные подсказки должны быть короткими и всегда под рукой: домофон, подъезд, этаж, код калитки, где парковаться, кому отдавать «вахтеру» или «ресепшен». Пример: «Домофон 12В, подъезд 3, этаж 9, оставить у двери, позвонить за 2 минуты». Такая строка экономит минуты на каждой доставке и снижает число звонков диспетчеру.
Курьер часто работает в лифте, в подъезде или за городом, где связь прыгает. Если приложение требует интернет для каждого шага, фото вручения и комментарии начинают теряться. Поэтому нужна офлайн-очередь: курьер делает действия, а отправка на сервер происходит позже, когда сеть появится.
В очередь попадает все, что подтверждает факт доставки и помогает разобраться в спорных случаях. Обычно достаточно хранить событие со временем, фото (как файл на телефоне) и привязку к заказу, короткий комментарий и причину отказа (если есть), координаты и точность (если разрешены), а также технические данные: ID заказа, ID попытки, версию записи.
Важно: фото лучше хранить как локальный файл, а в очереди держать только путь к нему и метаданные. Так запись не раздувается.
Курьеру нужно ощущение, что он закончил. Поэтому действие считается выполненным сразу локально: событие записалось, фото прикрепилось, заказ сменил статус на телефоне. Синхронизация идет отдельно. Если отправка не удалась, заказ не откатывается назад, но получает пометку вроде «ожидает отправки подтверждения».
Отправка должна уметь повторяться. Практичный вариант: пробовать сразу, потом через 1, 5 и 15 минут, а дальше реже. После нескольких неудач показывайте понятную причину (нет сети, сервер не отвечает, фото слишком большое) и кнопку «повторить сейчас». Чтобы не было дублей, каждую отправку делайте с уникальным ID попытки.
Что показывать курьеру: маленький индикатор очереди (например, «2 в ожидании») и простые статусы у заказа: «сохранено на телефоне», «отправляется», «отправлено», «нужна проверка». Так курьер понимает, что фото не пропало.
Чтобы быстро собрать мобильное приложение для курьеров цветов, начните не с экранов, а с того, какие данные вы обязаны сохранить даже без связи. Дальше все становится проще: данные диктуют API, API диктует экраны, а офлайн-очередь закрывает самый частый риск - потерю фото и статусов.
Опишите сущности и поля. Минимум: заказ (номер, адрес, окно времени, телефон), событие (тип, время, координаты), подтверждение (способ: фото, код, подпись; кто принял), вложение (фото: файл, размер, статус загрузки).
Сформулируйте действия API простыми словами. Не «эндпоинты», а «что делает курьер»: получить список заказов, открыть заказ, отправить событие, приложить подтверждение, загрузить фото, проверить, что все ушло.
Набросайте экраны Flutter и переходы. Обычно хватает: список заказов -> карточка заказа -> экран подтверждения. Добавьте внутри заказа «журнал событий», чтобы курьер видел, что уже сделано и что еще не отправилось.
Сделайте локальное хранилище и очередь. Сначала пишите события и фото локально, присваивайте им статус (в очереди, отправлено, ошибка). Затем добавьте фоновую синхронизацию: при появлении сети отправляйте события, потом фото.
Прогоните реальный сценарий и упростите. Возьмите 3-5 заказов, плохую связь, спешку, перчатки. Все лишнее всплывет сразу.
Проверка перед пилотом занимает час, но экономит недели. Обязательно прогоните руками: режим без интернета (события и фото не пропадают и остаются «в очереди»), повторную отправку (одно фото не превращается в два подтверждения) и ошибки (курьер видит понятный статус и понимает, что делать дальше).
Самая частая проблема - попытка учесть все случаи сразу. В итоге курьер видит десяток статусов, не понимает разницу и отмечает «не то», а диспетчер получает шум вместо понятной картины.
Вторая боль - «необязательные» поля. Если фото можно сделать без привязки к заказу, оно быстро превращается в безымянный файл в галерее. Если комментарий можно оставить без причины, его пишут как попало, и вы теряете смысл: почему доставка сорвалась, кто виноват, что делать дальше.
Третья ошибка заметна не в офисе, а на лестничной клетке: фото и события отправляются только онлайн. Связь пропала - курьер нажал «готово», а снимок не ушел. Через час приложение перезапустилось, и доказательство вручения исчезло или «зависло» без понятного статуса.
Четвертая - отсутствие защиты от случайного нажатия. Один тап по «Вручено» без подтверждения, и заказ закрыт, хотя курьер еще в лифте. Потом начинаются звонки, ручные исправления и недоверие к системе.
Пятая - конфликты. Диспетчер поменял адрес или окно времени, а курьер уже начал маршрут по старым данным. Если приложение не умеет аккуратно показывать изменения и просить подтвердить новые детали, появятся спорные доставки.
Чтобы снизить эти риски еще до первого пилота, держитесь простых правил:
Простой пример: диспетчер исправил подъезд, а курьер уже у дома. Приложение должно показать изменение крупно, сохранить старую версию в истории и дать кнопку «Принял изменения». Тогда спорных ситуаций меньше, а поддержка не тонет в разборках.
У курьера и диспетчера разные задачи, но один общий риск: «все сделали», а в системе нет фактов. Этот чек-лист помогает закрыть доставку так, чтобы не было спорных случаев, а фото и статусы не терялись даже без связи.
Перед стартом смены проверьте, что вы авторизованы и список заказов совпадает с планом. Откройте маршрут и убедитесь, что у каждого заказа есть телефон и примечания. Если что-то не сходится, сразу пишите диспетчеру или звоните - это экономит часы.
Перед вручением остановитесь на 10 секунд: сверяйте адрес, подъезд, этаж, домофон и пометки («не звонить, писать», «отдать охране»). Сделайте короткий контакт: звонок или сообщение, и уточните имя, чтобы убедиться, что вы у правильного человека.
В момент вручения фиксируйте обязательное подтверждение: чаще всего это фото вручения или код (если получатель не хочет фото). Если есть нюанс (просят оставить у двери, не открывают, адрес изменился), добавьте комментарий простыми словами. Одно понятное предложение лучше пустого поля.
После вручения проверьте в карточке заказа: статус должен быть «отправлено на сервер» или «ждет отправки», если нет сети. Если связь слабая, нормально, что фото попало в офлайн-очередь, важно только, чтобы оно не зависло без попыток отправки.
В конце дня откройте историю: все заказы закрыты, возвраты отмечены отдельным статусом, а спорные кейсы не висят без комментария и подтверждения. Если есть заказ «не доставлен», у него должны быть причина, отметка времени и действия (звонки, комментарий, фото, если применимо).
Диспетчеру важно видеть не «где курьер», а «что доказано». Проверьте, что по каждому заказу есть события и финальный статус, а по проблемным точкам - причина и следующее действие (повторная попытка, перенос, возврат).
Короткий контрольный список:
Если вы делаете приложение, заложите эти проверки прямо в интерфейс: понятные статусы, подсказки и простые отметки уменьшают ошибки сильнее, чем любые инструкции.
Утро, у курьера 12 доставок. Часть адресов в новостройках с корпусами и подъездами, часть - в офисных центрах с пропускным режимом. Диспетчер заранее загрузил заказы: время, адрес, получателя, телефон, заметку (например, «белые розы, аккуратно»).
Курьер открывает маршрут и по каждой точке видит один главный экран заказа: адрес, кнопку звонка и блок «События». События простые: «выехал», «на месте», «передано», «не удалось». Курьер не путается, а диспетчер понимает ситуацию без лишних звонков.
В середине смены курьер заходит в лифт в новостройке, связь пропадает. Он уже на месте, делает фото букета у двери, выбирает «Передано» и добавляет комментарий: «Передал лично, кв. 215». Приложение подтверждает действие и показывает, что фото и событие попали в офлайн-очередь. Курьер едет дальше, ничего не теряется.
Ближе к обеду клиент в офисе просит оставить букет у охраны. Курьер выбирает причину вручения «Оставлено у охраны/ресепшн», вводит имя охранника и номер стойки, делает фото на фоне ресепшн. Это занимает минуту, но потом снимает почти все вопросы.
Как это выглядит в событиях за один заказ:
Диспетчер в это время видит ленту событий по времени. Как только связь у курьера появляется, фото и подтверждения догружаются, и у каждого финального статуса появляется доказательство.
Начните с того, какие события вы фиксируете по каждой доставке и какие подтверждения обязательны. Это основа, на которой потом держатся маршрут, отчеты и разбор спорных случаев. Для приложения курьера цветов обычно хватает однозначных шагов: заказ принят, выехал, прибыл, не смог связаться, вручено или не вручено.
Дальше определите минимум данных, без которых заказ нельзя провести дальше. Чем меньше полей, тем быстрее работа курьера и меньше ошибок. Полезное правило: если поле не влияет на решение диспетчера или на оплату, оно не должно быть обязательным.
Компактный набор, с которого удобно стартовать:
Офлайн-очередь закладывайте сразу. Курьер может попасть в подъезд без связи или в место с плохим интернетом. Фото и события должны попасть в локальную очередь, получать статус «ожидает отправки» и уходить на сервер при первой возможности. Добавьте понятную подсказку: сколько элементов в очереди и что уже ушло.
Если нужно ускориться, удобно описать требования обычным текстом и собрать черновой прототип на TakProsto (takprosto.ai): перечислите события, обязательные подтверждения, экраны и правила офлайна. Платформа ориентирована на формат «чат -> приложение» и позволяет собрать мобильное приложение на Flutter вместе с серверной частью на Go и базой PostgreSQL, а затем при необходимости выгрузить исходники.
Пилот лучше делать на 2-3 курьерах и одной зоне доставки. За неделю станет видно, что чаще всего мешает: неудобный ввод комментария одной рукой, лишние обязательные поля, непонятно, когда фото «дошло». Упростите именно эти действия, и только потом расширяйте функции.
Начните с спорных ситуаций: что доказывает факт вручения и что объясняет срыв доставки. Затем задайте короткие статусы, список событий и обязательные подтверждения (фото/код/подпись). Этого достаточно, чтобы собрать первый рабочий прототип и не утонуть в деталях.
Обычно хватает пяти: «Принято», «В пути», «На месте», «Вручено», «Не вручено». Они должны означать одно и то же для всех, иначе менеджер получит хаос и спорные закрытия заказов.
Фиксируйте то, что влияет на деньги и ответственность: время, примерную геометку, ключевое событие и подтверждение. Из событий чаще всего нужны звонок клиенту, ожидание с длительностью, перенос адреса/времени, отказ, возврат.
Офлайн важен, потому что связь пропадает в подъездах, лифтах и дворах. Нормальная схема такая: курьер отмечает статус и делает фото, приложение сохраняет это на телефоне и отправляет автоматически, когда интернет появится.
Дайте курьеру минимум: список доставок на смену, карточку заказа, экран подтверждения (камера + комментарий) и журнал событий по заказу. Все дополнительные функции лучше прятать от курьера, чтобы не тормозить работу в полях.
Держите ядро простым: заказ (номер, время, сумма), адрес с подсказками (подъезд, этаж, домофон), получатель (имя, телефон), оплата, комментарии. Так вы закрываете большинство реальных кейсов и не усложняете ввод.
По умолчанию сделайте обязательным минимум одно фото и короткий комментарий, чтобы статус «Вручено» был доказуемым. Если хотите сильнее защититься от споров, добавьте подпись на экране или код подтверждения как обязательное поле.
Сделайте запасной сценарий: код + подпись или код + имя получателя, плюс обязательная причина из списка и короткий комментарий, кому передали. Это сохраняет понятный «след» по заказу, даже если фото запрещено.
Локально храните активные заказы на сегодня, очередь несинхронизированных событий и черновики фото с привязкой к заказу. На сервер отправляйте полный журнал событий и оригиналы фото, чтобы у менеджера была единая история и доказательства.
Сделайте действия «выполненными» сразу локально и показывайте индикатор очереди, например «2 в ожидании». Добавьте повторные попытки отправки и защиту от дублей через уникальный ID попытки, тогда фото не потеряется и не задвоится.
