Объект - это не сделка. Почему CRM в недвижимости ломается на второй сотне квартир
В агентстве недвижимости CRM обычно начинает жить как у всех: воронка, сделки, задачи. Первые месяцы всё нормально. Ломается это не сразу, а примерно на второй сотне объектов - когда выясняется, что одну и ту же квартиру ведут три агента, у неё четыре карточки, и в двух из них цена прошлогодняя.
Причина не в системе и не в агентах. Причина в том, что обычная CRM устроена вокруг одной сущности - сделки, а в недвижимости их две, и они живут по разным законам.
Клиент приходит и уходит, объект остаётся
У клиента есть начало и конец: обратился, посмотрел, купил или передумал. Это сделка в чистом виде, у неё нормально работает воронка.
У объекта конца нет. Квартиру показывают двадцати людям, снимают с продажи, возвращают через полгода с другой ценой, продают, а через два года собственник приходит с ней снова. По объекту нельзя построить воронку - он не движется к закрытию, он просто есть.
Когда объект заводят сделкой, начинается ровно то, что описано выше. Каждый новый интерес к квартире - новая сделка, то есть новая карточка того же объекта. Через полгода найти по базе «что у нас есть в этом районе до восьми миллионов» невозможно: поиск выдаёт двенадцать карточек, из которых три актуальны, а какие именно - знает только один человек, и он в отпуске.
Правильная схема простая: объект и клиент лежат в разных базах, а сделка - это связка между ними. Один объект, много сделок по нему. Один клиент, несколько интересующих его объектов. Технически это отдельный справочник или смарт-процесс, в котором объект заводится один раз и живёт всегда.
Что должно быть в карточке объекта, кроме адреса
Главное поле - не цена и не площадь, а дата последней проверки актуальности. Кто и когда в последний раз подтвердил, что объект действительно продаётся на этих условиях.
Поле выглядит бюрократией ровно до первого случая, когда агент везёт клиента смотреть квартиру, проданную три недели назад. Дальше оно выглядит обязательным.
Второе - параметры, по которым вы реально подбираете. Не всё подряд, а те пять-шесть, по которым агент фильтрует базу в разговоре с клиентом: район, бюджет, комнатность, этаж, состояние, срок выхода на сделку. Эти поля должны быть списками, а не текстом. Поле «район», заполненное вручную, через год содержит и «Северный», и «северный», и «сев.», и подбор по нему не работает.
Третье - источник объекта и условия работы с ним. Эксклюзив у вас или он есть ещё в десяти агентствах. От этого зависит, стоит ли вкладывать в рекламу, и это же основная причина споров внутри команды.
Кто чей клиент: правило должно быть в системе, а не в голове
Второй вечный конфликт агентства - закрепление клиента. Человек позвонил по объявлению одного агента, потом написал в мессенджер другому, потом пришёл в офис и попал к третьему.
Решается это не переговорами, а правилом, записанным в системе и одинаковым для всех: клиент закрепляется за тем, кто первым завёл его в базу, на фиксированный срок, и срок продлевается, только если по клиенту есть зафиксированная активность. Нет звонка или показа две недели - закрепление снимается, клиент возвращается в общий пул.
Важно, что эта логика не про справедливость, а про деньги: без неё агенты либо не заводят клиентов в базу вообще, чтобы не отдать, либо тратят время на выяснение отношений. И первое хуже - когда клиенты живут в личных блокнотах, у агентства нет базы, у него есть несколько независимых частных практик под одной вывеской.
Показ - это событие, а не задача
Мелочь, которая сильно меняет отчётность. Показ обычно оформляют задачей «показать квартиру». Задачу закрыли - информации не осталось: сколько показов было у объекта, каким клиентам, что они сказали.
Если показ - отдельная запись со ссылкой на объект, на клиента и с полем «реакция», через два месяца у вас появляются ответы на вопросы, ради которых всё и затевалось. Например: объект показали пятнадцать раз и не купили - значит, дело не в трафике, а в цене или состоянии, и с собственником пора разговаривать. Или наоборот: у объекта два показа за месяц, при этом он в рекламе - значит, проблема в объявлении, а не в объекте.
Без этой записи оба вывода делаются на ощущениях, и спор с собственником квартиры о снижении цены ведётся без единого аргумента.
Чего не надо делать на старте
Не надо тащить в систему всю историческую базу. В любом агентстве накопленные таблицы объектов на девяносто процентов состоят из неактуального, и перенос превращается в перенос мусора, после которого системе перестают верить в первую же неделю.
Рабочий вариант - завести объекты, по которым есть живая работа сейчас, а остальное подтягивать по мере обращения. Через три месяца в базе окажется то, что действительно используется.
И не надо начинать с интеграций с площадками. Автоматическая выгрузка объявлений - полезная вещь, но она имеет смысл, когда карточка объекта уже заполняется одинаково всеми и в ней есть чему выгружаться. В обратном порядке вы получите автоматическую публикацию кривых данных, только быстрее.
Короткий тест для вашей базы
Откройте систему и попробуйте за минуту ответить на три вопроса.
- Сколько у вас сейчас объектов в продаже до определённой суммы в конкретном районе?
- Когда по каждому из них последний раз подтверждали актуальность?
- Кто из клиентов смотрел похожее за последний месяц и не купил?
Если на все три ответ находится за минуту - база у вас есть, и дальше можно говорить про автоматизацию. Если хотя бы на один приходится звонить коллегам - у вас не база, а хранилище карточек, и никакая новая CRM сама по себе это не изменит.
Разбираю такие базы по конкретным агентствам и показываю, как развести объекты и клиентов, в канале в MAX: https://max.ru/channel_axiomacrm