Интеграция CRM застройщика с 1С, платежами и площадками объявлений

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

С ростом продаж ручная сверка начинает стоить денег:

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

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

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

Дальше рисуем карту потоков: что, куда, в каком направлении и как часто передаётся. Для каждого потока определяем правила на случай конфликтов — например, что делать, если квартиру одновременно бронируют на сайте и в офисе продаж.

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

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

Классифайды недвижимости — ЦИАН, Авито Недвижимость, Яндекс Недвижимость, Домклик и другие — принимают объекты в виде XML-фидов. У каждой площадки свой формат, обязательные поля и правила для фото и планировок, поэтому один «универсальный» файл обычно работает плохо.

Мы генерируем фиды из единого источника данных о квартирах: проданные лоты снимаются с публикации автоматически, новые цены попадают на площадки по расписанию, ошибки валидации видны в мониторинге. Звонки и заявки с площадок через колл-трекинг и формы попадают в CRM с указанием источника, чтобы маркетинг видел, какие площадки окупаются.

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

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

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

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

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

Внешние системы иногда недоступны, а API меняются. Хорошая интеграция переживает это без потери данных:

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

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

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

• Владелец данных со стороны девелопера решает, какая система главная для квартир, цен, сделок и платежей, и принимает результат.
• Администратор CRM настраивает поля, статусы и права, чтобы интеграция могла читать и писать нужные данные.
• 1С-специалист дорабатывает обмен на стороне учётной системы по нашей спецификации.
• Маркетинг согласует метки источников и правила отображения объектов на площадках.
• Наша команда проектирует потоки, разрабатывает сервис интеграций, тестирует обмен, запускает его и сопровождает.

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

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

• Один проект. CRM, сайт и площадки объявлений: шахматка и цены из CRM, фиды на площадки, заявки с сайта в CRM с источником. Этого достаточно, чтобы убрать большую часть ручной работы.
• Несколько проектов. К схеме добавляются 1С с договорами и платежами и личный кабинет покупателя. Появляется сервис интеграций, через который проходят все потоки, и сверка поступлений между CRM и 1С.
• Группа компаний. Несколько юрлиц, брендов и иногда несколько CRM, своя управляющая компания и программа лояльности. Здесь важны единые справочники, общая учётная запись клиента и мониторинг каждого потока.

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