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

Дальше — разбор на модельной компании: 24 собственные машины, наёмный транспорт по необходимости, 340 заявок в месяц, два диспетчера и логист, 1С:Бухгалтерия и таблицы. Средняя ставка рейса 62 000 ₽, маржа рейса 14 % — 8 680 ₽. Это середина того, что мы видим у перевозчиков на междугородных плечах; цифры в вашем случае будут другими, но структура потерь совпадёт.

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

Пять входов заявки и что с каждым из них делать

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

Канал входаЗаявок в месяцДоляЧто с ним делать в первую очередь
Почта с вложением: письмо, файл Excel или PDF-бланк клиента13941 %Разбор письма и вложения в карточку заявки; общий ящик с правилами, а не личные адреса менеджеров
Мессенджер: MAX, Telegram; из них 31 сообщение — голосовые8826 %Бот, который принимает текст, файл и голос, расшифровывает и создаёт черновик заявки
Грузовая биржа (ATI.SU и аналоги)5817 %Забор через API площадки в тот же реестр, а не отдельным экраном для логиста
Звонок3811 %Карточка заводится во время разговора; резюме звонка прикладывается к заявке
Форма на сайте и личный кабинет клиента175 %Единственный канал, где поля уже структурированы; его надо расширять, а не заводить шестой
Итого340100 %Один реестр на все пять каналов

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

графикavtomatizaciya-transportnoy-kompanii--01
Столбиковая диаграмма: 340 заявок в месяц по пяти каналам входа с долями

Горизонтальная столбиковая диаграмма из пяти строк, единицы — заявки в месяц: «Почта с вложением — 139 (41 %)», «Мессенджер, из них 31 голосовое — 88 (26 %)», «Грузовая биржа — 58 (17 %)», «Звонок — 38 (11 %)», «Форма на сайте и личный кабинет — 17 (5 %)». Под диаграммой итоговая строка «340 заявок в месяц». Два верхних столбика выделены штриховкой и подписаны сбоку «67 % — переносятся в таблицу руками». Все подписи по-русски.

Почта и мессенджер дают две трети заявок — и именно они обрабатываются руками

Что машина разбирает из письма, а что нет

Разбор заявки языковой моделью — не магия и не лотерея: одни поля берутся устойчиво, другие требуют человека почти всегда, и это распределение известно заранее. У модельной компании из 139 писем в месяц 103 (74 %) собираются в карточку без участия диспетчера, а 36 попадают в очередь на дозаполнение. Проектировать надо под эту вторую цифру: если очереди дозаполнения нет, заявки будут молча уезжать в систему с пустыми полями.

Поле заявкиБерётся автоматическиДоля случаев с человекомЧто мешает
Города погрузки и выгрузкиДа6 %Сокращения «мск — спб», названия терминалов вместо городов, посёлки-тёзки
Дата и окно подачиДа4 %«В четверг к утру», «после праздников», «как освободится машина»
Вес и число местДа9 %«Фура», «примерно 20 тонн», вес указан на паллету, а не на партию
Контакты на погрузке и выгрузкеДа7 %Телефоны в подписи и в теле письма вперемешку, часть — личные мобильные
Наименование грузаЧастично18 %У каждого клиента свой язык: одна и та же позиция называется тремя способами
Тип кузова и особые требованияЧастично22 %Допуски, гидроборт, температурный режим и ADR пишут прозой в середине абзаца
Объём грузаЧастично27 %Чаще всего не указан вовсе и считается по габаритам, которых тоже нет
Условия оплаты и отсрочкаНет100 % при первой заявкеБерутся из карточки клиента и договора, а не из письма — и это правильно
Приписка в конце письмаНет100 %«И да, в этот раз надо выгрузить до 14:00» — меняет весь расчёт, а стоит после подписи
Двадцать шесть процентов и тридцать один процент — это разные проценты

26 % писем уходят на дозаполнение, потому что разборщик чего-то не понял. И отдельно 31 % заявок приходят неполными, потому что клиент чего-то не написал: в письме нет объёма, нет окна выгрузки или нет контакта на точке. Первое лечится настройкой разбора, второе — только автоответом клиенту с перечнем недостающих полей. Путать их нельзя: подрядчик, который обещает «100 % автоматический разбор», обычно молча закрывает первую цифру и не трогает вторую.

