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

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

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

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

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

CRM должна держать границу между продажей, перевозкой и учётом

Главный вопрос здесь не «какую CRM выбрать», а где заканчивается один процесс и начинается другой. Для грузоперевозчика удобно разделить работу на три контура.

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

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

Такое разделение избавляет от ложной универсальности. Менеджеру не нужно видеть каждое изменение рейса, если его задача - договориться с клиентом и вовремя сообщить об отклонении. Диспетчеру не нужно продираться через коммерческие заметки, чтобы назначить машину. А руководитель получает два разных набора показателей: конверсию заявок и состояние исполнения.

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

Начните с пути одной заявки, а не с перечня полей

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

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

Для такого маршрута нужно ответить на пять рабочих вопросов:

1. Из каких каналов приходят обращения и кто первым берёт их в работу?
2. Какие данные действительно нужны, чтобы рассчитать и подтвердить перевозку?
3. В какой момент заявка становится обязательством компании, а не просто запросом цены?
4. Какие события должен видеть менеджер, чтобы не обещать клиенту статус по памяти?
5. Где возникает первичный факт: в CRM, учётной системе, TMS, приложении водителя или вручную у диспетчера?

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

На этой карте быстро появляются места, где данные теряются. Например, менеджер получил запрос в личный мессенджер, но не создал карточку. Или логист сообщил об изменении времени в чате, а клиенту никто не написал. Это проблемы маршрута и ответственности, а не отсутствия «правильной» кнопки в CRM.

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

Статус полезен, если по нему можно понять текущее обязательство, ответственного и следующий шаг. Формулировка «в работе» удобна как временная корзина, но для перевозки она почти ничего не сообщает: ждём подтверждения клиента, ищем перевозчика, машина на погрузке или рейс задерживается?

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

Важнее названия статусов правила перехода. К примеру, на этапе «Перевозчик назначен» нельзя оставлять пустыми исполнителя и согласованную дату подачи. В смарт-процессах и CRM можно сделать пользовательское поле обязательным для конкретной стадии (Битрикс24, «Пользовательские поля в счетах и смарт-процессах»). Но обязательное поле имеет смысл только там, где человек уже располагает данными. Требовать номер транспортной накладной до доставки означает заставить сотрудника ставить заглушку.

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

Каналы общения нужно привязать к ответственному и сроку ответа

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

Если для общения используется Битрикс24, открытые линии собирают сообщения из подключённых мессенджеров, соцсетей и онлайн-чата; обращения можно распределять по очереди или на ответственного за клиента. В документации также указано, что система сохраняет данные клиента в CRM и позволяет отслеживать скорость ответов (Битрикс24, «Как создать и настроить открытую линию»). Это помогает собрать входящие обращения, но не решает вопрос, кто обязан объяснить перенос подачи. Правило нужно закрепить отдельно.

Для каждого канала определите три вещи: как создаётся или находится карточка, кому назначается диалог и какое событие закрывает обещание клиенту. Например, менеджер отвечает на запрос цены, а при статусе «Есть отклонение» логист указывает новый прогноз и причину; после этого менеджеру приходит задача связаться с клиентом. Если клиент общается только с логистом, это тоже допустимо, но ответственный должен быть виден в карточке.

Не стоит включать автоматические уведомления на каждый переход. Сообщение «статус изменён» без времени, действия и понятного значения только увеличит поток писем. Автоматизация полезна на контрольных точках: подтверждена подача, требуется уточнение, есть отклонение, доставлено. Роботы в CRM можно настроить по стадиям: они выполняют действия при попадании элемента на стадию, а триггеры могут реагировать на события и перемещать элемент дальше (Битрикс24, «Автоматизация продаж в CRM»). Сначала протестируйте два-три таких сценария на реальных ролях, потом расширяйте их.

Интеграция начинается с владельца данных, а не с обмена «всем со всем»

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

Перед постановкой задачи на интеграцию соберите таблицу обмена.

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

Для внутренней интеграции конкретного портала Битрикс24 допускает входящие и исходящие вебхуки REST API. Входящий вебхук работает с правами пользователя, который его создал; официальный справочник отдельно предупреждает, что его секретный URL нельзя разглашать, а права нужно ограничивать нужными инструментами (Битрикс24 REST API, «Входящие и исходящие вебхуки»). Это техническая возможность, а не архитектура обмена. Сначала утвердите таблицу владельцев и сценарии ошибок, затем выбирайте метод интеграции.

Когда CRM для грузоперевозок лучше не усложнять

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

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

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

Практический инструмент: карта первого контура перевозки

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

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

Короткие ответы на частые вопросы

01Можно ли вести всю перевозку в CRM?

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

02Нужна ли отдельная карточка перевозки, если уже есть сделка?

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

03Какие статусы показывать клиенту?

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

04Можно ли автоматически передавать статусы из учётной системы?

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

05С чего начать внедрение CRM для логистики и грузоперевозок?

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

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