CRM для логистики: как выбрать и чем она отличается от TMS
Транспортная компания, которая ищет «CRM для логистики», обычно ищет две разные вещи сразу. Одна половина запроса — про клиента: кто звонил, что просил, почему не поехали. Вторая — про рейс: машина, водитель, документы, сколько заработали. Это разные системы, и путаница между ними — главная причина, по которой внедрение потом буксует.
Где проходит граница
CRM отвечает за заявки клиентов, воронку продаж и историю переговоров. Рейсом занимается TMS — система управления перевозками: она ведёт весь цикл от заявки до закрывающих документов и расчёта рентабельности, вместе с диспетчерской частью. Граница между классами у современных решений постепенно стирается, но при выборе полезнее считать их разными контурами и спрашивать поставщика прямо, какой из них он закрывает по-настоящему, а какой «тоже умеет».
| Вопрос компании | Чей это контур |
|---|---|
| Откуда пришла заявка и почему клиент не поехал | CRM |
| История переговоров и договорённостей по ставке | CRM |
| Машина, водитель, статус груза по рейсу | TMS |
| Закрывающие документы по перевозке | TMS |
| Рентабельность рейса | TMS |
С чего начинать, если бюджет один
Разумный порядок определяется тем, где потери измеримы. Если входящие заявки теряются между диспетчерами, менеджер не помнит, какую ставку обещал в прошлый раз, а причина отказа клиента нигде не записана — сначала нужен клиентский контур. Если заявки не теряются, но рейсы, документы и заработок считаются в таблицах и сходятся с задержкой в неделю — начинать надо с TMS.
Худший вариант — подключить оба контура одновременно «чтобы сразу правильно» и получить два наполовину заполненных инструмента, из которых сотрудники продолжают работать в третьем месте.
Главный риск — двойной ввод
Если заявка заведена в CRM, а рейс оформляется отдельно и руками, расхождения появляются быстро: ставка в одной системе одна, в другой другая, изменения по срокам живут только в переписке диспетчера. Поэтому при выборе смотреть надо на конкретный механизм: что уходит из заявки в рейс, в какой момент, возвращается ли обратно статус и фактические цифры, и какая система считается источником правды при расхождении.
Проверка на демонстрации: попросите показать не гладкий сценарий, а срыв — клиент передвинул дату загрузки, когда машина уже назначена. Именно там видно, живая связка систем или красивая презентация.
Слепая зона: переговоры до заявки
В грузоперевозках значительная часть работы идёт голосом и в мессенджерах: уточнили габариты, обсудили ставку, договорились о переносе. В системе оседает результат, а сам разговор — нет. Отсюда классическая ситуация: клиент ушёл, а причина неизвестна, потому что она была произнесена в звонке и нигде не сохранилась.
Что с этим делать, мы разбирали отдельно: почему переписка из мессенджеров не попадает в CRM сама и сколько стоит расшифровка звонков по минутам. Для компании с длинным циклом сделки — а в B2B-логистике он длинный — это часто ценнее, чем ещё один отчёт по воронке.
Чек-лист перед оплатой
| Что проверить | Почему это важно |
|---|---|
| Какой контур поставщик закрывает по-настоящему | «умеем и то и другое» часто означает половину каждого |
| Механизм передачи заявки в рейс | ручной перенос = расхождения по ставке и срокам |
| Возврат статуса и фактических цифр в карточку клиента | иначе менеджер узнаёт статус звонком диспетчеру |
| Поведение при переносе даты и смене машины | самый частый реальный сценарий |
| Фиксируется ли причина отказа клиента | без неё воронка показывает потери, но не объясняет их |
| Попадают ли звонки и переписка в карточку | основная часть договорённостей проходит голосом |
Аксиома не заменяет ни CRM, ни систему управления перевозками — собирает звонки, переписку и обращения в одну карточку клиента поверх них, чтобы история договорённостей не терялась между диспетчерами и каналами.
Как устроена платформа →Вопросы про CRM в логистике
Чем CRM отличается от TMS в транспортной компании?
CRM отвечает за заявки, воронку продаж и историю переговоров. TMS ведёт весь цикл рейса: от заявки до закрывающих документов и расчёта рентабельности. Граница между классами постепенно стирается, но контуры разные.
Нужны ли обе системы сразу?
Начинать стоит с того контура, где потери измеримы: теряются заявки и причины отказов — клиентский, не сходятся рейсы и документы — TMS. Подключать оба одновременно рискованно.
Какой главный риск при выборе?
Двойной ввод: заявка в CRM, рейс отдельно. Проверять надо механизм передачи заявки в рейс и возврата статуса обратно, а не длину списка функций.
Продукт по теме
Похожие материалы
Источники
- Разграничение CRM и TMS для транспортной компании: CRM — заявки, воронка и переговоры; TMS — цикл рейса до закрывающих документов и рентабельности — cargorun.ru
- Обзор классов программ для транспортной компании и стирание границы между CRM и TMS — blog.keycrm.app
Разграничение классов систем приведено по обзорным материалам отраслевых разработчиков, снято 30.07.2026. Конкретные цены не указаны: в проверенных источниках они не публикуются в сопоставимом виде и зависят от парка машин и числа пользователей.