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

Как CRM помогает логистической компании управлять заявками

#14

Заявки, согласования, поставщики, договоры, статусы, сроки, риски, аналитика и SRM-система.

Короткий ответ

  • 1. Омниканальная лидогенерация
    CRM собирает обращения из всех используемых каналов в один список: заявка с сайта, письмо на почту компании или менеджера, звонок в офис, сообщение в мессенджере и запрос с тендерной площадки попадают в одну очередь с конкретным сроком обработки и ответственными за ее оперативность. У каждой заявки появляется закрепленный менеджер и статус, который видно и ответственному, и руководителю.
  • 2. Передача заявки из продажи в исполнение без потери контекста
    Внутри заявки хранятся и дополняются менеджером уточненные условия клиента: маршрут, груз, объем, сроки, требования к транспорту и документам. Эти данные не пересобираются заново при передаче заказа – логист открывает ту же карточку и работает с исходными формулировками клиента.
  • 3. Управление сквозными процессами
    Каждая заявка связана с клиентом, сделкой, перевозкой, документами, оплатами и сервисными обращениями. Из карточки клиента видно, что компания возила раньше, по каким тарифам, где были задержки, о чем договаривались в прошлый раз и какие активные перевозки сейчас.
Такая система дает руководителю полный контроль не только за работой департамента продаж, но и за эффективностью передачи информации между разными отделами, создавая единый слой управления сквозными бизнес-процессами. Далее обо всем поподробнее.
ГДЕ ЛОГИСТИЧЕСКАЯ КОМПАНИЯ ТЕРЯЕТ ЗАЯВКИ
ЧАСТЬ 1
Поток обращений в перевозках почти всегда разнородный. Одна часть приходит с сайта и из формы расчета, другая – на почту компании или менеджера, третья – звонком от постоянного клиента, четвертая – с тендерных площадок или через личные контакты сотрудников. Каждый канал живет по своим правилам, и общей картины по заявкам не складывается.
Обращения остаются в личных каналах
Клиент пишет знакомому менеджеру в мессенджер, тот отвечает с телефона и планирует занести запрос в таблицу позже. К примеру, если день оказался плотным, запрос не доходит ни до таблицы, ни до расчета. Можно привести еще с десяток подобных ситуаций, не сильно напрягая память.

Одна заявка дублируется в разных местах
Клиент отправил запрос через сайт и параллельно позвонил. Двое сотрудников считают стоимость для одной компании по одному маршруту, сами не догадываясь об этом, а клиент получает два разных ответа с разницей в тарифе. Как итог – двойная работа и обоснованные вопросы у клиента.
Заявка уходит логистам без полного набора данных
В расчет передаются маршрут и вес, а требования по температурному режиму, времени выгрузки или сопроводительным документам обсуждались устно или остались в личной переписке. Сюда же можно отнести пример, когда менеджер передает заявку логистам, субъективно “обрезая” контекст по разного рода причинам: перегруз, срочность, просто забытые или пропущенные данные и т. п.

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

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

КАК ВЫГЛЯДИТ ПУТЬ ЗАЯВКИ В CRM
ЧАСТЬ 2
Путь заявки – это последовательность этапов с обязательными данными, ответственным и сроком. Он настраивается в CRM как статусы и правила обработки заявок и далее повторяется для каждого обращения.
Регистрация обращения из различных источников
Заявка создается автоматически при отправке формы на сайте или сообщения в мессенджере, поступлении письма на подключенный ящик или звонке на офисный номер. В карточку сразу попадают источник, дата, контакт и текст обращения. Менеджеру не нужно вручную переносить письмо в систему – он получает готовую заявку с задачей. Более того, для каждого канала могут быть настроены свои правила по скорости обработки и ответственным.

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

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

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