Голосовые сообщения — отдельная история и, вопреки ожиданиям, не самая тяжёлая. Из 88 сообщений в мессенджере 31 приходит голосом; расшифровка и разбор дают полную карточку по 22 из них, оставшиеся 9 идут диспетчеру вместе с текстом расшифровки, а не с записью. Это уже экономия: слушать полторы минуты голосового и параллельно записывать — дольше, чем прочитать двенадцать строк и поправить два поля. Что именно делает с текстом языковая модель и где проходит граница её надёжности, мы разбирали в материале про реальную точность распознавания.

сравнениеavtomatizaciya-transportnoy-kompanii--02
Две колонки: 74 % писем собираются автоматически, 26 % уходят на дозаполнение

Сравнение в две колонки. Левая — «Собирается само, 103 письма из 139 (74 %)»: маршрут, дата и окно подачи, вес и число мест, контакты. Правая — «Уходит в очередь на дозаполнение, 36 писем (26 %)»: объём груза, тип кузова и особые требования, наименование груза, приписка после подписи. Под колонками отдельная серая полоса с подписью «Плюс 31 % заявок неполны потому, что клиент не написал, — это лечится автоответом, а не разбором». Чертёжный стиль, подписи по-русски.

Проектировать надо не под первую колонку, а под вторую

Реестр заявок: 14 полей, 7 статусов, один владелец

Что это значитРеестр заявок

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

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

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

  1. 1Номер заявки и дата с точностью до минуты — от неё считается скорость ответа.
  2. 2Канал входа — без него нельзя понять, какой канал приносит деньги, а какой шум.
  3. 3Клиент — код из справочника контрагентов, не строка «ООО Ромашка» руками.
  4. 4Контакт заявителя: имя, телефон, канал, в котором он ждёт ответа.
  5. 5Город и адрес погрузки — код из справочника адресов.
  6. 6Город и адрес выгрузки — код из того же справочника.
  7. 7Дата и окно подачи под погрузку.
  8. 8Дата и окно выгрузки.
  9. 9Груз — код классификатора, а не свободный текст клиента.
  10. 10Вес, кг, и число грузовых мест.
  11. 11Объём, м³, либо габариты, из которых он считается.
  12. 12Тип кузова и особые требования: ADR, температурный режим, гидроборт, допуск на территорию.
  13. 13Ставка клиента, НДС и условия оплаты с отсрочкой.
  14. 14Владелец записи — конкретный логист, а не отдел.

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

разбор экранаavtomatizaciya-transportnoy-kompanii--03
Нарисованный экран реестра заявок: список слева, карточка с 14 полями справа

Абстрактный нарисованный экран (не скриншот реального продукта). Слева — список заявок с цветными метками семи статусов, подписанных полностью: «новая», «на расчёте», «предложение отправлено», «отказ», «подтверждена», «в рейсе», «закрыта». Справа — карточка заявки с сгруппированными полями: «клиент и контакт», «маршрут и адреса», «даты и окна», «груз, вес, объём», «требования к машине», «ставка и оплата», «владелец записи». Внизу карточки узкая полоса «история изменений». Сверху счётчик «14 обязательных полей». Чертёжный стиль, подписи по-русски.

Реестр отличается от таблицы четырьмя вещами: поля, статусы, владелец, история

Что стоит реестр в голове: расчёт на 340 заявках

Это главный расчёт статьи, и он специально построен так, чтобы его можно было повторить на калькуляторе. Ставка диспетчера — 620 ₽ за час полной стоимости (оклад, налоги, рабочее место, разделённые на рабочие часы). Маржа рейса — 8 680 ₽, это 14 % от средней ставки 62 000 ₽. Доли потерь взяты по нижней границе того, что мы видим при обследованиях: они всегда неприятнее.

