CRM для логистики и грузоперевозок: заявки, рейсы, документы и оплата

Новые разборы про CRM для логистики, автоматизацию перевозок и продаж я публикую в Telegram-канале, подписаться можно со страницы статьи.

Что такое CRM для логистики и чем она отличается от обычной?

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

Классическая CRM строится вокруг воронки: заявка, звонок, коммерческое предложение, счёт, оплата. Так её устройство описано в нашем разборе что такое CRM-система. В грузоперевозках согласие клиента на ставку - середина пути. Дальше диспетчеру нужно:

1. Найти машину. Свою из парка или нанятого перевозчика через биржу грузов или по базе знакомых.
2. Оформить заказ-заявку. С адресами, датами, характеристиками груза и ставкой.
3. Вести рейс. Погрузка, в пути, выгрузка, простой, переадресовка.
4. Собрать документы. Транспортная накладная, акты, счёт-фактура, путевые листы у своего транспорта.
5. Закрыть деньги. Получить оплату от клиента и заплатить перевозчику, не перепутав сроки.

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

Где вы сейчас

• Заявки в мессенджерах и почте, рейсы в таблице. Вам нужна первая CRM. Начните с пути заявки и классов готовых решений.
• CRM для продаж уже есть, но рейсы и документы живут отдельно. Проверьте границу с TMS и раздел про электронные документы.
• Свой парк машин, путевые листы и топливо уже в TMS. Вам важнее связка TMS с клиентской частью, смотрите раздел про обмен данными.
• Много каналов заявок, свои правила ставки, кабинет клиента. Скорее всего, понадобится доработка или своя система. Сначала прочитайте признаки в разделе «Когда готовой CRM мало».

CRM или TMS: где проходит граница?

Когда ищешь CRM для логистики, часто попадаешь на страницу TMS, и это путает. Например, Saby TMS описывает себя как программу автоматизации логистики и транспорта: электронные транспортные накладные, путевые листы, учёт топлива и топливных карт, плановые ТО и ремонты, зарплаты водителей и штрафы. Это инструмент для того, кто управляет машинами. Клиентская воронка, повторные продажи и работа менеджера с заявкой там не главное.

Если у вас нет своих машин, начинайте с CRM и не покупайте TMS «на вырост». Если парк есть и путевые листы уже ведутся в TMS, не пытайтесь заставить CRM делать то же самое: решите, какие данные о рейсе должны приходить из TMS в карточку заявки.

Про то, где в логистике помогает ИИ поверх этих систем - маршруты, склад, документы, - мы писали отдельно в статье ИИ для логистики.

Какой путь проходит заявка на перевозку?

Требования к CRM для логистики удобнее собирать по пути одной заявки. Когда мы разбираем процесс транспортной компании, просим взять три реальных рейса за прошлый месяц: обычный, срочный и тот, где что-то пошло не так. На них видно, где заявка ждёт и где теряется.

Два места в этой цепочке теряют больше всего.

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

Второе - документы после выгрузки. Рейс сделан, а подписанные документы не собраны, и счёт клиенту не выставлен. Деньги зависают на недели. Как устроить контроль оплат, чтобы это видел руководитель, разобрано в статье про контроль дебиторской задолженности.

Если путь заявки у вас нигде не записан, начните с него. Как описать процесс за пару встреч без специальных программ, мы показывали в разборе описания бизнес-процессов.

Что меняют электронные перевозочные документы с 1 сентября 2026 года?

Это самая свежая причина, по которой транспортные компании пересматривают свою CRM для логистики. С 1 сентября 2026 года по Федеральному закону от 07.06.2025 № 140-ФЗ транспортная накладная, заказ и заявка при автомобильной перевозке и экспедиторские документы оформляются в электронном виде через ГИС ЭПД. Случаи, когда допустима бумага, определяет Минтранс. До 1 марта 2027 года за бумажные документы вместо электронных не штрафуют, это переходный период. Какие документы меняются и где здесь помогает ИИ, мы разобрали в статье ИИ для логистики, в разделе про документы. Здесь важнее другое: обмен CRM с оператором ЭДО.

Что это значит для CRM на практике:

