Какие данные движутся между сайтом и системами застройщика
В первую очередь разделите три задачи.
| Задача | Направление обмена | Что передаётся |
| Наполнение каталога | Из системы учёта на сайт | Характеристики, цены, статусы, планировки |
| Обработка обращения | С сайта в CRM | Контакт, выбранная квартира, запрос и доступный контекст источника |
| Бронирование, если оно предусмотрено | Запрос с сайта и ответ системы учёта | Проверка доступности и подтверждённое изменение статуса |
CRM и система учёта квартир могут быть одной системой или разными сервисами. Иногда каталог получает данные из отдельного модуля недвижимости, а обращения поступают в CRM отдела продаж.
Подключение формы к CRM не означает автоматического обновления квартир на сайте. Состав каждого обмена нужно описать отдельно в ТЗ на разработку сайта ЖК.
Какие сведения нужны для каталога квартир
Начните с перечня полей. Он зависит от проекта и функций сайта, но для рабочего каталога полезно предусмотреть следующие группы.
| Группа данных | Что подготовить | Для чего используется |
| Идентификаторы | Уникальный ID квартиры, ID проекта и корпуса | Сопоставление записей при обновлении и передаче заявки |
| Расположение | Очередь, корпус, секция, этаж, номер квартиры | Навигация и понимание расположения объекта |
| Тип и характеристики | Тип помещения, комнатность, площадь, отделка | Фильтры и содержание карточки |
| Стоимость | Полная цена, валюта, при необходимости цена за м² | Представление предложения и поиск по бюджету |
| Доступность | Статус продажи и признак публикации | Управление показом и допустимыми действиями |
| Планировки | Связь квартиры с планировкой, изображения и необходимые версии | Просмотр и сравнение вариантов |
| Особенности | Терраса, гардеробная, вид, другие подтверждённые параметры | Дополнительные фильтры и аргументы выбора |
| Актуальность | Время изменения в источнике и время успешной синхронизации | Контроль обновлений и поиск расхождений |
Для каждого поля определите формат, обязательность и допустимые значения. Например, площадь передаётся числом в квадратных метрах, а валюта хранится отдельно от суммы. Пустое поле цены не должно автоматически превращаться в «0 ₽».
Если планируются фильтры по особенностям квартир, эти особенности нужны в структурированном виде. Фразу «просторная кухня и гардеробная» в описании нельзя считать готовой заменой отдельным признакам каталога.
Почему номер квартиры не заменяет уникальный ID
Квартира №128 может существовать в нескольких корпусах. Публичный номер также может измениться при уточнении нумерации. Поэтому для обмена нужен устойчивый ключ записи, который сохраняет связь с объектом в исходной системе.
Этот ключ связывает карточку, цену, статус и обращение покупателя. Номер строки в таблице для этой роли не подходит: после сортировки или удаления строк он может измениться
Чем квартира отличается от типа планировки
Одна планировка может повторяться на разных этажах. Такие квартиры используют похожее изображение, но имеют собственные идентификаторы, цены и статусы.
Необходимо хранить отдельно данные конкретной квартиры и ссылку на подходящий тип планировки. Если существуют зеркальные версии или различия между секциями, привязка изображения должна учитывать их
Пример записи для одной квартиры
Ниже условный набор данных, который иллюстрирует структуру. Это пример.
| Поле | Пример значения |
| ID квартиры | DEMO-B1-128 |
| ID проекта / корпуса | DEMO / B1 |
| Публичный номер | 128 |
| Этаж | 7 |
| Комнатность | 2 комнатная |
| Площадь | 53,2 м² |
| Полная стоимость | 6 384 000 ₽ |
| Статус | Доступна |
| Публикация | Разрешена |
| Тип планировки | 2K-53-A |
В рабочем обмене числа, единицы измерения, статусы и идентификаторы записывают в согласованном формате. Таблица выше показывает смысл данных; она не является готовым форматом API конкретной системы.
1. Задача сайта и границы первой версии
Начните с конкретной ситуации: старт продаж нового ЖК, запуск очереди, продвижение отдельного ассортимента или обновление действующего сайта.
Опишите основной сценарий покупателя и ожидаемое действие. Например:
Покупатель выбирает квартиру по параметрам, открывает её карточку и оставляет запрос на условия покупки. В обращении сохраняется идентификатор выбранной квартиры.
Отдельно перечислите функции, которые должны быть готовы к запуску, и задачи следующих этапов. Если на старте достаточно подборки планировок, а полноценный каталог планируется позже, это должно быть видно из ТЗ и сметы.
Цели по обращениям после запуска учитывают вместе с трафиком, предложением и работой отдела продаж. Для приёмки разработки нужны проверяемые требования к самому сайту.
Как определить источник цен и статусов
Для каждого изменяемого параметра назначьте основной источник. Например, цены и доступность поступают из системы учёта, а описание преимуществ и дополнительные изображения редактируются на сайте
Важно заранее определить, какие поля синхронизация перезаписывает, а какие сохраняет. Иначе ручное изменение цены на сайте может исчезнуть при следующем обновлении, а описание — случайно замениться пустым значением из выгрузки.
Для стоимости полезно отдельно согласовать:
- какая цена считается основной;
- как представлены акции и условия их применения;
- показывается ли цена за квадратный метр и как она рассчитывается;
- что делать, если цена отсутствует или не прошла проверку.
Для статусов нужна таблица соответствий. Внутренние обозначения системы учёта не обязаны совпадать с текстом для покупателя.
| Смысл статуса в системе | Возможное поведение сайта |
| Доступна к продаже | Показывать в основном предложении и разрешать обращение |
| Забронирована | Обозначать бронь; дальнейшие действия согласовать с отделом продаж |
| Продана | Убирать из доступного ассортимента; поведение сохранённой карточки определить отдельно |
| Не выведена в продажу | Публиковать только по согласованному правилу |
| Неизвестный статус | Не считать автоматически доступной; передать ошибку ответственному |
Статус продажи и разрешение на публикацию лучше различать. Объект может существовать в учётной системе, но ещё не предназначаться для показа на сайте.
Как обновлять каталог
Способ зависит от возможностей систем и требований к актуальности.
Ручное обновление может подойти для небольшого ассортимента и редких изменений. Понадобятся ответственный и понятный регламент
Регулярная выгрузка позволяет передавать данные файлом или фидом — структурированным набором записей. Нужно согласовать формат и расписание.
Обмен через API позволяет системам запрашивать и передавать данные программно. Наличие API ещё не определяет частоту обновления: её задаёт интеграция с учётом возможностей и ограничений сервиса.
Уведомления об изменениях могут запускать обновление после события в источнике, если такой механизм поддерживается. Дополнительно стоит предусмотреть сверку, которая выявит пропущенные изменения.
Для любого варианта нужно определить допустимую задержку, порядок проверки результата и действия при сбое. Обещание «обновляется в реальном времени» должно опираться на проверенный механизм.
Полная выгрузка и список изменений — разные форматы
Полная выгрузка представляет весь согласованный набор объектов. Частичная содержит только изменения.
Если квартиры нет в частичной выгрузке, это не означает, что она продана или удалена. Правила удаления, скрытия и завершения загрузки необходимо описать явно. При загрузке большого каталога также нужно проверить, что обработаны все части набора данных.
Что делать, если обновление не прошло
Неудачная загрузка не должна молча превращать каталог в пустой или возвращать устаревшие статусы.
Согласуйте сохранение последней корректной версии, уведомление ответственного и предел допустимого возраста данных. После его превышения может потребоваться изменить показ цен или предложить уточнение наличия — конкретное поведение выбирают для проекта.
Для контроля полезно различать время изменения записи в источнике и время её получения сайтом. Эти отметки помогают понять, где возникла задержка.
Какие данные передавать из заявки в CRM
Менеджеру нужен контакт и контекст запроса. Рекомендуемый состав обращения:
- имя и выбранный способ связи;
- проект, корпус и ID квартиры, если она выбрана;
- тип запроса: подбор, условия покупки, встреча или другое действие;
- комментарий покупателя;
- страница и форма, из которой пришло обращение;
- дата, время и уникальный идентификатор отправки;
- доступные данные об источнике перехода, включая UTM-метки, если они присутствуют.
Для общей формы подбора выбранной квартиры может не быть. В этом случае полезно передать пожелания: комнатность, бюджет и другие параметры, которые человек действительно указал.
Отсутствующие UTM-метки не нужно выдумывать. Также заранее определите, какой источник фиксируется: входной переход текущего посещения или другая согласованная модель.
Как сопоставить поля сайта и CRM
Перед разработкой составьте карту соответствий: какое значение откуда берётся и в какое поле попадает.
| Данные с сайта | Что определить в CRM |
| Контакт покупателя | Тип записи и поля телефона, email, имени |
| ID квартиры | Поле или связь с объектом недвижимости |
| ЖК и корпус | Справочник, отдельные поля или связь с проектом |
| Запрос и комментарий | Поле описания, тип обращения или другая согласованная структура |
| Страница и источник | Поля страницы, рекламных меток и источника |
| ID отправки | Поле или служебный механизм для контроля повторной передачи |
Названия, типы и обязательность полей нужно проверять в конкретной CRM. Например, документация Битрикс24 описывает получение структуры полей отдельным методом, а при создании записи учитываются тип объекта и требования к его заполнению.
Также определите, создаётся ли лид, контакт со сделкой или запись другого типа, в какую воронку она попадает и как назначается ответственный. Наличие данных в системе ещё не означает, что нужный менеджер увидел обращение и начал работу.
Как не потерять заявку и не создать дубликаты
При проектировании полезно разделить три результата: сайт принял обращение, CRM сохранила запись, менеджер получил её в работу.
Если CRM временно недоступна, согласуйте сохранение обращения и повторную передачу. Если CRM приняла запрос, но подтверждение потерялось, повторная попытка не должна без проверки создавать ещё одну такую же запись. Для этого используют идентификатор отправки и согласованный механизм контроля повторов.
При этом новый запрос того же покупателя — не обязательно дубликат. Человек может интересоваться другой квартирой или вернуться с новой задачей. Правила объединения обращений должны сохранять этот контекст; одного совпадения телефона для решения недостаточно.
Отдельно проверяется бронирование. Нажатие кнопки и отправка формы не подтверждают резерв: система учёта должна проверить доступность и вернуть результат предусмотренного сценария.
Что передать разработчику до начала работы
Подготовьте:
- Пример выгрузки с разными корпусами, типами квартир и статусами.
- Описание полей, единиц измерения и допустимых значений.
- Правила цен, публикации, скрытия и обновления квартир.
- Планировки и таблицу их соответствия конкретным объектам.
- Список форм и карту передачи данных в CRM.
- Сведения об используемых системах, документацию обмена и контакт технического ответственного.
- Условия проверки, тестовые данные и порядок предоставления необходимых доступов.
- Ответственных за цены, ассортимент, материалы и обработку обращений.
Передавайте только необходимые для работы сведения. Для первичного согласования структуры подойдут обезличенные примеры; ключи доступа не размещают в публичных документах или коде страницы.
Как проверить интеграцию перед запуском
Проверку стоит проводить на подготовленных тестовых записях и сценариях, чтобы не менять реальные предложения и обращения покупателей.
| Сценарий | Что должно подтвердиться |
| Изменилась цена | На сайте отображается согласованное значение в установленный срок |
| Квартира стала недоступна | Каталог и карточка выполняют правило нового статуса |
| Добавлен новый объект | Создаётся одна карточка с правильными характеристиками и планировкой |
| В данных ошибка | Ответственный получает понятное сообщение; некорректные значения не публикуются по умолчанию |
| Запрос пришёл из карточки | Менеджер видит контакт, квартиру и содержание обращения |
| Запрос пришёл из общей формы | Заявка принимается без обязательного ID квартиры |
| CRM временно не отвечает | Работает согласованное сохранение и повторная передача |
| Повторяется одна отправка | Не создаётся лишняя запись в рамках принятого механизма |
| Тот же человек выбирает другую квартиру | Новый интерес сохраняется по согласованному правилу |
Результаты зафиксируйте вместе с ответственными за дальнейший контроль. После запуска проверка обмена должна стать частью обслуживания сайта.
Подробнее — об услуге разработки сайтов и лендингов для ЖК.
Частые вопросы
Можно ли начать с Excel или CSV?
Да, если данные структурированы, у объектов есть устойчивые ID и понятен порядок обновления. В таблице нужно согласовать столбцы и форматы. При дальнейшем подключении API эта структура поможет описать обмен, но сам переход потребует отдельной настройки
Нужно ли переносить весь ассортимент в CRM?
Это зависит от устройства систем. Учёт квартир может вестись в специализированном сервисе, а CRM получать обращения и ссылки на выбранные объекты. Главное — определить, где находятся достоверные данные и как сохраняется связь между ними.
Можно ли обновлять каталог без передачи заявок в CRM?
Да. Это отдельные интеграции. Но нужно заранее решить, куда поступают обращения с сайта, кто их обрабатывает и как контролируется получение.
Стоит ли заменять действующий сайт, если заявок мало?
Сначала проверьте источники трафика, предложение, мобильную версию, формы и обработку обращений. Причина может быть в конкретном этапе пути покупателя. По результатам анализа станет понятно, достаточно ли доработок, нужна ли отдельная посадочная страница или требуется новая структура.
