Система мониторинга доставки собирает фактические статусы рейса: курьер отмечает этап в Telegram, клиент получает уведомление, диспетчер сразу видит отклонение. Headline (headln.ru) реализует этот сценарий на Telegram API, Node.js и Redis, включая серверное размещение и сопровождение.
Обычный чат не даёт надёжной картины смены: сообщение «выехал» теряется, клиент звонит в офис, а диспетчер вынужден уточнять статус у курьера. Кнопки этапов и журнал событий сокращают эту цепочку без обязательной разработки отдельного мобильного приложения.
Как клиент узнаёт статус
Заказ становится заданием. Курьер жмёт кнопку в Telegram. Клиент получает факт. Диспетчер видит смену, а не собирает её звонками.
Заказ к доставке → Кнопки в Telegram → Уведомление клиенту → Экран диспетчера → Аналитика смены
Кому система мониторинга доставки приносит пользу
Службе, у которой рейсы уже идут каждый день, а диспетчер тонет в переписке. Магазину с собственной доставкой. Кухне, которая возит заказы сама. Опту, где машина «где-то едет», а клиент уже ждёт окно. Не стартапу без курьеров и без хозяина рейса: код неспособен создать логистику из слайда.
На сайте Headline это отдельный проект: комплексный контроль курьеров через Telegram-бота, уведомления клиентов, детальная аналитика. Имя службы и тарифы мы не выдумываем. Берём стек и смысл контура. Если нужен не только статус, а рейс, слоты, склады и машины, это уже соседний класс: TMS система на заказ.
Для селлера доставка часто всплывает в момент своего магазина. Площадка прятала статус за комиссией 30–48%. На своём канале статус: ваша операционка. Сначала витрина и заказ, затем мониторинг. Сценарий: интернет-магазин для селлеров и страница ecommerce.
- Курьеры уже в поле, а диспетчер собирает статусы из трёх чатов.
- Клиент узнаёт «где заказ» только после звонка.
- Опоздания видно постфактум, когда отзыв уже написан.
- Нужна аналитика рейсов, но не ощущение «сегодня плохо везли».
Граница между ботом, трекингом и TMS
Коробочный трекинг службы доставки уместен, если вы полностью отдаёте последнюю милю подрядчику и вас устраивает его кабинет. Свой мониторинг нужен, когда курьер ваш, маршрут ваш, обещание окна ваше. Чужой кабинет в таком случае не закроет ваш SLA.
Telegram-бот: быстрый контур для курьера, который и так живёт в мессенджере. Не нужно ставить отдельное приложение, чтобы отметить «забрал» и «доставил». Клиенту уходит статус, диспетчеру: картина смены. Это не замена склада и не замена учёта.
TMS заказывают, когда появляются рейсы, слоты, несколько складов, машины, возвраты. Бот мониторинга может быть первым срезом. Полный TMS: отдельный проект. Путать их: частая ошибка скоупа. Сначала статус и уведомление, затем планирование рейса.
Headline выбирает путь под задачу: готовое, если дешевле, код с нуля, если процесс свой. База: разработка ПО на заказ. Узкий пилот: один тип доставки, одна роль курьера, одно уведомление клиенту. Формат: MVP за 14 дней.
Архитектура мониторинга доставки
Сначала карта рейса, не карта на слайде. Где заказ становится «к доставке», кто назначает курьера, какие статусы клиент имеет право видеть, что считается опозданием, где возврат. Без этого бот станет ещё одним чатом, только с кнопками.
В проекте на сайте: Telegram-бот для курьера, уведомления клиенту, аналитика логистики. Стек: Telegram API, Node.js, Redis. Redis здесь не «модная база». Это статусы и очередь событий, которые должны дойти сразу, но не «когда сервер проснётся». On-Premise, если телефоны клиентов и маршруты не должны уезжать.
Деплой и мониторинг 24/7: бот, который молчит в час пик, хуже отсутствия бота. Сопровождение после запуска: новые статусы, ещё одна служба, другое окно. Чужой контур берём с аудитом. Тема: сопровождение после запуска.
Что должен уметь первый релиз
- Назначение курьера на заказ и понятный статус в одном месте.
- Кнопки курьера в Telegram: принял, забрал, еду, доставил, проблема.
- Уведомление клиенту в тот же система, который вы уже используете.
- Экран диспетчера: кто где, что зависло, что сорвалось.
- Простая аналитика смены: опоздания, закрытые адреса, возвраты.
- Сервер, копии, журнал событий. Иначе разбор инцидента: гадание.
Склад и ячейка: другой слой. Если курьер уехал не с тем, мониторинг опозданий не спасёт. Тогда рядом WMS для склада. Если полевому нужна камера и маршрут в телефоне, не только бот: мобильное приложение на заказ.
Почему чужие статусы не работают
Риск скопировать чужие статусы. У агрегатора своя сетка и свои штрафы. У вас: своё окно и свой клиент. Нужны ваши статусы и ваши эскалации, не чужой скриншот.
Геолокацию следует использовать только с понятной целью и корректным основанием. Точка на карте не заменяет факт «доставил» и фото у двери, если вам это нужно. Сначала факт и уведомление, затем карта, если она закрывает спор.
Если сохранить обходной путь через личные сообщения, бот быстро перестанут использовать. Если курьеру быстрее написать «ок» в личку, бот умрёт зно неделю. Кнопка должна быть быстрее чата. Диспетчер не должен принимать статус из двух мест.
Риск вынести телефоны клиентов в чужой облачный бот «на тест». Персональные данные. Периметр: On-Premise и 152-ФЗ. Тест, который остаётся навсегда в чужом системе: типичная дыра.
Опасен и чрезмерный объём первой версии. Оптимизация маршрутов, ИИ-прогноз опозданий, своя биржа курьеров в первой версии. Внедрение провалится, и сотрудники вернутся в чат. Сначала статус и уведомление. ИИ: когда журнал рейсов уже живой. Тема: внедрение ИИ в бизнес.
- Нет хозяина смены: статусы плодит каждый курьер как хочет.
- Нет критерия опоздания: аналитика будет спором, не цифрой.
- Нет связи с заказом в учёте: бот живёт отдельно от 1С и витрины.
- Нет мониторинга сервера: пик убивает уведомления.
Как встроить мониторинг в уже живую доставку
Не выключают старый чат в первый день, если смена к этому не готова. Параллельно гоняют один тип заказов: например, только город в пределах МКАД или только вечерние слоты. Курьер на пилоте должен закрыть день без второй таблицы.
Клиенту не обещают «как у маркетплейса», если окна у вас другие. Обещают тот статус, который система реально умеет. Ложное «курьер рядом» разрушает доверие быстрее, чем честное «задерживается на 20 минут».
Стык с учётом рисуют сразу. Заказ в 1С или в магазине становится заданием на доставку один раз. Два номера одного заказа: снова звонки. Если учёт дырявый, сначала сопровождение 1С, не новый бот поверх вранья.
Документы возврата и акты расхождения не обязан писать бот. Их собирает шаблон. КонтрактПРО закрывает пакет минутами, если это B2B-отгрузка, не розничная посылка.
Инфраструктура: бот и Redis не живут на личном ноутбуке разработчика. Копии, доступы, мониторинг. Статья: обслуживание серверов. Для склада в Петербурге часто один подрядчик: IT-аутсорсинг.
Если курьер уже пропадает в чате, в письме достаточно: сколько рейсов в день, чем сейчас ловите статус, и что клиент должен увидеть сам.
Как измерить пользу мониторинга за смену
Успех мониторинга: диспетчер не собирает статусы звонками, клиент видит тот факт, который курьер реально нажал, опоздание всплывает в смене, но не в отзыве на следующее утро. Если этих трёх вещей нет, бот: декорация.
Считают простые числа. Доля заказов без звонка «где курьер». Время от кнопки «доставил» до уведомления. Число рейсов, которые закрыли день без второй таблицы. Без счётчика вы будете спорить о вкусе интерфейса.
Стык с витриной и учётом проверяют на одном заказе. Номер в магазине, номер в боте, номер в 1С: один. Если три, офис снова станет коммутатором. Для прямых продаж селлера это тот же урок, что на странице ecommerce: канал ваш, операционка тоже ваша.
После стабильного статуса можно думать о рейсе и слоте. Не раньше. Иначе TMS унаследует враньё мониторинга. Связка: TMS система на заказ. Юридический документ перевозки это отдельная тема: электронная транспортная накладная идёт через оператора ЭПД.
Частые вопросы
Что вы называете системой мониторинга доставки?
Система, в котором курьер фиксирует статус, клиент получает уведомление, диспетчер видит смену, но не собирает её из чатов. В опубликованном проекте это Telegram-бот, уведомления и аналитика логистики.
Почему Telegram, но не отдельное приложение?
Курьер и так в мессенджере. Кнопка статуса должна быть быстрее лички. Отдельное приложение имеет смысл, когда нужны камера, маршрут и офлайн. Это уже мобильная разработка, не первый срез мониторинга.
Это уже TMS?
Нет. Мониторинг закрывает статус и видимость рейса. TMS планирует рейсы, слоты, машины, склады. Часто начинают с бота, затем растят TMS, если появляется планирование.
Можно проверить гипотезу за 14 дней?
Да, на одном типе доставки и одном уведомлении клиенту. Вся биржа курьеров и оптимизация города в этот срок не входят.
Если статус заказа ещё собирают звонками, напишите на welcome@headln.ru: сколько рейсов, какой мессенджер у курьеров и что клиент должен видеть сам.