С момента назначения у заявки есть ответственный и срок первого ответа. Обращений без владельца в системе не остается.
Расчет условий и подготовка коммерческого предложения
Менеджер готовит расчет на основе данных заявки. Шаблон предложения подтягивает маршрут, груз, сроки и условия из карточки, поэтому ошибки переноса вручную исчезают. Все версии расчета сохраняются в истории заявки – видно, что предлагали клиенту в первой редакции и что изменилось после переговоров.
Согласование, передача заказа логистам и контроль статусов
После подтверждения клиентом заявка переходит в заказ. Логист получает задачу с полным набором данных и работает с той же карточкой, дополняя ее информацией о перевозчике, машине и рейсе. Продажи видят текущий статус перевозки и отвечают клиенту без звонка коллегам.

Если исполнение ведется в TMS, CRM передает согласованный заказ туда и принимает обратно статусы, информацию по рейсам/вагонам/контейнерам в зависимости от вида перевозки и их точное местонахождение. Как итог – любой сотрудник видит движение груза в карточке клиента, не заходя в транспортную систему.

Можно пойти еще дальше и дать возможность клиенту самому видеть всю необходимую информацию по своему заказу, связав CRM с клиентским порталом.
Закрытие заявки, документы, оплата, причина отказа и следующий контакт
Завершенная перевозка закрывается комплектом документов и отметкой об оплате. Если клиент отказался на каком-то этапе, менеджер выбирает причину из списка: цена, сроки, отсутствие транспорта, ушел к конкуренту, перенес отгрузку и т. п. Для каждой закрытой заявки задается следующий шаг – запрос обратной связи, звонок через месяц, отправка обновленных тарифов.
Путь заявки в CRM держится на трех составляющих: у каждого этапа есть обязательные данные, ответственный и срок. Как только один из трех элементов пропадает, заявки снова начинают теряться между людьми.
Этапы обработки заявки
ЧТО ХРАНИТЬ В КАРТОЧКЕ КЛИЕНТА И ЗАЯВКИ
ЧАСТЬ 3
Клиентская база в логистике держится на операционной истории. Кроме контактов и реквизитов, в карточке живет информация о том, что возили, откуда, чем, как часто и с какими сложностями – именно она нужна менеджеру при следующем обращении.

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

В самой заявке лежат условия конкретной перевозки: маршрут с точками, груз и упаковка, даты и временные окна, тип транспорта, стоимость расчета, статус и причина отказа при потере. Общие сведения о компании остаются на уровне карточки клиента и не дублируются в каждом обращении.
Обязательные поля заявки и зона ответственности
КАКИЕ ОПЕРАЦИИ С ЗАЯВКАМИ МОЖНО АВТОМАТИЗИРОВАТЬ
ЧАСТЬ 4
Автоматизация в работе с заявками закрывает рутину, где чаще всего происходят потери: прием, распределение, напоминания и передача данных между отделами.

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

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

Проверка дублей и объединение истории
Система находит совпадения по реквизитам и контактам, предлагает объединить записи и сохраняет единую историю заказов по клиенту.

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

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

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

Обратная связь и повторная коммуникация
После завершения перевозки запускается запрос оценки качества, а через заданный срок – задача на повторный контакт с клиентом.
Автоматизировать имеет смысл повторяющиеся шаги с понятными правилами. Согласование нестандартных условий и переговоры по крупным контрактам остаются за людьми, а система обеспечивает их полными данными и структурой.
КАК CRM СВЯЗЫВАЕТ ПРОДАЖИ, ЛОГИСТОВ И КЛИЕНТСКИЙ СЕРВИС
ЧАСТЬ 5
Заявка на перевозку проходит через несколько подразделений, каждое из которых работает со своей частью данных. Проблемы начинаются там, где данные передаются пересказом: в чате, в устной постановке задачи или в письме с частичными условиями.