Цена отсутствия реестра, 340 заявок в месяц
Ручное занесение заявок: 340 × 11 мин = 3 740 мин ≈ 62 ч × 620 ₽/ч38 440 ₽
Переписка по неполным заявкам: 31 % от 340 = 105 шт × 12 мин = 21 ч × 620 ₽/ч13 020 ₽
Заявки, потерянные между каналами: 4 % от 340 = 14 шт, из них 5 стали бы рейсами × 8 680 ₽43 400 ₽
Ответ дольше 40 минут по 156 заявкам (46 %): минус 8 п.п. конверсии = 12 рейсов × 8 680 ₽104 160 ₽
Двойное занесение: 6 % от 340 = 20 шт × 11 мин = 3,7 ч × 620 ₽/ч2 290 ₽
Итого201 310 ₽ в месяц, 2,42 млн ₽ в год

Внутри этой суммы две разные природы денег, и путать их нельзя. 53 750 ₽ — часы людей: их можно перераспределить, но нельзя положить в кассу, пока вы не сократили ставку или не перевели человека на другую работу. А 147 560 ₽ — упущенная маржа: это рейсы, которые компания не сделала, потому что не увидела заявку или ответила позже конкурента. Вторая цифра больше первой втрое, и именно она обычно остаётся за рамками разговора о «сокращении рутины». Разбор того, как вообще считать стоимость ручной работы, чтобы не завысить эффект, мы выложили отдельно.

графикavtomatizaciya-transportnoy-kompanii--04
Диаграмма из пяти строк: 201 310 ₽ потерь в месяц с разделением на часы и маржу

Горизонтальная столбиковая диаграмма из пяти строк с суммами в рублях в месяц: «Медленный ответ, 12 рейсов — 104 160 ₽», «Потерянные заявки, 5 рейсов — 43 400 ₽», «Ручное занесение, 62 часа — 38 440 ₽», «Переписка по неполным заявкам, 21 час — 13 020 ₽», «Двойное занесение — 2 290 ₽». Столбики двух видов штриховки, легенда: «упущенная маржа 147 560 ₽» и «часы людей 53 750 ₽». Итог справа: «201 310 ₽ в месяц, 2,42 млн ₽ в год».

Три четверти потерь — не переработка людей, а рейсы, которых не было

Карта контура: шесть переходов, на которых теряются деньги

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

ПереходКак это обычно устроеноЧто ломаетсяГде разобрано подробно
Заявка → реестрДиспетчер переносит из почты и чата руками4 % заявок не доходят, 46 % ответов позже 40 минутЭта статья
Реестр → ставкаЛогист называет цену по памяти о похожем рейсеРазнобой между логистами, рейсы уходят в минус незаметно/zhurnal/raschet-stoimosti-perevozki
Ставка → машинаПодбор по опыту: кто свободен и кто знает направлениеПустой пробег, машина уходит недогруженной/solutions/logistics/planirovanie-zagruzki-transporta
Машина → рейсПлан на завтра собирается в таблице вечеромСорванные окна, клиент узнаёт о срыве первым/solutions/logistics/optimizatsiya-marshrutov
Рейс → документыОригиналы едут с водителем и лежат у клиентаСчёт выставляется на 3–6 недель позже выгрузки/zhurnal/dokumenty-reysa-i-ih-vozvrat
Документы → деньгиНапоминает тот, у кого дошли рукиДебиторка растёт, оборотка заморожена/solutions/calls/napominanie-ob-oplate

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

карта связейavtomatizaciya-transportnoy-kompanii--05
Схема контура перевозчика: шесть переходов от заявки до денег с точками потерь

Горизонтальная схема-цепочка из семи узлов слева направо: «Заявка», «Реестр», «Ставка», «Машина», «Рейс», «Документы», «Деньги». Между узлами шесть стрелок, каждая подписана тем, что теряется на переходе: «4 % заявок не доходят», «разнобой в цене», «пустой пробег», «сорванное окно», «счёт на 3–6 недель позже», «дебиторка». Первая стрелка выделена и подписана «здесь начинают». Под цепочкой сноска: «каждый следующий переход опирается на данные предыдущего». Чертёжный стиль, все подписи по-русски.

Шесть переходов — шесть мест, где заявка теряет данные и деньги

Каналы связи в 2026 году: чем разговаривать с клиентом и водителем

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

