Розробка мобільного додатка для кур'єрської служби (кур'єр)

Мобільний застосунок кур'єра: де ламається доставка

Збій під час доставки рідко виглядає як відмова сервера. Частіше це кур'єр біля зачиненого під'їзду, який набирає диспетчера й диктує номер квартири: у мобільному застосунку кур'єра адреса згорнулася в короткий рядок без під'їзду, поверху й коду домофона. Кожен такий дзвінок — хвилини простою, а за зміну набирається близько години.

Окрема історія — робота без зв'язку. Підземний паркінг, ліфтова шахта, склад із металевих панелей: застосунок втрачає мережу разом із відкритою заявкою.

Кур'єр не може підтвердити вручення, статус залишається незмінним, замовлення висить «у дорозі», а клієнт телефонує в підтримку. Без збереження стану на пристрої та його надсилання після відновлення мережі втрачається не позначка, а сам факт доставки.

Ручні статуси ламають картину ще раніше: кур'єр позначає «доставлено» наприкінці зміни, з пам'яті або за папірцем.

Диспетчер до вечора не знає, вручено замовлення чи ні — звідси повторні виїзди за однією адресою, спірні ситуації з клієнтом і розбіжність між фактичними врученнями та звітом.

Адресна навігація кур'єра тримається на деталях, які зазвичай не переносять у застосунок: номер під'їзду, поверх, код домофона, орієнтир біля двору. Якщо їх немає, кур'єр перепитує щоразу — це повільніше, ніж прокласти маршрут за збереженою точкою входу.

Закриття замовлення рветься там само: знімок накладної, підтвердження оплати та зміна статусу розведені по різних екранах, і кур'єр закриває заявку формально, а докази досилає потім.

Кожен такий розрив — хвилини простою, зайві кілометри й дзвінки, яких не повинно бути. Розбираємо, як це закривається.

Вимірюваний ефект: тривалість зміни та точність адреси

Метрики фіксуємо до старту, інакше ефект нічим підтвердити. Базову лінію знімаємо на поточному контурі за два-три тижні: за кожною зміною рахуємо час зміни кур'єра — від першого переходу в статус «на зміні» до закриття останнього замовлення, з вирахуванням простоїв з вини складу. Той самий інтервал потім порівнюємо один в один.

Повторні виїзди відокремлюємо від первинних: це адреса, куди кур'єр повернувся через неповні дані про одержувача, недоступний телефон або відсутність людини.

Кожен такий виїзд — подвійний пробіг і зсув інших точок у маршруті, тому рахуємо їхню частку від загальної кількості доставок за зміну, а не абсолютне число.

Дзвінки диспетчеру на сто замовлень — непрямий показник навантаження на диспетчера.

Їх беремо з журналу викликів і зіставляємо зі змінами: видно, скільки звернень спричинено уточненням адреси, а скільки — технічними збоями застосунку, і це різні статті, які закриваються по-різному.

Частка успішних доставок рахується за подіями застосунку з позначками часу та геопозицією — тобто за доставками з підтвердженням вручення, а не за формально закритим статусом.

У знаменник ідуть усі видані кур'єру замовлення, включно зі скасованими та поверненими на склад, інакше показник лестить і не годиться для порівняння.

Щоб порівняння було чесним, тримаємо однаковими склад змін, зони та типові маршрути, а сезонні сплески враховуємо поправкою. Далі ці показники йдуть у панель моніторингу й оновлюються автоматично — відхилення видно протягом дня, а не за підсумками кварталу.

Варіанти доставки замовлень на пристрій кур'єра

Вибір визначається тим, наскільки сильно ваш процес доставки відрізняється від типового і як швидко кур'єри мають отримати замовлення в полі.

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

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

Етапи проєкту: аудит, схема, збірка, перевірка, передача

Аудит процесів доставки починається не з екранів, а зі спостереження за зміною: як кур'єр отримує наряд, скільки разів телефонує диспетчеру, за яких умов закриває точку і що робить у разі відмови клієнта.

На виході — карта поточних маршрутів, заміри часу на точку та перелік місць, де ручні дії з'їдають робочі години.

1. Аудит процесів доставки. Виїжджаємо з кур'єрами, фіксуємо приймання наряду, зв'язок із диспетчером, підтвердження вручення, повернення та передачу зміни. Окремо перевіряємо покриття мережі, старі пристрої та роботу в рукавичках — від цього залежить, які дії взагалі можна вішати на екран.
2. Схема маршрутів і статусів. Описуємо стани замовлення та допустимі переходи між ними, правила збору точок у маршрут, поведінку при відмові, перенесенні доставки й повторному врученні. Схема узгоджується зі службою до початку збірки, щоб логіка диспетчера і застосунку не розходилися.
3. Збірка. Навігація, офлайн-режим для підвалів і під'їздів, надсилання фото-підтвердження, обмін даними з обліковою системою служби. Перший прототип проходить перевірку на знеособлених нарядах минулих змін — навантаження й маршрути беруться реальні, а не вигадані.
4. Пілотна зміна. Кілька кур'єрів в обмеженому районі, диспетчер працює в обох контурах одночасно. Дивимося частку нарядів, закритих без дзвінка диспетчеру, час на точку та кількість розбіжностей з обліковою системою.
5. Розбір результатів. Правки за гарячими точками, повторний прогін на тій самій групі, фіксація цільових значень метрик. Якщо пілот не сходиться з розрахунковими показниками, контур відкочується на паперову схему — служба не залишається без робочого процесу.
6. Передача проєкту. Схема розгортання, доступи, регламент оновлень, інструкції для кур'єрів і диспетчерів, навчання відповідального з боку служби. Далі — узгоджений період супроводу й оновлення після змін у тарифах або зонах доставки.

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

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

