Разработка бота для трекинга доставки в мобильном приложении

Почему бот трекинга доставки ломается на пике заказов

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

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

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

Разбираем, как это закрывается: идемпотентная обработка событий, сверка по расписанию как страховка от потерь и явные правила перехода между статусами.

Что меняется после встраивания трекинга в приложение

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

• Доля автоматических статусов. Вебхуки и периодический опрос вместо ручного ввода: 92–97% переходов «создан — в пути — у курьера — доставлен» приходят без оператора.
• Время реакции на отклонение. События «задержка» или «не дозвонились» доходят до очереди оператора за 30–60 секунд, а не через часы после звонка клиента — возврат успевают предотвратить.
• Нагрузка на поддержку. Обращения «где моя посылка» закрываются экраном заказа с трек-номером и статусом, их доля падает в 2–3 раза, а смена переключается на возвраты и претензии.
• Время доставки. Напоминание о прибытии на пункт и за день до визита курьера снижает число неудачных попыток вручения — срок до клиента сокращается на 8–15%.
• Сценарии уведомлений. Канал и шаблон под каждый переход: уведомление в приложении на смену статуса, письмо на отказ, тихие часы, дедупликация повторов; тексты правятся настройкой, без релиза.
• Ушедший класс отказов. Сбой интерфейса перевозчика больше не теряет статус: события встают в очередь и повторяются с растущей паузой, расхождения сверяются с СДЭК по трек-номеру.

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

Способы оповещения о статусах заказа: сравнение подходов

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

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

Этапы встраивания трекинга: от аудита до передачи

Трекинг ломается не на карте, а на согласовании статусов между складом, курьером и службой доставки. Пользователь третий день видит «в пути», поддержка отвечает на одно и то же, а уведомление приходит после того, как курьер уехал. Выстраиваем работу так, чтобы расхождения всплывали на стенде, а не в отзывах.

1. Аудит статусов. Собираем системы, которые знают о заказе: учётную, складскую, службу доставки, приложение курьера. Их коды состояний сводим в одну таблицу соответствия — сразу видно, какие статусы приходят с задержкой, а какие не приходят вовсе.
2. Схема потоков данных. Определяем, как событие доходит до телефона: опрос внешнего сервиса, входящий сигнал или промежуточное хранилище. На схеме отмечено, где событие теряется при обрыве связи и как часто опрашивать источник.
3. Правила уведомлений. Договариваемся, какие статусы бот сообщает сразу, какие копятся в ленте заказа, а какие не показываем совсем. Одно событие — одно сообщение, даже если оно пришло из двух источников.
4. Проверка на реальных заказах. Прогоняем настоящие и тестовые заказы: совпал ли статус, вовремя ли пришло уведомление, что видит человек при отмене и возврате. Отдельно — потеря сети и приложение в фоне.
5. Передача проекта. Отдаём таблицу статусов, схему потоков, правила уведомлений и инструкцию по подключению нового перевозчика. Разбираем на живом заказе, чтобы правку можно было внести без нас.

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

Конфигурации, схемы и регламенты: что остаётся у команды

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

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

Артефакты обновляем при каждом изменении и храним рядом с кодом, а не в переписке. Проверка простая: ваш инженер или новая команда по этим материалам собирают версию и разбирают типовой сбой без вопросов к нам.

Кейс: трекинг доставки снял нагрузку со службы поддержки

Заказчик — сеть доставки «Северный маршрут» с собственным парком курьеров. В приложении клиент видел одну строку «в пути» до самого вручения: смена курьера, перенос окна и повторный выезд нигде не отражались. Нагрузка ложилась на поддержку — обращения по статусу заказа занимали около 40% входящего потока.

Что сделали

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

Через два месяца поддержка перестала быть единственным источником правды о заказе: клиент узнаёт об отклонении раньше, чем открывает чат. Освободившийся ресурс операторов ушёл на сложные случаи — повреждения, споры по адресу, возвраты.

Чем трекинг доставки в приложении отличается от внешнего сервиса?

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

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

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

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

Стоимость владения смещается: внешний сервис экономит запуск, но добавляет постоянную зависимость — его сбой или смена условий становятся вашим простоем. Свой трекинг требует работы на входе, зато расходы предсказуемы, а доработки выходят в вашем темпе.

Технические вопросы: надёжность, доступы, сбои и метрики

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

Фиксируем их в документации до старта: схема потоков статусов, матрица доступов, набор проверок, регламент передачи. Тогда надёжность уведомлений и ответственность — не предмет договорённостей на словах.

Какие права нужны боту на данные заказов?

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

Как тестируется трекинг до появления реальных заказов?

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

Что меняется после передачи проекта?

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

Обсудим задачу: разберём ваши статусы и сценарии

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

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

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