Антон Дегтярёвбитрикс24 для транспортной компании
Транспортная компания на 30 машин приходит с одной и той же болью: заявки живут в почте и вотсапе, диспетчер держит загрузку парка в голове и в жёлтом блокноте, а когда он уходит в отпуск, компания на неделю теряет управляемость. CRM тут нужна не для продаж — она нужна как единое место, где видно, какая машина под какой заявкой и когда освободится. Ниже — как я собираю такую конфигурацию на Битрикс24 без разработки под заказ, на штатных инструментах.
почему обычная воронка продаж здесь не работает
В классической CRM сделка идёт по одной линии: лид, переговоры, счёт, оплата, закрыта. В перевозках линий две, и они живут в разном темпе.
Первая — коммерческая: клиент прислал заявку, мы посчитали ставку, согласовали, подписали. Вторая — исполнительская: машина подана, груз загружен, рейс идёт, груз выдан, документы вернулись, счёт закрыт. Вторая линия начинается, когда первая уже наполовину пройдена, и заканчивается через две-три недели после того, как коммерсант считает сделку выигранной.
Если склеить обе линии в одну воронку, получится 15 этапов, половина из которых не про продажу. Диспетчер и менеджер будут таскать одну и ту же карточку в разные стороны, и через месяц никто не поймёт, что означает этап «в работе».
Я развожу их так: сделка — только коммерческая часть, рейс — отдельная сущность со своей воронкой. Связь один ко многим: по одной сделке может быть три рейса, по одной заявке на регулярные перевозки — тридцать.
машины и водители — не поля, а справочники
Первый порыв на внедрении — завести в сделке поля «госномер» и «водитель» списком. Через два месяца выясняется, что этого мало: нужно знать, когда у машины заканчивается страховка, какая у неё грузоподъёмность, кто из водителей допущен к рефрижератору и у кого через месяц истекает медсправка.
Правильно завести два справочника на смарт-процессах — «транспортные средства» и «водители». В карточке ТС: госномер, марка, тип кузова, грузоподъёмность в тоннах и кубах, дата окончания ОСАГО и техосмотра, признак собственная/наёмная, текущий статус. В карточке водителя: ФИО, телефон, категории, срок действия прав и медсправки, привязка к машине по умолчанию.
Это даёт две вещи. Во-первых, в карточке рейса машина выбирается связью с реальной записью, а не текстом, — и оттуда сразу подтягивается грузоподъёмность. Во-вторых, на даты можно повесить автоматику: за 30 дней до окончания страховки ответственному прилетает задача. На парке в 30 единиц это экономит механику несколько сорванных выездов в год.
Про то, как устроены смарт-процессы и что в них можно, я писал отдельно — смарт-процессы в Битрикс24.
воронка заявки — семь этапов, которые держатся
Этапы, которые я ставлю в коммерческой воронке транспортной компании: новая заявка, уточнение параметров груза, расчёт ставки, ставка отправлена, согласование, заявка подтверждена, передана в диспетчерскую. Выигрыш — не «оплачено», а именно передача в исполнение.
Ключевой этап — уточнение параметров. Клиент почти никогда не присылает всё сразу: приходит «нужна фура из Москвы в Казань», а вес, объём, тип погрузки, дата и адреса выясняются в переписке. Поэтому на этом этапе стоит обязательный набор полей, без заполнения которых сделка не двигается дальше: точки погрузки и выгрузки, вес, объём, тип кузова, дата подачи, требуется ли гидроборт, есть ли ограничение по въезду.
Требование обязательности — не бюрократия. Именно из этих шести полей потом автоматически считается ставка и подбирается машина. Если поля пустые, дальше по цепочке всё делается руками.
Про то, как правильно настраивать поля, чтобы менеджеры их заполняли, а не игнорировали, — в материале настройка полей CRM в Битрикс24.
как назначается машина и водитель
Полной автоматизации подбора я не делаю и не советую — слишком много неформальных факторов: кто где стоит, кто с каким клиентом уже ездил, кто в отгуле. Задача автоматики другая: сузить выбор до трёх-пяти вариантов, а решение оставить диспетчеру.
Работает это так. При переходе заявки в диспетчерскую создаётся карточка рейса. В ней диспетчер выбирает машину из справочника, но список отфильтрован по грузоподъёмности и типу кузова из заявки, а занятые в этот период машины помечены. Дальше подтягивается водитель по умолчанию, диспетчер при необходимости меняет.
Отдельно проверяются стоп-факторы: истекшая страховка, просроченная медсправка, машина на ремонте. Это простое правило на статусе — если у ТС стоит статус «ремонт» или дата ОСАГО в прошлом, назначить её нельзя.
В одной компании, где до внедрения загрузка велась в общей таблице, после запуска такой схемы количество случаев «две заявки на одну машину» упало с 3–4 в месяц до нуля за первый же квартал. Не потому что автоматика умная, а потому что занятость машины стала видна всем в одном месте.
рейс как отдельный процесс
Карточка рейса — это второй смарт-процесс со своей воронкой: назначен, машина подана, загружен, в пути, выгружен, документы получены, закрыт.
Что живёт в карточке: связь со сделкой и клиентом, машина, водитель, маршрут с километражем, плановые и фактические даты, ставка клиенту, затраты (топливо, суточные, платные дороги, оплата наёмнику), приложенные документы.
Смысл выделения рейса в отдельную сущность становится очевиден на регулярных клиентах. Договор с торговой сетью — это одна сделка и восемьдесят рейсов в месяц. Пытаться уместить это в сделку невозможно, а в связке «сделка → рейсы» всё раскладывается ровно и считается автоматически.
Переходы по этапам рейса удобно вешать на водителя через мобильное приложение: загрузился — нажал кнопку, выгрузился — нажал и приложил фото документов. Приучить водителей к этому — самая тяжёлая часть проекта. Мой опыт: без прямого распоряжения руководства и двух недель контроля не приживается, зато после — работает годами.
документы, которые вечно теряются
Главная операционная дыра в перевозках — возврат оригиналов. Груз доставлен, а закрывающие документы едут обратно с водителем, потом лежат в бардачке, потом на столе у логиста, и счёт клиенту уходит с задержкой в три недели.
Схема, которая это чинит, простая. На этапе «выгружен» водитель обязан приложить фото подписанных документов — без вложения рейс не переводится дальше. Скан уходит в бухгалтерию сразу, счёт выставляется по нему, а оригиналы догоняют потом. На этапе «документы получены» отмечается уже физическое получение оригиналов.
Заявку на перевозку и договор-заявку удобно генерировать прямо из карточки по шаблону — реквизиты, маршрут, ставка и данные машины подставляются из полей, менеджер не перепечатывает их вручную. Это снимает второй типовой источник ошибок: госномер и ФИО водителя в заявке, отличающиеся от тех, что реально приехали на погрузку.
По просроченным оригиналам ставится простое правило: если через 14 дней после выгрузки на рейсе нет отметки о получении оригиналов, логисту прилетает задача. Как собирать такие правила без программиста — в разборе роботы и триггеры Битрикс24.
что считать в отчётах
Выручка по клиентам в перевозках почти ничего не говорит: крупный клиент с длинным плечом и низкой ставкой может приносить меньше денег, чем мелкий с короткими рейсами.
Считать нужно маржу рейса и производную от неё — доход на километр. Для этого в карточке рейса и должны лежать затраты: топливо, суточные, платные участки, ремонт в пути, оплата привлечённому перевозчику. Разница между ставкой и суммой затрат — маржа, делённая на километраж — тот самый рубль на километр.
Три среза, которые я вывожу руководителю в первую очередь: маржа по машинам за месяц (видно, какая единица парка не окупается), маржа по направлениям (видно, какие плечи стоит брать, а какие — только под обратную загрузку), доля порожнего пробега.
Порожний пробег — отдельная метрика, ради которой стоит терпеть заполнение километража. Когда компания впервые видит, что 22% пробега порожние, разговор о загрузке обратных рейсов начинается сам собой.
сроки и объём работ
Типовой проект по этой схеме занимает у меня 3–4 недели при парке до 50 машин. Раскладка примерно такая: неделя на описание процессов и согласование этапов, полторы недели на настройку двух смарт-процессов, воронки, полей и автоматики, несколько дней на шаблоны документов и отчёты, неделя на обучение и сопровождение первых рейсов.
Разработки под заказ в базовой конфигурации нет — всё собирается штатными инструментами. Отдельным бюджетом идут интеграции: телефония, почта, обмен с 1С по документам и взаиморасчётам.
Что почитать дальше: если у вас не собственный парк, а доставка последней мили — там другая специфика, разобрал её в статье Битрикс24 для логистики и доставки. Если хотите понять, из каких этапов вообще состоит проект внедрения и на что уходит время, — этапы внедрения Битрикс24.