• Регламент оновлення — де збирається версія, які перевірки проходить, як викладається спочатку на пілотну групу кур'єрів, потім на всіх. Зазначено, хто ухвалює рішення про викладку і в які години її робити, щоб не зловити хвилю скарг у розпал зміни.
• Відкат версії — як повернути попередню збірку, якщо після оновлення ламається приймання замовлень або трекінг, і за скільки хвилин це проходить без втрати даних за активними доставками.
• Права доступу — матриця ролей: хто бачить замовлення, хто змінює зони й тарифи, хто викладає релізи; окремо — порядок видачі та відкликання доступів при звільненні.
• Журнал дій — де дивитися, хто і коли змінював налаштування, скасовував замовлення або видавав роль, щоб розбір інциденту не перетворювався на пошук винуватого навмання.
• Документація передачі — структура проєкту, схеми даних, інтеграції з картами й телефонією, список зовнішніх сервісів та відповідальних за них з боку служби.
• Доступи й секрети — облікові записи, ключі інтеграцій і сертифікати, переоформлені на службу, а не на нас.

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

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

Служба доставки Скороход — кілька сотень кур'єрів, паперові маршрутні листи й рація: диспетчер обдзвонював кожного, щоб закрити адресу або переназначити замовлення.

Пілотне впровадження запустили на групі з 40 кур'єрів, друга група залишилася контрольною — метрики до й після рахувалися на одному потоці замовлень і одній сезонності.

Замір до пілоту: зміна тривала в середньому 9 годин 40 хвилин при нормі маршруту 7 годин. Без дзвінка диспетчеру закривалося 46% замовлень — кур'єр не міг позначити статус, якщо адреса недоступна або клієнт просить перенести доставку.

Повторні виїзди становили 11%: адреса в листі розходилася з фактичною, а правку вносили через диспетчера лише наступного дня.

Що змінили в застосунку

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

Що змінилося за метриками

Зміна скоротилася до 7 годин 15 хвилин — мінус третина за тієї самої кількості замовлень на кур'єра. Частка замовлень без дзвінка диспетчеру зросла з 46% до 89%, повторні виїзди впали з 11% до 3%: правки адреси вносяться в момент доставки, а не наступного дня.

Після пілоту на застосунок перевели весь парк, а контрольна група перейшла на нього без доопрацювань.

Що робити, якщо служба вже працює в готовому сервісі доставки?

Служба, що виросла всередині готового сервісу доставки, упирається в стелю: правила розподілу замовлень задає платформа, статуси й розрахунки з кур'єром живуть за її логікою, а зв'язок із вашим обліком іде лише через вивантаження.

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

Перенесення історії замовлень починається з вивантаження: замовлення, адреси, позначки часу за кожним статусом, виконавець, причина скасування.

Дані приводимо до однієї схеми й завантажуємо у свою базу — історія потрібна не для звітності, а для розрахунку тарифів, розбору спірних доставок і перевірки нових правил розподілу на минулих змінах.

Паралельна робота двох контурів тримається на джерелі замовлення: у кожної заявки є зовнішній номер, за ним працює захист від дублів, а кур'єр бачить єдиний список завдань незалежно від того, звідки надійшло замовлення.

Такий режим тримаємо 2-6 тижнів — поки час доставки й частка виконаних замовлень на своєму контурі не зрівняються з показниками платформи.

Навчання виконавців іде пілотною групою з 10-15 кур'єрів: зміни в новому застосунку, розбір офлайн-режиму й спірних адрес, правки за кожним екраном. Далі переводимо решту по бригадах, щоб на зв'язку завжди залишалася група, яка працює за старою схемою.

Відкат влаштований просто: свій контур зберігає дані як джерело істини, тому повернення — це перемикання джерела заявок, а не відновлення історії. Опишіть, як влаштована ваша служба, — повернемося з оцінкою та планом переходу.

Часті технічні сумніви перед стартом проєкту

Кур'єр працює в підвалі, в ліфті, у промзоні за містом — зв'язок зникає на хвилини, а зміна не зупиняється. Нижче запитання, які найчастіше ставлять до старту: відповіді на них визначають архітектуру застосунку, а не косметику інтерфейсу.

Як оновлювати застосунок, якщо кур'єр уже в зміні?

Обов'язкові версії викочуються у вікні між замовленнями: застосунок перевіряє оновлення при поверненні на головний екран і не дає взяти нове замовлення на застарілій збірці.

Активні замовлення при цьому доводяться до кінця — оновлення не вибиває кур'єра зі зміни на середині доставки.

Як застосунок стикується з обліковою системою замовника?

Через програмний інтерфейс: наш шар відповідає за синхронізацію замовлень, статусів і нарахувань, а ваша облікова система залишається джерелом істини.

Якщо готового інтерфейсу немає, розбираємо обмін файлами за розкладом — повільніше, але запускається без доопрацювань на вашому боці.

Які дані кур'єра й клієнта доступні диспетчеру?

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

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

Точність оцінки застосунку кур'єра залежить не від кількості екранів, а від повноти опису поточних процесів: як розподіляються замовлення, хто змінює статуси, як рахується винагорода.

Якщо ці дані є на старті, ми одразу бачимо обсяг інтеграцій і не переробляємо логіку в середині роботи.

Щоб повернутися з оцінкою й планом, а не із загальними словами, достатньо надіслати те, що вже використовується в щоденній роботі:

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

Цього достатньо, щоб обговорити задачу предметно й повернутися з оцінкою та планом: обсягом робіт, порядком етапів і датою старту проєкту. Підготовка даних з боку замовника зазвичай іде паралельно проєктуванню й не затримує початок.