• Документ оформляют у оператора ЭДО. Это сервисы вроде Контур.Логистики или Saby. CRM в ГИС ЭПД напрямую ничего не отправляет.
• Данные рейса вводить дважды нельзя. Если диспетчер заводит заявку в CRM, а потом перепечатывает те же адреса, груз и машину в сервис ЭДО, появятся ошибки и задержки. Нужен обмен: карточка заявки передаёт данные, сервис ЭДО возвращает статус подписания.
• Статус документа становится статусом заявки. «Накладная подписана получателем» - это событие, после которого можно выставлять счёт. Хорошо, когда этот статус приходит в CRM автоматически, без звонка диспетчера.

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

Какие бывают готовые CRM для грузоперевозок?

Если искать CRM для логистики через подборки, в одном списке окажутся программа для путевых листов и CRM для отдела продаж. Это системы для разных задач, поэтому сначала выберите класс, потом продукт.

Универсальная CRM с отраслевым приложением. Пример - Битрикс24. В справке Битрикс24 для транспорта перечислены отраслевые приложения из маркетплейса, среди них Логистика24. По описанию в справке, в нём отдельные воронки «Заказчики» и «Подрядчики»: у заказчика стадии идут от назначения машины через документы и счёт до оплаты, у подрядчика фиксируются его документы и сумма к оплате. Путевые листы, транспортные средства и топливные карты ведут в другом приложении из той же справки, «Путевые листы». Сильная сторона класса - клиентская часть, задачи, телефония и почта в одном месте.

CRM с шаблоном для транспортных компаний. Например, у SberCRM есть страница решения для логистики: этапы доставки, документы, счета и договоры в CRM, аналитика. Это универсальная система, настроенная под отрасль.

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

TMS с блоком заказов. Saby TMS и похожие системы ведут электронные заказы-заявки и накладные, путевые листы, контроль парка. Для перевозчика со своими машинами это основа, к которой клиентскую CRM подключают рядом.

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

Что даёт связка CRM с ботом приёма заявок?

Типичный запрос ставки приходит неполным: «Сколько будет Москва - Казань, паллеты». Логист тратит несколько сообщений на уточнения: вес, объём, количество мест, тип кузова, дата погрузки, нужна ли растентовка. Пока идёт переписка, клиент уже спросил двух конкурентов.

Бот в мессенджере или на сайте закрывает эту часть. Он задаёт те же вопросы в одном порядке, проверяет, что ответы заполнены, и создаёт в CRM заявку со статусом «Запрос ставки». Логист видит полную карточку и сразу считает. Как устроены такой бот приёма заявок и ИИ-диспетчер, мы подробно описали в статье ИИ для грузоперевозок.

Что важно в этой связке:

• Бот не называет ставку сам, если правила расчёта не записаны. Он собирает данные и обещает срок ответа.
• Каждая заявка из бота получает ответственного. Иначе бот просто переносит хаос из мессенджера в CRM.
• Клиент видит статус без звонка. Тот же бот может отвечать, где груз, если статусы рейса ведутся в CRM.

Если имена, телефоны и адреса клиентов уходят в бота и в облачную CRM, это персональные данные по 152-ФЗ. Проверьте, где хранятся данные и как сервис выполняет требования закона.

Когда готовой CRM мало и нужна своя?

Сначала признаки, при которых готовой системы хватает:

1. Один-два канала заявок, и диспетчеров немного.
2. Ставка считается логистом вручную или по простому правилу.
3. Одно юрлицо и один оператор ЭДО.
4. Обмен с 1С типовой: контрагенты, счета, оплаты.

Здесь своя разработка вряд ли себя оправдает: права сотрудников, приложение для телефона и шаблоны документов в готовой системе уже есть.

Теперь признаки, при которых готовая CRM начинает мешать:

