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