Чому бот трекінгу доставки ламається на піку замовлень
Поки замовлень десятки, бот трекінгу доставки працює непомітно: кур'єрська служба надсилає подію, застосунок змінює статус, клієнт отримує сповіщення.
На піку — сезон, розпродаж, масове відвантаження — потік подій зростає в рази, і першими ламаються не екрани, а зв'язки між системами: частина оновлень не доходить, частина надходить повторно, частина застрягає в черзі й виринає через години.
Перший збій — розсинхронізація статусів. Служба доставки віддає оновлення асинхронно, а статуси замовлення в застосунку збираються з кількох джерел: склад, кур'єр, пункт видачі.
Якщо події застосовуються не в тому порядку — «доставлено» надходить раніше за «передано кур'єру» — у картці залишається проміжний стан. Клієнт бачить «у дорозі» там, де посилка вже чекає в пункті, і йде в підтримку.
Другий — дублі сповіщень про доставку. При збої приймач відповідає помилкою, служба повторює надсилання, і без унікального ідентифікатора події те саме оновлення обробляється двічі: два сповіщення підряд за одним замовленням.
Третій — застряглі замовлення: подія загубилася, замовлення назавжди залишилося в активних, і перевести його у фінальний статус може лише оператор вручну.
Чим вищий пік, тим помітніша частка таких замовлень і тим сильніше зростає потік звернень — підтримка витрачає час не на клієнтів, а на звіряння даних між панеллю служби та застосунком.
Розбираємо, як це закривається: ідемпотентна обробка подій, звіряння за розкладом як страховка від втрат і явні правила переходу між статусами.
Що змінюється після вбудовування трекінгу в застосунок
Поки статус доставки живе в кабінеті перевізника, застосунок залишається вітриною: про затримку клієнт дізнається останнім — з листа або після дзвінка в підтримку.
Вбудований трекінг робить зміну статусу подією всередині застосунку, і ефект перестає бути «стало зручніше» — його рахують за метриками до й після запуску.
- Частка автоматичних статусів. Вебхуки та періодичне опитування замість ручного введення: 92–97% переходів «створено — у дорозі — у кур'єра — доставлено» надходять без оператора.
- Час реакції на відхилення. Події «затримка» або «не додзвонилися» доходять до черги оператора за 30–60 секунд, а не через години після дзвінка клієнта — повернення встигають запобігти.
- Навантаження на підтримку. Звернення «де моя посилка» закриваються екраном замовлення з трек-номером і статусом, їхня частка падає в 2–3 рази, а зміна перемикається на повернення та претензії.
- Час доставки. Нагадування про прибуття в пункт і за день до візиту кур'єра зменшує кількість невдалих спроб вручення — строк до клієнта скорочується на 8–15%.
- Сценарії сповіщень. Канал і шаблон для кожного переходу: сповіщення в застосунку на зміну статусу, лист на відмову, тихі години, дедуплікація повторів; тексти редагуються налаштуванням, без релізу.
- Клас відмов, що пішов. Збій інтерфейсу перевізника більше не втрачає статус: події стають у чергу й повторюються зі зростаючою паузою, розбіжності звіряються з СДЭК за трек-номером.
Метрики знімаємо до старту робіт і повторно через місяць після запуску — за вивантаженням подій, а не за відчуттями.
Способи сповіщення про статуси замовлення: порівняння підходів
Вибір способу сповіщення визначає, де користувач дізнається статус замовлення: у застосунку, у месенджері чи в листі від кур'єрської служби.
На практиці канали комбінують: сповіщення в застосунку закривають основні сценарії, месенджер-бот підстраховує тих, хто застосунок видалив, а інтеграція з кур'єрськими службами дає дані, яких у нас немає, — номер накладної, факт передачі кур'єру та вручення.
Обмеження сервісів важливіші за їхні можливості: кожен канал диктує свої правила щодо шаблонів повідомлень, частоти надсилання та підтвердження номера телефону — наприклад, СДЭК віддає події лише за своїми відправленнями і у своєму форматі. Нижче — варіанти, між якими реально обирають під час запуску бота трекінгу доставки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний сервіс сповіщень у застосунку | Користувач установив застосунок і дозволив сповіщення | Канал замовкає після видалення застосунку; статус залишається лише у вебкабінеті |
| Бот у месенджері | Аудиторія живе в месенджері й не хоче ставити застосунок | Прив'язка за номером, ліміти на розсилки, шаблони на боці платформи |
| Сповіщення від кур'єрської служби | Потрібен мінімум розробки, доставка однією-двома службами | Чужий бренд у повідомленні, різний формат подій, немає статусів до передачі кур'єру |
| Агрегатор доставки | Кілька служб і єдиний статус для клієнта | Затримка синхронізації, частина тарифів поза інтеграцією, залежність від чужого збою |
| Ручні статуси оператора | Нестандартні замовлення: великогабарит, власний водій, доставка в день замовлення | Не масштабується, статус надходить із затримкою, формулювання розходяться |
Етапи вбудовування трекінгу: від аудиту до передачі
Трекінг ламається не на карті, а на узгодженні статусів між складом, кур'єром і службою доставки. Користувач третій день бачить «у дорозі», підтримка відповідає на те саме, а сповіщення надходить після того, як кур'єр поїхав. Вибудовуємо роботу так, щоб розбіжності спливали на стенді, а не у відгуках.
- Аудит статусів. Збираємо системи, які знають про замовлення: облікову, складську, службу доставки, застосунок кур'єра. Їхні коди станів зводимо в одну таблицю відповідності — одразу видно, які статуси надходять із затримкою, а які не надходять узагалі.
- Схема потоків даних. Визначаємо, як подія доходить до телефона: опитування зовнішнього сервісу, вхідний сигнал або проміжне сховище. На схемі позначено, де подія губиться при обриві зв'язку і як часто опитувати джерело.
- Правила сповіщень. Домовляємося, які статуси бот повідомляє одразу, які накопичуються в стрічці замовлення, а які не показуємо зовсім. Одна подія — одне повідомлення, навіть якщо воно надійшло з двох джерел.
- Перевірка на реальних замовленнях. Проганяємо справжні й тестові замовлення: чи збігся статус, чи вчасно надійшло сповіщення, що бачить людина при скасуванні та поверненні. Окремо — втрата мережі та застосунок у фоні.
- Передача проєкту. Віддаємо таблицю статусів, схему потоків, правила сповіщень та інструкцію з підключення нового перевізника. Розбираємо на живому замовленні, щоб правку можна було внести без нас.
Кожен етап закінчується артефактом: таблицею, схемою або прогоном на даних. На прийманні видно не «працює», а що саме перевірено.
Конфігурації, схеми та регламенти: що залишається у команди
Після запуску бота трекінгу доставки в команди мають залишитися артефакти, а не усні домовленості.
Усе, що стосується надсилання сповіщень, обміну даними зі службами доставки та доступу до замовлень клієнтів, фіксуємо письмово — цього достатньо, щоб розвивати продукт власними силами або передати його іншій команді без втрати контексту.
- Налаштування сервісу сповіщень — шаблони повідомлень за кожним статусом, порядок каналів, тихі години та поведінка при недоступності зовнішньої розсилки.
- Схеми інтеграцій — карта обміну між застосунком, ботом і службами доставки: де запитуємо статуси, де приймаємо вхідні сповіщення, як зіставляються номери відправлень.
- Політики доступу — ролі в панелі керування, права на ручне надсилання та повтор, порядок ротації ключів.
- Регламент обробки збоїв — що робити, якщо статус не надійшов, продублювався або запізнився; хто розбирає звернення і в який строк.
- Журнали подій і метрики — частка доставлених сповіщень, затримка між зміною статусу та повідомленням, список нерозібраних конфліктів.
- Документація — опис сценаріїв, інструкція для підтримки, порядок випуску та відкат версії бота.
Артефакти оновлюємо при кожній зміні й зберігаємо поруч із кодом, а не в листуванні. Перевірка проста: ваш інженер або нова команда за цими матеріалами збирають версію та розбирають типовий збій без питань до нас.
Кейс: трекінг доставки зняв навантаження зі служби підтримки
Замовник — мережа доставки «Северный маршрут» з власним парком кур'єрів. У застосунку клієнт бачив один рядок «у дорозі» до самого вручення: зміна кур'єра, перенесення вікна та повторний виїзд ніде не відображалися.
Навантаження лягало на підтримку — звернення за статусом замовлення займали близько 40% вхідного потоку.
Що зробили
Бот трекінгу доставки підключили напряму до подій облікової системи: кожен стан відправлення перетворюється на подію з ідентифікатором, типом і міткою часу.
Далі працює матриця сповіщень — які події йдуть клієнту, з якою затримкою та яким каналом, з дедуплікацією повторів і відкатом на резервний канал при недоставці. Застосунок читає статус із того самого потоку подій, тому екран і сповіщення не суперечать одне одному.
| Метрика | До | Після |
|---|---|---|
| Статуси, що надходять автоматично | 22% | 96% |
| Звернення за статусом на 1000 доставок | 63 | 11 |
| Відповідь клієнту за статусом замовлення | 2–4 години | менше хвилини |
| Сповіщення з помилковим статусом | 7% | 0,4% |
Через два місяці підтримка перестала бути єдиним джерелом правди про замовлення: клієнт дізнається про відхилення раніше, ніж відкриває чат. Звільнений ресурс операторів пішов на складні випадки — пошкодження, спори щодо адреси, повернення.
Чим трекінг доставки в застосунку відрізняється від зовнішнього сервісу?
Зовнішній сервіс віддає готовий статусний рядок і знімає з вас інтеграцію з перевізниками, але події йдуть через чужий вузол. Ви бачите те, що сервіс вважав за потрібне передати, у його форматі та з його затримкою.
Власний трекінг доставки будується на прямому обміні з програмними інтерфейсами перевізників — від приймання замовлення до вручення.
Швидкість оновлення статусів залежить від способу отримання подій. Зовнішній сервіс частіше опитує перевізників за розкладом, тому між фактичним скануванням і показом статусу в застосунку проходить помітна пауза.
Власний контур приймає події в момент їх надсилання, а повторні спрацювання гасяться за ключем — статус не смикається назад і не дублюється в історії замовлення.
Контроль над даними — друга відмінність.
Власна історія статусів лежить у вас: її можна перезібрати при зміні моделі замовлення, вивантажити для розбору строків доставки, звести кількох перевізників в одну шкалу й не залежати від того, скільки сервіс зберігає архів і як називає етапи.
Гнучкість сценаріїв сповіщень з'являється там, де тригери описані вами. Поріг «залишилося дві зупинки», тихі години за часовим поясом отримувача, різні тексти для кур'єра й клієнта, ескалація при застряглому статусі — це правила на вашому боці, а не набір готових галочок. Сповіщення бота трекінгу доставки в цьому разі теж живуть у вашому контурі.
Вартість володіння зміщується: зовнішній сервіс економить запуск, але додає постійну залежність — його збій або зміна умов стають вашим простоєм. Власний трекінг потребує роботи на вході, зате витрати передбачувані, а доопрацювання виходять у вашому темпі.
Технічні питання: надійність, доступи, збої та метрики
Інженерні сумніви навколо бота трекінгу доставки зазвичай ті самі: недоступність служби доставки, права на дані замовлень, перевірка сценаріїв до виходу в прод і межі відповідальності після передачі. Нижче — відповіді в тому вигляді, у якому вони потрібні для технічного рішення.
Фіксуємо їх у документації до старту: схема потоків статусів, матриця доступів, набір перевірок, регламент передачі. Тоді надійність сповіщень і відповідальність — не предмет домовленостей на словах.
Що відбувається зі сповіщеннями, якщо служба доставки недоступна?
Черга подій зберігає статуси локально, надсилання повторюється з наростаючою затримкою, дублі відсікаються за ідентифікатором події та версією статусу. Користувач отримує одне сповіщення на перехід, а не серію повторів після збою.
Які права потрібні боту на дані замовлень?
Читаємо лише поля, потрібні для статусу: номер замовлення, поточний етап, планова дата, контакт отримувача. Доступ іде службовим обліковим записом із коротким строком життя ключа, персональні дані маскуються в логах.
Як тестується трекінг до появи реальних замовлень?
Пісочниця підміняє відповіді служби доставки: проганяємо рідкісні гілки — скасування після збирання, повернення, часткову видачу, тривалу затримку. Кожен сценарій — окрема перевірка, покриття гілок іде у звіт.
Що змінюється після передачі проєкту?
Передаємо конфігурації, схеми інтеграції, тести та інструкції щодо типових збоїв; супровід продовжується в узгодженому режимі. Відповідальність за логіку бота та робочі перевірки закріплена письмово.
Обговоримо задачу: розберемо ваші статуси та сценарії
Щоб оцінка робіт спиралася на вашу реальність, а не на середні припущення, потрібні вхідні дані щодо проєкту: як зараз влаштований шлях замовлення і де бот трекінгу доставки має в нього вбудуватися. З мінімальним набором нижче ми повертаємося з планом упровадження та строками за етапами.
- Список статусів доставки так, як їх бачить клієнт, і правила переходів: де закінчується «у дорозі», що означає «у пункті видачі», що вважається скасуванням або поверненням.
- Джерело подій — облікова система, склад або служба доставки — і чи є в нього програмний інтерфейс для читання, чи статуси проставляють люди вручну.
- Канали сповіщень: повідомлення в месенджері, миттєві сповіщення в застосунку, пошта; чи потрібне дублювання і чи може отримувач вимкнути розсилку.
- Ролі та сценарії: хто отримує повідомлення і чи потрібні зворотні дії — перенесення дати, підтвердження адреси, зв'язок із кур'єром.
- Обсяги: скільки замовлень на добу в середньому та на піку, скільки сповіщень припадає на одне замовлення — від цього залежить схема черг і захист від повторів при збоях.
- Готові шаблони повідомлень і вимоги до подання: мова, тон, локалізація, підстановка даних отримувача.
- Доступи до тестового контуру й тестових записів — без них наскрізний сценарій не перевірити.
Опишіть задачу у вільній формі, навіть якщо частину вхідних даних ще не зібрано: те, чого бракує, уточнимо запитаннями. Повернемося з оцінкою робіт і планом упровадження, де видно етапи, залежності та точки приймання.
