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

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

Планирование рейсов, назначение машины и водителя, юридически значимые перевозочные документы относятся к профильному контуру: системе управления перевозками (TMS), диспетчерской программе или учётной системе. Чтобы CRM работала в логистике, мало настроить поля. Нужно договориться, когда заявка готова к расчёту, какая версия ставки действует и кто подтверждает, что диспетчер принял заказ.

Заявка на грузоперевозку: когда её можно считать готовой к расчёту

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

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

Этап «Новая заявка» в логистике легко смешивает два разных состояния. Первое - «нам написали». Второе - «мы знаем достаточно, чтобы посчитать». Между ними обычно стоит уточнение: откуда и куда, что за груз, когда грузиться, есть ли ограничения. Если не разделить эти состояния, отчёт покажет «быстрый ответ», хотя клиент получил вопрос вместо цены.

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

Заказчик, заявка, заказ и рейс: почему сделка не равна рейсу

Одна из ошибок модели - приравнять одну сделку к одному рейсу. Так проще настроить, но реальность перевозок устроена иначе. Один согласованный заказ может исполняться несколькими машинами или плечами. Постоянный заказчик работает по рамочному договору и присылает десятки отдельных заявок. Заказ может отмениться после назначения машины, а рейс - уйти с опозданием, не меняя коммерческого результата продажи.

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

Как это выглядит в конкретной платформе, зависит от процесса. В amoCRM заявки и заказы можно вести в разных воронках, а для связи с внешними объектами хранить их номера в полях. В Битрикс24 для отдельных сущностей вроде заказа на перевозку рассматривают смарт-процессы - новые элементы CRM со своими полями, стадиями и правами. Они доступны не на всех тарифах, поэтому тариф сверяют до проектирования. Обе платформы подходят. Выбор зависит от того, сколько объектов вы ведёте в CRM, какие интеграции нужны и как команда привыкла работать.

Рамочный договор и отдельные заявки

Для постоянного заказчика полезно разделить два уровня. Рамочный уровень - договор, согласованные тарифы или правила расчёта, контактные лица, особые условия. Операционный уровень - каждая новая заявка со своими датами и грузом. Если вести всё в одной бесконечной сделке, исчезает видимость: сколько заявок пришло за месяц, сколько посчитано, сколько отменено. Если создавать нового заказчика на каждую заявку, теряется история и появляются дубли. Как их избежать, описано в статье о дублях в amoCRM.

Предложение: версия ставки и срок её действия

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

Рабочее правило звучит так: изменение существенных условий создаёт новую версию предложения, а не тихую правку. У версии есть номер, дата, срок действия и состав условий, на которых она рассчитана. Согласование фиксируется явно: какая версия принята и кем. Тогда диспетчер получает не просто «сумму в сделке», а конкретные условия, под которыми заказчик дал согласие.

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

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

Когда достаточно CRM, а когда нужен TMS: передача заказа

Небольшой перевозчик с несколькими машинами иногда ведёт исполнение в той же CRM: отдельная воронка заказов, задачи диспетчеру, отметка о выполнении. Это допустимо, пока диспетчеру не нужны планирование загрузки, учёт парка, маршруты и путевые документы. Когда такие задачи появляются, их решают профильные программы. У 1С, например, есть отдельные решения для управления автотранспортом и транспортной логистики: в них учитывают заказы на перевозку и ведут оперативное планирование.

Граница определяется не размером компании, а тем, где принимается решение о машине. Если диспетчер планирует рейсы в другой системе, CRM не должна делать вид, что знает о назначенном транспорте. Клиенту нельзя сообщать «машина назначена», пока это не подтвердил тот, кто её назначает.

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

Технически такую связь строят через интерфейс программирования (API). У amoCRM он требует авторизации и учитывает права пользователя, от имени которого работает интеграция. Но наличие API не означает, что готовый обмен с вашей TMS существует. Универсального коннектора CRM и TMS мы не знаем: обмен проектируют под конкретные системы, их поля и события. Общий порядок такой работы описан в статье о сквозном обмене данными.

Счета и оплаты через 1С

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

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

Повторные заказчики и показатели логистических продаж

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

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

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

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

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

Начните с одного направления перевозок и одного менеджера или группы. Не нужно сразу переносить всю историю. Цель пилота - убедиться, что заявка доходит до расчёта, версия ставки сохраняется, а диспетчер подтверждает приём заказа. Удачную заявку проверить легко. Ценнее проверить исключения: перенос даты, отмену, отказ диспетчера, повторную заявку постоянного клиента.

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

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

Следующий шаг: найти главный разрыв

Составьте список систем, в которых сейчас живут заявки, расчёты, рейсы и оплаты. Затем выберите один разрыв, который должна закрыть CRM в первую очередь. Например, это потери заявок между каналами или передача согласованного заказа диспетчеру без подтверждения. Ближайший рабочий результат важнее полного набора функций.

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

Частые вопросы

Вывод

CRM транспортной компании наводит порядок в продажах: собирает заявки, фиксирует версии ставок и ведёт постоянных заказчиков. Рейсы, транспорт и юридически значимые документы остаются в профильных системах. Ценность появляется на стыке: когда согласованный заказ передан диспетчеру и CRM получила подтверждение, что его приняли. Начинать стоит с пилота, в котором проверены не только удачные заявки, но и исключения.

Источники

• amoCRM: отраслевое решение для транспортной компании
• amoCRM: типы пользовательских полей
• amoCRM: интерфейс программирования, авторизация и права
• Битрикс24: смарт-процессы, их возможности и доступность на тарифах
• 1С:Управление автотранспортом: заказы на перевозку и оперативное планирование
• 1С: профильные транспортные решения и сервис электронных перевозочных документов