Как связать продажу, договор, объект и обязательства подрядчиков, не превращая CRM в замену сметной или производственной системы.
Заявка на ремонт или строительство приходит в мессенджер. Менеджер договаривается о выезде, готовит предложение, клиент подписывает договор. Дальше в работу входят руководитель проекта, снабжение, прораб и подрядчики. У каждого свой чат, своя таблица и свой способ помнить о сроках. Когда заказчик спрашивает, почему сдвинулся этап, руководитель часто собирает ответ вручную: звонит на объект, ищет последнюю версию договора, сверяет сообщения.
Покупка CRM сама по себе эту картину не склеит. Сначала компании нужно договориться, какие события она обязана видеть: куда попало обращение, на каких условиях продали работы, что происходит по объекту и кто должен сделать следующий шаг. Затем уже выбирать карточки, статусы и автоматизацию.
Спешите? В FAQ есть ответы, когда можно начать с одной сделки и почему подрядчика не стоит вести как обычного клиента.
В CRM стоит собрать четыре связанных контура
Прямой ответ на главный вопрос: строительной компании полезно объединить в CRM входящие заявки, коммерческую воронку, карточку проекта и контроль обязательств подрядчиков. Не каждый рабочий процесс на стройке должен оказаться в одной системе. Сметы, детальные графики работ, закупки, бухгалтерские документы и исполнительная документация часто уже живут в профильных программах или регламентах. Переносить их в CRM без понятной цели означает создать второй источник данных.
У этих четырёх контуров разные владельцы и разные вопросы. Продажа отвечает, будет ли договор и что обещано заказчику. Проект отвечает, что происходит на объекте после договора. Карточка подрядчика хранит постоянные сведения о контрагенте. А обязательство подрядчика показывает конкретную работу в конкретном проекте: объём, срок, ответственного и результат приёмки.
| Контур | На какой вопрос отвечает | Кто поддерживает запись |
|---|---|---|
| Заявка и сделка | Откуда пришёл заказчик, что ему нужно, на какой стадии продажа | менеджер или коммерческий руководитель |
| Договор и проект | Что продали, какой объект, плановые контрольные даты, текущая остановка | руководитель проекта |
| Подрядчик | С кем компания уже работает, документы, допуски, контакты | ответственный за контрагентов или руководитель проекта |
| Обязательство подрядчика | Что именно поручено на объекте, к какому сроку, принято ли выполнение | руководитель проекта, прораб или координатор |
У генподрядчика, девелопера и компании со своими бригадами будут разные этапы и документы. Но важное изменение должно вноситься в одном месте и понятным человеком. Иначе у компании появляются три версии обещания клиенту: в сделке, чате и таблице.
В Битрикс24 для объектов, договоров и других нестандартных сущностей можно использовать смарт-процессы с собственными полями, стадиями, правами доступа и связями с CRM. Это подтверждает официальная справка. Сначала опишите маршрут проекта, затем создавайте карточки.
Продажа заканчивается раньше, чем заканчивается работа с клиентом
Сделка удобна, пока команда выясняет потребность, готовит расчёт, согласует цену и условия. После подписания договора она перестаёт быть достаточной: в ней смешиваются коммерческие переговоры, план проекта, замечания по объекту и работа нескольких исполнителей. Карточка превращается в длинную ленту, где сложно понять, что уже продано, а что прямо сейчас задерживает работы.
Отдельный проект появляется в точке, которую компания считает своим обязательством. Например, после подписания договора и получения согласованного аванса. Этот момент нужно закрепить в регламенте. Если сегодня проект создают после первого выезда, завтра после сметы, а послезавтра только после оплаты, отчёты не покажут реальную загрузку.
Связь сделки и проекта нужна в обе стороны. Менеджер должен видеть, что на объекте возникло обстоятельство, которое влияет на обещанный срок. Руководитель проекта должен открыть договорённости с клиентом, не спрашивая коллегу в личном чате. При этом права на изменение различаются: руководитель проекта может зафиксировать риск по сроку, но новое коммерческое обязательство перед заказчиком должен подтверждать назначенный ответственный.
В CRM можно создавать новый элемент на основании другого: система переносит данные в новую карточку и сохраняет связь с исходной. Документация Битрикс24 описывает этот механизм. В строительной схеме он подходит для создания проекта из успешной сделки, если заранее проверить состав передаваемых полей.
Воронка продаж нужна до первого обязательства по объекту
Воронка продаж не должна повторять календарный план строительства. Её задача проще: показать, где менеджер работает с заказчиком и какое действие приближает договор. Например: новое обращение, квалификация, выезд или встреча, подготовка предложения, согласование условий, договор, выиграно или проиграно.
Не копируйте чужие стадии с названиями вроде «в работе». Такой статус прячет больше, чем показывает. «Подготовка предложения» предполагает конкретный результат. «Согласование условий» даёт руководителю повод проверить, какие условия меняются и кто ждёт ответа. Для каждой стадии полезно назвать владельца, следующее действие и условие перехода.
Битрикс24 позволяет настраивать отдельные воронки, стадии, карточки и права доступа. Официальная справка подтверждает, что направления могут иметь разные сценарии. Разделяйте частных и корпоративных заказчиков только при различающихся договоре, согласовании или ответственности. При одинаковом процессе воронка раздробит данные.
На старте не пытайтесь обязать менеджера заполнить всю будущую паспортную информацию объекта. В заявке нужны данные, по которым принимают коммерческое решение: контакт, тип работ, локация, источник обращения, предполагаемый объём, дата следующего действия. Точный состав работ, график и документы появляются позже, когда их уже есть кому подтвердить.
Проекту нужны контрольные точки, а не имитация стройплощадки в канбане
Статусы проекта должны обозначать управленческие события: договор передан в проект, подготовлен старт работ, идут работы, есть риск по сроку, этап готов к приёмке, этап принят, проект закрыт. Не стоит делать карточки задачами «залить бетон», «привезти крепёж» или «созвониться с электриком», если для этого команда уже использует календарный план или диспетчеризацию. Руководителю проекта важнее увидеть, что блокирует следующий контрольный результат.
Хороший тест для этапа: по нему можно принять действие. Статус «риск по сроку» требует назначить разбор и решить, что сказать заказчику. Статус «в процессе» сам по себе ничего не предлагает. Если бригада не смогла выйти, а нужный материал не согласован, это разные причины. Они должны быть отдельным полем или классификацией, иначе руководитель увидит лишь красную карточку без возможности понять масштаб проблемы.
Ниже приведена условная модель карточки проекта. Набор полей нужно проверить на одном реальном объекте вместе с теми, кто продаёт, ведёт проект и принимает работы.
| Блок карточки | Что можно зафиксировать | Для какого решения |
|---|---|---|
| Связи | сделка, заказчик, договор, объект, руководитель проекта | быстро открыть исходные договорённости и ответственных |
| Обязательства | состав работ верхнего уровня, согласованная дата начала и контрольные даты | понять, что именно обещано и какой этап под угрозой |
| Ход проекта | текущая контрольная стадия, причина блокировки, ближайшее действие, дата следующей проверки | снять неопределённость без обхода чатов |
| Подрядчики | связанные обязательства, ответственные, документы или ссылки на них | проверить, чья работа влияет на этап |
| Коммуникация с заказчиком | последнее согласованное сообщение, кто должен связаться, дата контакта | не оставлять клиента без объяснения при изменении плана |
Карточка не должна превращаться в электронную папку со всеми файлами и перепиской. Если проектировщик обязан загрузить туда каждую версию чертежа, а затем повторить действие в рабочем хранилище, он быстро перестанет обновлять одну из систем. В CRM оставляют сведения для передачи ответственности и управленческого контроля, а также ссылку на место, где хранится актуальный документ.
Подрядчик и его обязательство лучше разделить
В карточке подрядчика удобно хранить то, что повторяется между проектами: юридическое наименование, контакты, специализацию, сведения о необходимых документах и ответственных за взаимодействие. Но сама карточка не отвечает, что этот подрядчик делает на конкретном объекте прямо сейчас.
Для этого нужна связанная запись обязательства подрядчика. В ней фиксируют проект, вид работ, назначенного представителя, контрольную дату, требуемый результат, статус приёмки и причину задержки. Один подрядчик может иметь несколько обязательств в одном проекте или работать на нескольких объектах одновременно. Если держать всё в одном поле «подрядчик», вы не увидите, какая именно работа зависла.
Такая запись не заменяет договорной и финансовый учёт. Она показывает, что должно случиться дальше, кто отвечает и влияет ли задержка на обещание заказчику. Робот может напомнить о контрольной дате, но не определит, принята ли работа и можно ли открывать следующий этап.
В Битрикс24 канбан доступен в том числе для смарт-процессов, а стадии используются для движения карточек по процессу. Справка по канбану CRM описывает эту механику. Для обязательства подрядчика стадиями могут быть «назначено», «выполняется», «предъявлено к приёмке», «принято» и «заблокировано». Названия здесь вторичны. Важны событие перехода и сотрудник, который отвечает за достоверность записи.
Сначала проверьте одну цепочку передачи, затем настраивайте роботов
Не начинайте с большой схемы на все отделы. Надёжнее взять одну цепочку: заявка, сделка, договор, запуск проекта и первое обязательство подрядчика. Пройдите её по реальному объекту. Отметьте ручные переносы, решения только в чате и места, где руководитель вынужден спрашивать статус у конкретного человека. Это кандидаты на изменение процесса или настройку CRM.
Порядок работы может быть таким:
- Соберите все источники заявок и назначьте владельца первого ответа.
- На одном договоре назовите момент, когда продажа передаёт ответственность руководителю проекта.
- Опишите несколько контрольных событий проекта, а не весь производственный план.
- Для каждого обязательства подрядчика определите исполнителя, срок, подтверждение результата и причину блокировки.
- Решите, какие данные остаются в сметной, учётной или проектной системе, а в CRM передаются только ссылкой или контрольным статусом.
- Запустите прототип на нескольких реальных записях и сравните карточки с тем, что происходит на объектах.
После этого появляются основания для автоматизации. Например, создание проекта из успешной сделки может назначать задачу руководителю проекта; запись о блокировке может требовать указать причину; контрольная дата может создавать напоминание ответственному. Автоматизация полезна, когда она поддерживает уже принятый порядок. Если порядок не согласован, робот лишь быстрее разошлёт хаос.
Когда с CRM лучше подождать
Если один руководитель ведёт несколько небольших объектов, подрядчиков мало, а сроки помещаются в общем плане без ручных копий, начните с таблицы и правила, кто вносит изменения. Смарт-процессы здесь добавят работу.
Пауза нужна и когда команда не может назвать момент передачи договора руководителю проекта. Обсудите один объект: кто передал договор, что получил новый ответственный и где информация потерялась. CRM оправдана, когда несколько людей работают с одними объектами, а руководитель уже не видит картину без звонков и переписки.
Чек-лист перед настройкой CRM для строительства
Проверьте этот список на одном настоящем объекте, а не на идеальной схеме. Неопределённый пункт сегодня станет сообщением «уточните статус» после запуска.
- Перечислены все каналы, из которых приходят заявки, и назначен ответственный за первый контакт.
- Определено событие, после которого сделка становится проектом.
- Для каждой контрольной стадии проекта есть владелец и событие перехода дальше.
- Отдельно зафиксировано, что считается риском по сроку и кто сообщает об этом менеджеру или заказчику.
- В обязательстве подрядчика указаны проект, вид работ, ответственный, дата контроля и способ подтверждения результата.
- У каждой важной даты есть один источник: CRM, календарный план, сметная или учётная система.
- Руководитель знает, на какой вопрос отвечает отчёт: где проекты остановились, какие обязательства просрочены или какое обещание клиенту требует пересмотра.
Если на большую часть пунктов есть точный ответ, можно собирать рабочий прототип. Расширять его стоит только после того, как команда провела по схеме реальные заявки и проекты. Это менее эффектно, чем большая презентация со всеми отделами, зато быстрее показывает дублирование и спорные статусы.
Короткие ответы на частые вопросы
01Можно вести весь проект в одной сделке?
Можно, когда после продажи объект ведёт один человек и передач мало. Если подключаются руководитель проекта, прораб и подрядчики, сделка смешивает коммерческие условия с исполнением. Связанный проект разделяет эти задачи и сохраняет историю заказчика.
02Нужен ли отдельный смарт-процесс для подрядчиков?
Постоянная карточка нужна для повторяющихся сведений о контрагенте и работы с ним на нескольких объектах. Для контроля важнее запись обязательства: в ней видны объект, срок и результат. Если подрядчиков немного, сначала проверьте схему на таблице или задачах.
03Что должно оставаться вне CRM?
Вне CRM оставляют данные, которые уже корректно живут в профильной системе и не нужны для передачи ответственности. Обычно это детальные сметы, техническая документация, производственные операции и бухгалтерский учёт. В CRM достаточно ссылки на актуальный документ и статуса для действия менеджера или руководителя.
04Можно ли автоматизировать проект сразу после подписания договора?
Можно, если договор уже содержит данные для передачи: объект, состав работ верхнего уровня, ответственного и контрольные даты. Когда менеджер каждый раз дописывает их вручную, сначала определите обязательный состав передачи. Иначе карточка проекта останется пустой формальностью.
05Как проверить, что этапы выбраны правильно?
Проведите по ним несколько реальных объектов и попросите руководителя проекта ответить на три вопроса без звонков: что задержано, кто отвечает и влияет ли это на заказчика. Если ответ требует открывать разные чаты и таблицы, этапов или связей пока недостаточно. Если карточка содержит поля, которыми никто не пользуется, их лучше убрать.
CRM для строительства нужна не ради единого окна. Её задача практичнее: сделать видимыми передачу обязательств, риск по сроку и следующий ответственный шаг. Начинайте с одного маршрута, где руководитель уже теряет время на поиск статуса, и не переносите в систему работу, которой она не должна владеть.
Неясно, где именно у вас рвётся путь от заявки до объекта? На разборе процесса можно проследить один договор: от первого обращения до передачи работ подрядчику, отметить ручные переносы между чатами и таблицами и определить минимальную схему CRM для проверки на реальных проектах.
