CRM для застройщика: бронирование квартир и ДДУ

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

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

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

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

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

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

Каналы стоит выбирать по тому, где клиент реально читает: звонок — для важных решений, мессенджер — для статусов и документов, почта — для официальных писем. Голосовой AI закрывает типовые входящие вроде «какие квартиры есть в такой-то площади» и «на какой стадии моя заявка», а сложный разговор передаёт менеджеру вместе с историей, чтобы человек не начинал с нуля. Человек при этом остаётся в контуре: бронь, цену и условия договора подтверждает сотрудник, а не робот.

Тот же принцип работает после сдачи дома. Гарантийные обращения, замечания по отделке и передача дел управляющей компании — отдельный поток, который удобно вести в той же системе. У застройщика с несколькими очередями репутация следующего корпуса складывается ровно из того, как закрыли замечания по предыдущему.

Шахматка — это визуальная сетка квартир по корпусам и этажам, где видно, что свободно, что в резерве, а что продано. Технически она может жить в двух местах: на сайте для покупателя и внутри CRM для отдела продаж. Двойные брони появляются ровно тогда, когда это две независимые базы, которые синхронизируются раз в сутки.

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

Отдельно стоит развести внутренние и публичные статусы. Покупателю на сайте достаточно трёх состояний: свободна, забронирована, продана. Внутренние оттенки — «бронь до вечера», «ждём одобрение», «отложено по просьбе руководителя» — наружу не показываются: они путают клиента и лишний раз рассказывают конкурентам, что происходит с продажами.

Механика брони ресурса с таймером и автоматической сменой статусов — не экзотика и не пишется с нуля каждый раз. В нашем кейсе цифровизации сети из 5 банных комплексов такая шахматка собрана внутренним приложением на коробочном Битрикс24: администратор видит занятость в сетке и ставит брони прямо там, а рядом работают портал сотрудника с ролями, POS-касса через REST-интерфейс Bitrix24 и выпуск сертификатов и абонементов. Оговоримся честно: это сфера услуг, а не застройка, и за отраслевой опыт работы с девелоперами мы его не выдаём — аналогия здесь технологическая. Но задача технически та же: один ресурс, несколько желающих, срок резерва и единый источник правды. У застройщика меняются сущности и правила, а не принцип.

Общее правило «у ресурса один владелец статуса» работает и за пределами недвижимости: в статье про онлайн-запись клиентов через виджет, бота или CRM мы разбирали тот же корень двойных броней — две независимые базы вместо одной. У застройщика цена такой ошибки просто выше, потому что речь не о часе в расписании, а о конкретной квартире, которую покупатель уже считает своей.

Агентский канал даёт застройщику объём, но он же приносит самые неприятные конфликты: два агентства приводят одного и того же покупателя, клиент сначала пришёл сам, а потом «через агента», комиссия считается по памяти. Решается это не характером руководителя отдела продаж, а правилами, зашитыми в систему.

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

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

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

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

Здесь важно не перепутать роли: CRM не заменяет юриста и не принимает решений за банк. Долевое строительство и расчёты через эскроу-счета в России регулируются законом о долевом строительстве, и конкретные требования — к форме договора, регистрации, порядку раскрытия счетов — нужно сверять с действующей редакцией закона и вашим юристом, а не с настройками системы.

Что при этом разумно закладывать в CRM: хранение версий договора и дат подписания, статус регистрации, связь каждого платежа с конкретным договором и лотом, журнал изменений по сделке. Это не юридическая гарантия, а порядок. Когда через полгода возникает вопрос, какая версия договора подписана и когда пришли деньги, ответ находится в системе за минуту, а не в переписке трёх сотрудников.

Второй пласт — персональные данные покупателей. Их у застройщика много, и они чувствительные: паспорта, справки о доходах, сведения о составе семьи. Базовые вещи закладываются в архитектуру с самого начала, а не после первой проверки: хранение данных на серверах в России, разграничение доступа по ролям, фиксация согласий, ограниченный срок хранения сканов и журнал доступа. Кто из сотрудников и внешних агентов что видит — решается правами в системе, а не доверием.

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

Второй шаг — честно посмотреть, где сейчас лежит правда о статусе квартиры. Частый случай: Битрикс24 или другая система у застройщика стоит год-два, но настроена «как получилось» — одна общая воронка на все комплексы, номера квартир в комментариях к сделке, сайт живёт отдельно, а реальный учёт брони ведётся в таблице, которую по вечерам сводит руководитель отдела. Формально CRM есть, фактически источник правды — файл.

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

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

DigitalOffice24 внедряет CRM и достраивает недостающие модули заказной разработкой одним контуром, без сборки команды из трёх подрядчиков. Что нужно именно вам, объём работ и стоимость мы называем после бесплатного экспресс-аудита на 30 минут — включая честный ответ, если часть задач решается настройкой уже купленной системы и разработка не нужна.