В общей системе передача происходит по-другому: следующий участник открывает ту же карточку и видит все, что было зафиксировано до него. Повторно запрашивать информацию у клиента не приходится.
Ценность общей системы для перевозок измеряется отсутствием разрывов между отделами: клиент один раз сообщает условия, и они доходят до исполнителя без искажений.
ЧЕМ CRM ОТЛИЧАЕТСЯ ОТ TMS И ERP
ЧАСТЬ 6
Три системы часто путают, потому что все они «про перевозки и деньги». Разница в объекте работы: у CRM это клиент и его обращение, у TMS – рейс и транспорт, у ERP – ресурсы и учет компании.
Сценарий совместной работы выглядит так. Заявка приходит в CRM, там же проходит проверка клиента, расчет и согласование условий. После подтверждения заказ передается в TMS, где планируется рейс и назначается транспорт. Статусы возвращаются в CRM, поэтому менеджер отвечает клиенту без переключения между системами. Закрывающие документы и оплаты фиксируются в ERP, а в карточке клиента видно, оплачен заказ или нет.

Приписывать CRM функции транспортной системы не стоит: планирование загрузки машин, расчет плеч и работа с путевыми документами остаются задачей TMS. Практический вопрос при выборе решения звучит иначе – какие данные и в какую сторону должны ходить между системами.
КАКИЕ ПОКАЗАТЕЛИ ДОЛЖЕН ВИДЕТЬ РУКОВОДИТЕЛЬ ОТДЕЛА ПРОДАЖ
ЧАСТЬ 7
Отчетность по заявкам собирается из данных, которые заполняются в процессе работы. Чем строже правила по статусам, причинам отказа и следующему действию, тем меньше расхождений между отчетом и реальностью.
Пример дашборда: заявки по каналам, время первого ответа, конверсия этапов, просрочки и загрузка менеджеров
Нормативных значений по этим метрикам в отрасли нет: время ответа в сборных грузах и в проектной логистике отличается в разы. Ориентироваться стоит на собственную динамику – как показатель менялся до и после изменений в процессе.
КАК ВНЕДРИТЬ CRM ДЛЯ РАБОТЫ С ЗАЯВКАМИ
ЧАСТЬ 8
Запуск системы в перевозках редко проходит гладко, если начинать с настройки полей. Полезнее сначала разобрать текущий процесс и найти в нем места потерь.
Шаг 1. Собрать реальные каналы и типы заявок
Выписать все источники обращений, включая личные контакты менеджеров и тендерные площадки. Отдельно перечислить типы: разовая перевозка, регулярные отгрузки, тендер, запрос на расчет, сервисное обращение по текущему заказу.

Шаг 2. Описать текущие процессы, статусы, ответственных и обязательные данные
Зафиксировать, как заявка движется сегодня, какие статусы движения нужно отслеживать, кто за что отвечает в рамках этого движения и какие данные нужны на каждом шаге. Здесь обычно выясняется, что у продаж и логистов разные названия одних и тех же этапов.

Шаг 3. Найти потери, дубли и ручные передачи между отделами
Отследить несколько заявок целиком – от обращения до закрытия. Точки, где данные переносятся вручную или пересказываются устно, дают список первых улучшений.
Шаг 4. Настроить пилотный процесс на одном направлении перевозок
Взять одно направление или одну услугу, настроить путь заявки, поля и правила распределения. Пилот на ограниченном объеме показывает ошибки настройки быстрее, чем запуск на всю компанию.

Шаг 5. Подключить каналы, уведомления и отчеты
Завести формы сайта, почту, телефонию и мессенджеры в систему, настроить напоминания по срокам и базовый набор отчетов для руководителя.

Шаг 6. Сравнить показатели до и после запуска
Сопоставить время первого ответа, срок обработки, конверсию и причины отказов с данными до внедрения. Сравнение помогает отделить реальные изменения в процессе от ощущений команды.
ОТРАСЛЕВОЕ РЕШЕНИЕ
ЧАСТЬ 9
После того как требования к процессу описаны, выбор сводится к проверке: закрывает ли платформа путь заявки целиком и настраивается ли под конкретные услуги компании. Система CRM для транспортной компании оценивается по связке заявки с клиентом, заказом и документами. Длина списка функций в презентации о пригодности решения говорит мало.

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

