Сервисы сквозной аналитики: как застройщику выбрать

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

Зачем застройщику сервис и чего он не покажет

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

Но у стандартной сквозной аналитики есть слепое пятно: она видит клики и не видит показы. Если человек увидел баннер, не кликнул, а через неделю набрал название комплекса в поиске, сквозная аналитика отдаст сделку поиску. Чтобы учесть такие касания, нужен post-view — учёт показов рекламы, после которых человек пришёл другим путём. По исследованию Digital Developer, реклама участвовала в 65,4% сделок, а при настроенном post-view — в 81,2%. Разница — вклад, который без post-view остаётся невидимым.

Для застройщика с большой долей агентских сделок это особенно важно. Без post-view он отдаёт заслугу последнему касанию — агенту — и недооценивает вклад своей рекламы в брокерские сделки. А значит, рискует урезать охват, который эти сделки и создаёт.

Сначала CRM, потом сервис

Сначала порядок в CRM, потом сервис. Ни один сервис не исправит то, что менеджеры не ведут в CRM. Если у обращения нет источника, если статусы трактуются по-разному, если встречи не отмечаются, сервис просто красиво визуализирует хаос.

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

Эффект от такого порядка хорошо виден в опубликованном кейсе одного застройщика: после того как навели порядок в CRM — ввели критерии качественного обращения, разделили встречи и проставили источники у каждого обращения, — достоверность данных выросла до 99%. Связать с источником удалось 93% обращений и 90% сделок. Сервис при этом не меняли: изменились данные, которые в него попадали.

Типы решений: готовая платформа, сборка, BI

Решения можно разделить на три типа.

Готовая платформа. Один сервис закрывает весь контур: коллтрекинг, сбор данных из кабинетов, интеграцию с CRM и отчёты. Быстрее внедряется, проще в поддержке, но вы зависите от того, что умеет платформа.

Сборка из отдельных инструментов. Коллтрекинг от одного поставщика, сбор данных от другого, отчёты в BI-системе. Гибче, но требует больше времени, ресурсов и людей, которые понимают, как всё это связано.

Собственная разработка. Хранилище данных и отчёты, написанные под компанию. Максимум гибкости и максимум рисков.

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

У застройщика жилой недвижимости мы начинали с Power BI и myBI Connect, затем перешли на UIS и Smartis, где подключали и post-view. В ЖК бизнес-класса работали с UIS. В коммерческой недвижимости была связка CRM, Qlik Sense и Calltouch, и данные из CRM шли в обе системы параллельно. Моя роль во всех случаях — организация внедрения, а не разработка BI.

Критерии выбора под модель продаж

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

Первый критерий — готовая интеграция с вашей CRM без разработки. У застройщиков часто отраслевые CRM, и если у сервиса нет с ними готовой интеграции, внедрение превращается в проект по разработке со всеми его рисками.

Второй — учёт агентских сделок и post-view, если агенты дают заметную долю продаж. Третий — коллтрекинг и учёт офлайн-каналов: наружной рекламы, офиса продаж, мероприятий. Четвёртый — как работает с длинным циклом: умеет ли сервис строить когорты по месяцу первого обращения, а не только отчёты «расходы месяца — сделки месяца». И пятый — где хранятся данные и устроит ли это службу безопасности.

Внедрение: этапы и где застревают

Внедрение удобно разбить на пять этапов. Аудит: какие каналы, где теряются заявки при передаче, работает ли телефония отдельно от CRM, сохраняются ли UTM-метки. Подключение аналитики и телефонии. Настройка целей и сквозной передачи UTM до CRM. Интеграция с CRM. Дашборды и регулярный контроль.

Служба безопасности и ИТ — часть проекта с первого дня. Внедрения чаще всего застревают на доступе к данным CRM, а не на технике. Если подключить их только на этапе интеграции, проект встанет на недели или месяцы, пока идут согласования.

В опубликованном кейсе другого застройщика это решили так: чтобы пройти службу безопасности, выбрали коробочное решение с хранением данных на серверах застройщика. ИТ не дал прямого доступа к CRM, поэтому сделали промежуточную базу, через которую данные передавались в аналитику. В итоге долю сделок, которые удалось связать с источником, подняли на 20%. Такие решения находятся, но только если ИТ и безопасность участвуют с самого начала.

Как не дать аналитике умереть

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

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

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

Чек-лист выбора сервиса

Чек-лист ниже стоит пройти до покупки — сначала самим, потом вместе с поставщиком.

И мини-таблица — какой тип решения когда подходит:

Если на вопросы блока «Готовность CRM» ответ «нет», выбор сервиса стоит отложить: сначала порядок в данных, потом инструмент.