КаналСтатус на сентябрь 2026 годаРоль в контуре перевозчика
MAXРаботает: бизнес-профиль на business.max.ru, верификация через Госуслуги, есть Bot APIОсновной канал для новых внедрений: приём заявок, отметки рейса водителем, статус клиенту
TelegramРаботает с ограничениями: звонки ограничены с августа 2025 года, деградация медиа в 2026 годуВторой канал, но не единственная опора — статус волатилен
WhatsAppЗаблокирован в РФ с февраля 2026 годаТолько точка ухода: источник базы номеров клиентов и водителей
ПочтаРаботаетОсновной канал заявок от корпоративных клиентов и единственный, где есть вложение с бланком
СМС и телефонияРаботаютЗапасной контур: уведомление о подаче машины и о срыве окна должно доходить всегда
Личный кабинет клиента на сайтеРаботаетЕдинственный канал, который вы контролируете полностью, — сюда переносят постоянных клиентов
Не проектируйте под конкретный мессенджер

За период с августа 2025 по февраль 2026 года условия работы клиентских мессенджеров в России менялись трижды. Если бот, реестр и уведомления написаны напрямую под API одного мессенджера, следующее изменение обойдётся в повторную оплату интеграции и месяцы работы. Слой абстракции канала — отдельный адаптер на каждый мессенджер и общий интерфейс отправки — добавляет к проекту около недели и 20 000–25 000 ₽, а стоит того при первом же переключении. План перехода на другой канал мы разбирали пошагово, а запасной контур на случай ограничений — отдельно.

Для водителя правило ещё жёстче: ничего, кроме телефона, ему ставить не надо. Отметки «прибыл на погрузку», «загрузился», «выехал», «прибыл на выгрузку» делаются кнопками в обычном мессенджере, фото документов приходит туда же. Отдельное мобильное приложение для парка в 24 машины не окупается никогда: его надо разрабатывать, обновлять, объяснять и переустанавливать каждому новому водителю, а отдача та же самая.

карта связейavtomatizaciya-transportnoy-kompanii--06
Схема: четыре канала связи через общий адаптер приходят в единый реестр заявок

Схема связей. Слева четыре узла-канала: «MAX», «Telegram», «Почта», «СМС и звонок». Каждый соединён стрелкой с общим прямоугольником в центре, подписанным «слой абстракции канала: адаптер на канал, один интерфейс отправки, +20 000–25 000 ₽ и неделя». Из него одна стрелка вправо в крупный блок «Реестр заявок». Ниже пунктиром показан пятый пустой слот с подписью «место под следующий канал». Над блоком MAX пометка «основной, сентябрь 2026», над Telegram — «с оговоркой о стабильности». Чертёжный стиль, подписи по-русски.

Мессенджер меняется, адаптер переписывается за неделю, реестр остаётся

Порядок внедрения: две волны по шесть недель

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

  1. 1
    Недели 1–2. Справочники и правила, до всякого кода

    Чистка справочника контрагентов, сведение адресов погрузки и выгрузки к единому виду с координатами, классификатор грузов. Это самая скучная и самая критичная часть: пока один и тот же склад записан четырьмя способами, ни расчёт по километражу, ни маршрутизация не работают. Итог этапа — два справочника, которые заказчик принимает и признаёт своими.

  2. 2
    Недели 2–4. Реестр и разбор входящих

    Заводим реестр с 14 полями и 7 статусами, подключаем почту, мессенджер и биржу, настраиваем разбор письма и голосового в черновик заявки, ставим очередь дозаполнения на те 26 %, которые машина не собрала. Итог — все заявки в одном месте, у каждой есть владелец.

  3. 3
    Недели 4–6. Скорость ответа и автоответ клиенту

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

  4. 4
    Недели 7–9. Расчёт ставки и предложение клиенту

    Тарифная модель на правилах, коридор скидки, автоматическое формирование предложения. К этому моменту в реестре уже есть структурированные маршрут, вес и объём, без которых правила считать не по чему.

  5. 5
    Недели 9–12. Рейс, документы и деньги

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

  6. 6
    Третья волна, не раньше чем через квартал. Маршруты и телематика

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