Ключевой критерий при оценке любой платформы остается тем же: заявка, клиент, заказ, документы и оплаты должны жить в одной связке. Отдельные списки, которые сотрудники сводят вручную, дают тот же результат, что и таблицы до внедрения.
ОШИБКИ ПРИ ЗАПУСКЕ CRM В ЛОГИСТИКЕ
ЧАСТЬ 10
Перенос всех полей из старых таблиц
В файлах накапливаются столбцы, которые давно никто не заполняет. Переезд в систему – хороший момент проверить, какие данные действительно используются в работе и в отчетах.
Слишком много обязательных полей на первом этапе
Если для регистрации входящего звонка требуется двадцать заполненных полей, менеджеры начнут заводить заявки задним числом или мимо системы.
Разные статусы у продаж и логистов
Когда «в работе» у одного отдела означает подготовку расчета, а у другого – выехавшую машину, сводная отчетность перестает отражать реальность.
Нет ответственного за качество клиентской базы
Без владельца процесса дубли, пустые реквизиты и брошенные карточки накапливаются, и через полгода отчет по клиентам приходится собирать вручную.
Попытка заменить системой весь функционал TMS и ERP
Дописывание в CRM планирования рейсов и полноценного финансового учета затягивает проект и усложняет поддержку. Практичнее настроить обмен данными между системами.
Отчеты без правил заполнения
Пока этапы, причины отказа и следующее действие заполняются по-разному, любые цифры в отчете остаются приблизительными.
ЧЕК-ЛИСТ ВЫБОРА СИСТЕМЫ CRM ДЛЯ ТРАНСПОРТНОЙ КОМПАНИИ
ЧАСТЬ 11
  • Система принимает заявки из нужных каналов: сайт, почта, телефония, мессенджеры, тендерные площадки
  • Карточка клиента связана с заявками, сделками, заказами, перевозками, документами и оплатами
  • Настраиваются правила распределения заявок и сроки ответа с уведомлениями о просрочке
  • Повторяющиеся ручные операции могут быть сведены к минимуму и автоматизированы на самой платформе CRM
  • Есть роли и права доступа для продаж, логистов, диспетчеров, сервиса и руководителей
  • Доступны интеграции с TMS, ERP и учетными системами
  • Отчеты показывают потери заявок, сроки обработки, конверсию этапов и загрузку команды
  • Процесс в системе может корректироваться силами компании по мере появления новых услуг, направлений и маршрутов
  • Поставщик поддерживает требования по размещению данных и импортозамещению, если это критично для клиентов компании
FAQ
ЧАСТЬ 12
Какие заявки можно вести в CRM транспортной компании?
Обращения на перевозку, тендерные заявки, запросы на расчет стоимости, повторные заказы постоянных клиентов и сервисные обращения по текущим перевозкам. Для каждого типа настраивается свой путь этапов и набор обязательных данных.

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

Может ли CRM заменить TMS?
Потенциально да, но зависит от класса выбранной системы. Мы рекомендуем вести работу с клиентом, заявкой и сделкой в CRM, а планирование и исполнение перевозок – в TMS. Системы связывают интеграцией: согласованный заказ уходит в TMS, статусы возвращаются в карточку клиента.
Как CRM помогает не терять заявки?
Обращение фиксируется автоматически, у заявки появляются ответственный, срок и следующее действие. Просрочки видны в отдельном списке, уведомления о них приходят руководителю, а история общения хранится в карточке клиента и доступна любому сотруднику с нужными правами.

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

С чего начать выбор системы CRM для транспортной компании?
С описания текущего пути заявки и списка потерь в нем. Требования к системе формулируются из этой информации, а сравнение решений идет по их способности закрыть конкретные шаги обозначенного процесса.
ВЫВОД
CRM для транспортной компании решает задачу управления заявками: обращения из всех каналов попадают в один список, у каждого появляется владелец, срок и статус, а условия клиента доходят до логистов без пересказа.
Связка заявки с клиентом, заказом, перевозкой и документами дает руководителю честную картину по срокам, конверсии и причинам потерь.
PS
Еще до сравнения CRM-продуктов начинать стоит с разбора текущего процесса: где приходят заявки, кто их обрабатывает, какие данные теряются при передаче. С этим описанием на руках выбрать и настроить систему получается быстрее, чем при запуске «как у всех».