Аренда спецтехники на Битрикс24: почему обычного внедрения не хватает

Мы в X-Form внедряем Битрикс24 с 2007 года, а последние годы всё чаще работаем с компаниями, которые сдают в аренду спецтехнику. Эта отрасль удобна для разбора: процесс в ней короткий и жёсткий, а деньги теряются в двух-трёх совершенно конкретных местах. Расскажу, что мы сделали для ярославского «Технопарка» и почему обычная настройка CRM там не закрывает задачу.

Сразу оговорюсь про цифры ниже: это результаты заказчика, названные заказчиком. Мы их не измеряли независимо, и относиться к ним стоит как к оценке компании, а не как к замеру.

Что было

«Технопарк» — один из лидеров региона по аренде спецтехники: автопарк больше пятидесяти единиц, больше семидесяти сотрудников. Учёт вёлся в Excel и мессенджерах.

Со слов руководителя компании, это стоило примерно следующего: до 15% клиентов терялось из-за ошибок в учёте, дебиторская задолженность доходила до 15–20 миллионов рублей.

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

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

Почему обычное внедрение здесь не закрывает задачу

Это главное, ради чего стоит читать дальше, и главная причина, по которой проекты в аренде буксуют.

Сделка не видит ресурс. Битрикс24 прекрасно ведёт сделку от обращения до оплаты, но стандартная логика сделки ничего не знает о том, что экскаватор с восьми до часу занят на другом объекте, а водитель в это время в рейсе. Для продаж это и не нужно. Для аренды — это и есть суть работы: менеджер не столько продаёт, сколько распоряжается занятым ресурсом.

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

Второе расхождение — в том, что предмет учёта не сделка, а заявка. Один заказ — это часто несколько выездов, разная техника, разные водители и разные даты. Пока единицей учёта остаётся сделка, всё это живёт в комментариях, а значит нигде.

Что мы построили

Коротко о конструкции, без интерфейсных подробностей.

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

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

Защита от двойного бронирования. Система сама определяет доступность: машину нельзя забронировать, если она уже в рейсе, водителя нельзя назначить, если он занят на другой заявке. Это не подсказка и не предупреждение, а запрет — иначе смысла в нём нет.

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

Снято на «1С-Битрикс24: Корпоративный портал 50»

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

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

Снято на «1С-Битрикс24: Корпоративный портал 50»

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

Документы в одной цепочке. Заявка, работа, счёт, оплата и закрывающие связаны между собой и не теряются между отделами.

Где на самом деле лежат деньги

Если из всего кейса запомнить один абзац, пусть будет этот.

Деньги в аренде теряются не на скорости менеджера, а в двух местах: в разнице между планом и фактом и в дебиторке.

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

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

Всё остальное — скорость, удобство, порядок в документах — приятные следствия, но платит бизнесу именно эта пара.

Что получилось

Ещё раз: цифры названы заказчиком.

Что	Результат
Скорость обработки заявок	+40%
Дебиторская задолженность	сократилась в 2,5 раза
От звонка клиента до выставленного счёта	15 минут
Экономия времени бухгалтерии	20 часов в месяц
Экономия времени руководителя	8–16 часов в месяц
Окупаемость проекта	4 месяца

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

Что из этого следует для похожих проектов

Это не наблюдения за годы, а выводы из самой конструкции — но они, кажется, переносятся на любой проект в аренде.

Начинать нужно с ресурса, а не с воронки. Если сначала настроить стадии сделки и только потом думать про технику и водителей, переделывать придётся именно воронку: она стоит на ресурсе, а не наоборот.

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

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

Водитель работает в телефоне. Любой сценарий, который требует от водителя сесть за компьютер, останется незаполненным, а вместе с ним незакрытым останется факт — то самое место, где и теряются деньги.

---

Александр Румянцев, X-Form. Внедряем и автоматизируем Битрикс24 с 2007 года, Ярославль. Отраслевое решение для аренды спецтехники — «Аренда PRO». Цифры результатов приведены со слов заказчика, ООО «Технопарк», Ярославль; независимого замера мы не проводили.