Вопрос «где мой груз» снимается не колл-центром и не наймом ещё одного диспетчера, а тем, что данные о движении рейса начинают доходить до клиента сами. Технически это два разных инструмента с разной ценой и разной отдачей: уведомления по событиям, которые компания отправляет сама, и личный кабинет, куда клиент заходит, когда ему нужны подробности. Первое стоит около 210 000 ₽ и окупается за квартал, второе — от 380 000 ₽ и окупается годами, но нужно по другим причинам.
Главное препятствие при этом не техническое. У перевозчика внутри рейса живёт полтора-два десятка состояний: «на расчёте», «ждёт подтверждения ставки», «машина ищется», «водитель назначен», «выехал под погрузку», «на погрузке», «загружен, ждёт документы», «в пути», «на отстое», «в очереди на выгрузку» и так далее. Показать это клиенту нельзя — он не поймёт разницы между «на отстое» и «в очереди», а спрашивать станет чаще. Задача — свести всё к шести состояниям, за каждым из которых стоит однозначное событие.
Считать будем на модельной компании: 900 отправлений в месяц, три диспетчера, смешанная работа — городская развозка и межгород, телематика на своих машинах есть, наёмные машины идут без неё. Час диспетчера в полной стоимости — 650 ₽. Базовый контур заявок и рейсов у компании уже наведён: без него статусы брать неоткуда.
Шесть статусов, которые видит клиент
Правило перехода одно: статус двигается только вперёд и только событием. Ручной перевод логистом возможен, но фиксируется отдельно с причиной — потому что каждый ручной перевод означает, что событие не пришло, и это надо чинить, а не заминать.
| Статус | Что видит клиент | Чем открывается | Типичная ошибка |
|---|---|---|---|
| 1. Заявка принята | «Заявка 4718 принята, ставка подтверждена, плановая подача 12 сентября» | Перевод заявки в работу в реестре | Статус ставится при получении письма, до подтверждения ставки — клиент считает заявку согласованной |
| 2. Машина назначена | «Назначена машина, госномер, водитель и телефон, подача к 09:00» | Привязка машины и водителя к рейсу | Назначение меняют, а клиенту уходит первый вариант — приезжает другой водитель |
| 3. Погрузка | «Машина на погрузке» | Вход в геозону погрузки плюс отметка водителя | Ставится по геозоне без отметки: машина стоит в очереди, клиент думает, что грузят |
| 4. В пути | «В пути, расчётное прибытие 14 сентября, 10:30–13:30» | Выход из геозоны погрузки, ETA пересчитывается по треку | Обещается точное время вместо интервала — любое отклонение читается как срыв |
| 5. Прибытие | «Машина на месте выгрузки» | Вход в геозону выгрузки | Не отделяется от выгрузки: клиент ждёт закрытия, а машина три часа в очереди |
| 6. Выгружено, документы приняты | «Выгружено, экземпляр накладной подписан» | Отметка водителя и фото подписанной накладной либо подписание в ЭДО | Ставится по одной отметке водителя — рейс «закрыт», а документов нет |
Шестой статус стоит отдельного внимания: он единственный, который клиенту важен меньше, чем вам. Именно с него начинается цепочка «документы — счёт — деньги», и если он ставится по устной отметке водителя, вы получаете красивую систему статусов и всё ту же заморозку оборотных средств. Как связать закрытие рейса с фактическим комплектом документов, разбираем в соседнем материале.
Откуда берётся статус и кому верить при расхождении
Источников четыре, и надёжного среди них нет ни одного. Работающая схема строится не на выборе лучшего источника, а на их сочетании: один открывает статус, другой подтверждает.
| Источник | Что подтверждает надёжно | Задержка | Слабое место |
|---|---|---|---|
| Отметка водителя в чате | Факт действия: прибыл, загрузился, выехал, выгрузился | От минут до конца смены | Отмечает пачкой вечером, «задним числом» — по такому потоку статус клиенту показывать нельзя |
| Телематика, геозона | Факт нахождения машины в точке | 2–10 минут | Не отличает прибытие от стояния в очереди у ворот; на наёмной машине телематики обычно нет |
| Отметка склада или WMS клиента | Факт приёмки груза | От часа до конца дня | Есть далеко не у всех клиентов и требует отдельной интеграции на каждого |
| Оператор ЭДО | Юридический факт подписания документа | Минуты | Работает только на последнем статусе и только с теми, кто уже перешёл на электронные документы |
Правило разрешения расхождений, которое мы используем: геозона открывает статус, отметка водителя его подтверждает. Если геозона сработала, а отметки нет дольше 40 минут — задача логисту: скорее всего, машина в очереди, и клиенту рано показывать «прибытие». Если отметка есть, а геозоны нет, — это либо наёмная машина без телематики, и тогда отметка единственный источник, либо отметка поставлена заранее, и это повод посмотреть на конкретного водителя. Расхождения полезно считать: их доля — прямой показатель качества данных, на которых работают и статусы, и ETA, и планирование.
Карта с движущейся машиной выглядит эффектно и почти всегда создаёт больше обращений, чем снимает. Клиент видит, что машина стоит сорок минут, и звонит спросить почему; видит, что она поехала в другую сторону в объезд, и звонит снова. Статус с интервалом прибытия отвечает на его настоящий вопрос — «успею ли я принять груз до конца смены», — не порождая новых. Карту имеет смысл открывать в личном кабинете по запросу, а не гнать в уведомления.
Расчёт: 900 отправлений, 2 160 обращений в месяц
Вводные. На отправление приходится 2,4 обращения — звонки, письма и сообщения вместе; итого 2 160 в месяц. Одно обращение занимает 4,8 минуты вместе с переключением между задачами: разговор короткий, но диспетчер каждый раз выпадает из того, чем занимался. Итого 172,8 часа в месяц, или 112 320 ₽ по ставке 650 ₽/час. Эти 650 ₽ — полная стоимость часа диспетчера, а не оклад: 70 000 ₽ начисленной зарплаты плюс 30 % взносов и около 15 000 ₽ на рабочее место дают 106 000 ₽ в месяц, делённые на 164 рабочих часа. Ту же ставку мы используем во всех транспортных расчётах журнала. При трёх диспетчерах с фондом 528 рабочих часов это 33 % — та самая треть дня, которая уходит на ответы вместо работы.
Структура обращений: 62 % — статусные вопросы «где груз, когда будет» (1 339 в месяц), 14 % — запросы документов и истории отправлений (302), 13 % — перенос окна и изменение заявки (281), 11 % — всё остальное (238). Уведомления снимают статусные вопросы, кабинет — часть статусных и большую часть документных. Перенос окна не снимается ничем: это содержательный разговор, и снимать его не надо.
Самая крупная строка здесь не про часы, а про срывы: 29 400 ₽ — это шесть повторных подач в месяц, которых не случилось, потому что клиент узнал об отклонении заранее и передвинул приёмку, а не отправил машину обратно. Именно эта строка обычно выпадает из расчётов подрядчиков, хотя она не требует ни кабинета, ни интеграций — достаточно одного правила: отклонение расчётного прибытия больше чем на 60 минут порождает событие, а не остаётся внутри системы.
Уведомление или личный кабинет: что дешевле и что снимает больше
Это главный практический вопрос темы, и ответ на него неочевидный. Разложим тот же расчёт по двум инструментам отдельно — с их собственными ценами внедрения и собственной эксплуатацией.
| Параметр | Уведомления по событиям | Личный кабинет клиента |
|---|---|---|
| Внедрение | 180 000–260 000 ₽, 3–4 недели | 320 000–540 000 ₽, 6–8 недель |
| Эксплуатация | 5 300 ₽/мес — СМС как запасной контур | 9 200 ₽/мес — хостинг и поддержка |
| Снимает обращений | 616 статусных плюс разбор опозданий и срывы окна | 321 статусное и 196 запросов документов |
| Эффект | 65 700 ₽/мес чистыми | 20 245 ₽/мес чистыми |
| Окупаемость | около 3,2 месяца | около 19 месяцев |
| Зачем на самом деле | Снять поток вопросов и предупредить срывы | Пройти тендер, удержать крупного клиента, дать доступ к архиву документов |
Вывод, который стоит сказать прямо: личный кабинет не окупается часами диспетчера и не должен продаваться под этим предлогом. Девятнадцать месяцев — это срок, на котором любой расчёт перестаёт быть расчётом. Кабинет ставят по другим причинам, и они законные: требование в тендере крупного заказчика, самостоятельный доступ клиента к архиву накладных и актов, возможность подать заявку без письма. Если этих причин нет — начинайте с уведомлений и вернитесь к кабинету, когда его попросит первый клиент, ради которого стоит потратить полмиллиона.
Порядок внедрения из этого следует сам: сначала уведомления на четырёх событиях (машина назначена, подача через два часа, отклонение прибытия больше часа, выгружено), через квартал — оценка остаточного потока обращений, и только потом решение о кабинете. Механику самого кабинета — состав разделов, права доступа и что туда попадает из учётной системы — мы описали на странице решения, а расчёт ожидаемого времени прибытия вынесен в отдельное.
Чем уведомлять в 2026 году
По состоянию на сентябрь 2026 года основной канал для новых внедрений — MAX: работает бизнес-профиль на business.max.ru с верификацией через Госуслуги и есть Bot API. Telegram работает с ограничениями, и опираться на него как на единственный канал не стоит. WhatsApp заблокирован в России с февраля 2026 года и в новых проектах не используется — только как источник базы номеров при переезде. Почта и СМС остаются обязательным запасным контуром: уведомление о подаче машины должно доходить при любом состоянии мессенджеров.
| Событие | Основной канал | Запасной | Срочность |
|---|---|---|---|
| Машина назначена, водитель и номер | MAX или Telegram | Почта | В течение часа |
| Подача машины через 2 часа | MAX или Telegram | СМС | Жёстко по времени |
| Отклонение прибытия больше 60 минут | MAX или Telegram, плюс звонок логиста по крупным клиентам | СМС | Немедленно |
| Выгружено, рейс закрыт | MAX или Telegram | Почта | В течение часа |
| Документы подписаны, счёт выставлен | Почта с вложением | Личный кабинет | В течение дня |
Четыре события на отправление — рабочий максимум. При десяти клиент отключает бота на второй неделе, и вы теряете канал целиком вместе с тем единственным сообщением, ради которого всё строилось, — предупреждением о срыве окна. Признак, по которому это ловится: доля отписок и заблокированных ботов; если она выше 8 % за квартал, событий слишком много. И отдельно: не привязывайте логику к API конкретного мессенджера — за период с августа 2025 по февраль 2026 года условия работы каналов в России менялись трижды. Слой абстракции канала и запасной контур разбирали отдельно.
Обратная сторона прозрачности: клиент увидит опоздание раньше менеджера
Это главное возражение, которое звучит внутри компании, и оно справедливое. Пока статусы не показывались, о срыве узнавали постфактум и успевали придумать объяснение. После включения уведомлений клиент видит отклонение в тот же момент, что и вы, — иногда раньше, потому что он смотрит на своё уведомление, а логист занят другим рейсом. К этому надо готовить процесс, а не прятать данные.
- 1Отклонение уходит внутрь на 15 минут раньше, чем клиенту
Это единственная техническая мера, которая нужна. Событие «расчётное прибытие сдвинулось больше чем на час» сначала создаёт задачу логисту, и только через пятнадцать минут уходит клиенту. Пятнадцати минут хватает, чтобы позвонить первым — а звонок «мы видим сдвиг на два часа, что делаем» и звонок клиента «почему вы молчите» это разные разговоры с разными последствиями.
- 2Показывать интервал прибытия, а не точку
«Прибытие 10:30–13:30» отрабатывает отклонение внутри себя и не порождает обращений. «Прибытие в 11:15» превращает любые сорок минут в срыв обещания. Ширина интервала — вопрос честности: на городской развозке разумны два-три часа, на межгороде — половина дня, и сужать их можно по мере накопления фактической статистики, а не заранее.
- 3У менеджера должен быть готовый ответ, а не отговорка
Прозрачность выдерживают компании, у которых на срыв есть регламент: кто звонит, что предлагает, в каких случаях компенсирует. Если такого регламента нет, включение уведомлений сначала увеличит поток обращений — просто теперь они будут приходить вовремя, а не в конце дня. Это не аргумент против прозрачности, это аргумент за то, чтобы делать её вместе с регламентом.
- 4Считать срывы и менять нормативы, а не прятать цифру
В модельной компании 11 срывов окна в месяц на 900 отправлений — 1,2 %. Пока их не считали, они существовали как отдельные неприятности. Как только появился счётчик, стало видно распределение: половина срывов приходится на два направления с недооценённым временем в пути. Это правится нормативами за неделю и без всяких вложений, но увидеть проблему можно только после того, как её начали измерять.
Когда статусы для клиента ставить не надо
Расчёт выше держится на потоке обращений. Если потока нет, снимать нечего, и весь эффект сводится к эксплуатационным расходам. Четыре ситуации, в которых мы сами отговариваем.
- Меньше 120 отправлений в месяц или меньше одного обращения на отправление. При 120 отправлениях и коэффициенте 1,0 это 120 обращений, 9,6 часа диспетчерского времени, около 6 240 ₽ в месяц. Уведомления за 180 000 ₽ будут окупаться больше двух лет даже без учёта эксплуатации.
- Регулярные рейсы по расписанию для двух-трёх клиентов. Когда машина каждый вторник и четверг идёт по одному плечу, клиент не спрашивает «где груз» — он спрашивает «поехали ли», и на это отвечает одно сообщение в общий чат утром. Строить контур статусов ради этого не нужно.
- Нечем наполнить статус. Водители не отмечаются, телематики нет или она только на трети парка, рейс не привязан к заявке номером. В этом случае система будет показывать клиенту то, что диспетчер проставил руками, — то есть ровно ту же неточность, только теперь публично и с претензией. Сначала базовый контур, потом статусы.
- Клиент — крупный заказчик со своей системой. Маркетплейсу, сетевому ритейлеру или производству с собственной TMS не нужны ваши уведомления: им нужен обмен данными по API или через ЭДО в их формате. Это другой проект — интеграция, а не информирование.
Минимальный вариант без бюджета, который стоит попробовать до любого проекта: одно сообщение клиенту вечером накануне с номером машины, водителем и интервалом подачи, и второе — в момент выгрузки. Два сообщения, отправляемые руками, снимают заметную часть статусных обращений и заодно дают честный ответ на вопрос, стоит ли автоматизировать: если за месяц ручных отправок поток вопросов не упал, дело не в информировании, и проект надо отменять. Как собрать все обращения клиентов в одно окно, чтобы вообще увидеть их структуру, разбирали отдельно.
Клиент звонит не потому, что ему нужен статус. Он звонит потому, что не знает, успеет ли принять груз до конца смены.