этапыavtomatizaciya-transportnoy-kompanii--07
Лента внедрения: две волны по шесть недель и третья волна через квартал

Горизонтальная лента времени с тремя блоками. Блок 1 «Недели 1–6»: подписи «справочники», «реестр 14 полей и 7 статусов», «разбор почты и голосовых», «скорость ответа»; под блоком результат — «все заявки в одном месте, у каждой владелец». Блок 2 «Недели 7–12»: «тарифная модель», «рейс и отметки водителя», «статус для клиента», «документы и счёт»; результат — «контур замкнут от письма до оплаты». Блок 3 отделён разрывом и подписан «Через квартал»: «маршруты, догрузы, телематика»; под ним пометка «нужна накопленная статистика за 3 месяца». Чертёжный стиль, подписи по-русски.

Каждая волна заканчивается результатом, который можно оставить и не продолжать

Три признака, что вам рано трогать маршрутизацию

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

  1. 1Меньше 90 % заявок попадают в систему структурированными. Если каждая десятая заявка приходит в планировщик с пустым объёмом или с адресом «склад заказчика», алгоритм будет строить план по половине входных данных, а диспетчер — переделывать его руками и перестанет ему верить на второй неделе.
  2. 2Нет справочника адресов с координатами. Один и тот же терминал, записанный как «Домодедово», «МКАД 26 км» и «база на Каширке», превращается для алгоритма в три разные точки. Оптимизация по такой карте даёт маршруты, которые водители не поедут.
  3. 3Плановое время рейса нигде не фиксируется. Если в системе нет обещанного времени прибытия, факт не с чем сравнивать: экономию посчитать невозможно, отклонение поймать невозможно, и через полгода проект закрывают с формулировкой «эффекта не увидели».

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

Для небольшого парка отдельно собран пакет с фиксированной ценой — подбор грузов, расчёт себестоимости плеча, ведение рейса, электронные перевозочные документы и контроль оплаты за 350 000 ₽ и 5 недель. Курьерская доставка и таксопарк устроены иначе и вынесены на отдельные страницы: там другая единица работы — не рейс, а смена и заказ.

Когда перевозчику на 10 машин не нужна система вообще

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

  • Меньше 80 заявок в месяц. Разработка стоит примерно одинаково при 80 и при 340 заявках, поэтому цена одной обработанной заявки становится неприемлемой. Ниже этого порога дешевле дисциплина, чем система.
  • Один диспетчер, и он же собственник или его заместитель. Реестр нужен там, где данные передаются между людьми. Если решение принимает один человек и он же всё помнит, реестр решает только задачу преемственности — важную, но не срочную.
  • Не больше 12 постоянных клиентов, которые дают 90 % объёма. Заявки от них приходят по одному шаблону, ставки согласованы договором, разбирать письмо машиной незачем.
  • Три-пять повторяющихся направлений. Тарифная модель на правилах имеет смысл, когда направлений десятки; для пяти плеч таблица со ставками в одном файле работает не хуже и стоит ноль.
  • Закрывающие документы уже уходят электронно и возвращаются в течение недели. Если самая денежная утечка контура у вас закрыта, остальное — оптимизация, а не спасение.

Минимальный порядок без бюджета выглядит так: один общий почтовый ящик вместо личных адресов менеджеров; один файл с теми же 14 полями и 7 статусами; правило «заявки нет, пока она не в файле»; и раз в неделю пятнадцать минут на просмотр строк, которые висят в статусе «на расчёте» дольше суток. Это не автоматизация, это дисциплина — но она закрывает две из пяти строк расчёта выше, а именно потерянные заявки и двойное занесение, и стоит 0 ₽.

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

Посчитайте на своих числах

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

Калькулятор рутины

Сколько стоит ручная работа в вашем процессе

4
2.5 ч
700
70%
350 000
26 000
Ручная работа сейчас обходится в
147 000 ₽/мес
Чистая экономия с системой
+76 900 ₽/мес
Окупаемость внедрения≈ 5 мес.
Эффект за первый год (за вычетом внедрения)+572 800 ₽

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

Маршрут можно оптимизировать. Заявку, которой нет в системе, оптимизировать нельзя.