• Заявки из многих источников. Сайт с калькулятором, бот, почта, биржи грузов, тендерные площадки крупных грузоотправителей. Каждый канал приходится склеивать вручную.
• Свои правила ставки. Расчёт зависит от направления, загрузки обратных рейсов, сезона, и логисты держат его в своих таблицах.
• Кабинет клиента или перевозчика. Крупный клиент хочет сам создавать заявки и смотреть статусы, перевозчик - загружать документы и видеть оплату.
• Несколько юрлиц или направлений. Разные договоры, разные операторы ЭДО, общая база клиентов.
• Нестандартный обмен. Данные рейса нужно передавать в сервис ЭДО, в 1С и клиенту одновременно, а готовый модуль передаёт только счета.

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

Если хотите увидеть свой процесс перевозок в работающей системе до решения о бюджете, посмотрите, как устроена разработка и внедрение CRM в ClaudeLab. Мы начинаем с разбора пути заявки от запроса ставки до оплаты рейса. Затем собираем самый болезненный сценарий в рабочем прототипе и показываем его до подписания договора. Вы проводите через него свои реальные рейсы и решаете, нужна ли своя система или хватит готовой с доработкой.

Если задача шире работы с заявками и затрагивает учёт парка, себестоимость рейсов и планирование ресурсов всей компании, речь уже о разработке ERP-системы.

Как связать CRM транспортной компании с 1С и другими системами?

Транспортная компания почти всегда живёт в нескольких системах сразу. Ломается всё в одном месте: никто не решил, где главная копия данных.

Как обычно распределяют роли:

1. Клиенты и перевозчики. Заводятся в CRM, с реквизитами уходят в 1С после первого счёта.
2. Заявки и ставки. Живут в CRM, в 1С уходят счёт клиенту и документ на оплату перевозчику.
3. Машины и водители. У перевозчика со своим парком живут в TMS, в CRM видны в карточке рейса.
4. Перевозочные документы. Оформляются у оператора ЭДО по данным из CRM или TMS, статус подписания возвращается в заявку.
5. Оплаты. Фиксируются в 1С, статус возвращается в CRM, чтобы менеджер видел, что рейс закрыт.

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

Что спросить у вендора до внедрения?

Демонстрация любой CRM для логистики показывает экраны. Проблемы через год работы видны по ответам на эти вопросы.

Две стороны сделки. Можно ли в одной заявке вести ставку клиенту и ставку перевозчику, две оплаты и маржу. Если для этого нужны две сделки и ручная сверка, вы вернётесь к таблице.

Электронные документы. С каким оператором ЭДО работает система, какие поля заявки уходят в накладную, как возвращается статус подписания.

Открытое API. Калькулятор на сайте, бот, кабинет клиента рано или поздно появятся. Без API их связь с CRM зависит только от планов вендора.

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

Хранение данных. Где стоят серверы и как вендор выполняет требования 152-ФЗ. В базе транспортной компании лежат телефоны клиентов и данные водителей.

На чём спотыкаются при внедрении CRM в логистике?

CRM продаж без рейсов. Воронка работает, а после согласия клиента заявка пропадает из поля зрения. Если берёте универсальную систему, сразу решите, кто настроит в ней этапы рейса и документы.

TMS вместо CRM. Перевозчик ставит программу для путевых листов и ждёт от неё работы с клиентами. Повторные продажи и запросы ставок остаются в мессенджерах.

Двойной ввод. Заявку заводят в CRM, накладную - в сервисе ЭДО, счёт - в 1С, и каждый раз руками. Через месяц данные в трёх системах расходятся.

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

Переезд одним днём. Если перевести всех диспетчеров сразу, неделю заявки ведут и в системе, и в старой таблице. Спокойнее начать с приёма заявок, затем подключить рейсы и документы, затем оплаты.

Чек-лист

• Описан путь одной заявки: от запроса ставки до оплаты клиентом и перевозчику.
• Понятно, что вам нужно: CRM, TMS или обе системы с обменом.
• Для каждого вида данных решено, где главная копия: CRM, TMS, 1С или оператор ЭДО.
• Проверено, как заявка превращается в электронную накладную у вашего оператора ЭДО.
• Получены ответы вендора: две стороны сделки, API, выгрузка, хранение персональных данных.
• Две системы проверены на трёх реальных рейсах: обычном, срочном и проблемном.
• Есть план перевода по этапам: приём заявок, рейсы и документы, оплаты.