Коли каталог житлового комплексу на сайті, CRM менеджерів і таблиці відділу продажу показують різні дані, втрачаються не лише ліди. Покупець бачить вільну квартиру, менеджер повідомляє про бронювання, маркетинг продовжує вести рекламу на вже недоступний лот. Синхронізація квартир сайту і CRM усуває цю проблему лише тоді, коли команда заздалегідь визначає джерело правди, правила статусів і відповідальних за винятки.
Для девелопера сайт має бути зрозумілим інструментом вибору, а CRM — операційною системою продажів. Технічно синхронізація каталогу квартир може передавати дані через API, вебхуки або проміжний інтеграційний шар. Однак результат визначає не сам спосіб обміну, а узгоджена модель даних і процес роботи менеджерів із бронюваннями.
Почніть із єдиного джерела правди
Для кожного поля потрібно прямо зафіксувати, яка система має остаточне право його змінювати. У більшості проєктів CRM є джерелом правди для комерційного стану лота: доступності, бронювання, ціни, відповідального менеджера та етапу угоди. Сайт отримує ці відомості для вітрини. Водночас характеристики будинку, секції, поверху, площі, планування та медіаматеріали часто ведуться в CMS або спеціалізованому каталозі.
Не варто будувати двосторонній обмін усіма полями «про всяк випадок». Він створює конфлікти: редактор сайту змінює площу, менеджер коригує лот у CRM, а система не розуміє, яка версія правильна. Надійніша модель — одностороння публікація комерційних статусів із CRM на сайт і окремо контрольовані сценарії для заявок та бронювань із сайту в CRM.
Мінімальна картка лота для обміну
- Незмінний ID квартири — ключ, який не залежить від назви, номера поверху чи маркетингової назви планування.
- Ідентифікатори структури — проєкт, будинок, секція, поверх, черга.
- Комерційний статус та час його останньої зміни.
- Площа, кількість кімнат, ціна або правило її відображення — якщо ці дані публікуються.
- Ознака публічності — чи може лот бути видимим у каталозі.
- Версія запису або час оновлення — потрібні для виявлення застарілих повідомлень.
На сайті ЖК важливо відобразити цю логіку і в інтерфейсі: актуальна доступність на сайті має залежати від даних лота, а не від ручного перемальовування шахматки чи планування.
Створіть словник статусів, який розуміють продажі й покупці
Статуси квартир у CRM рідко можна без змін вивести на сайт. Внутрішні етапи на кшталт «документи на перевірці» або «очікуємо платіж» можуть бути необхідні менеджеру, але лише заплутають покупця. Потрібна таблиця відповідності між операційним і публічним статусом.
| Статус у CRM | Що бачить покупець | Дія системи |
|---|---|---|
| Вільна | «У продажу» | Лот доступний у фільтрах і приймає заявку. |
| Тимчасове бронювання | «Заброньовано» або «Уточнюйте» | Прибрати з основної видачі або залишити без можливості бронювання — за політикою девелопера. |
| Резерв / очікування оплати | «Недоступна» | Приховати цільову дію, але за потреби запропонувати альтернативи. |
| Продана / договір укладено | Не показувати або «Продано» | Виключити з рекламних вибірок і форм бронювання. |
| Технічне блокування | «Уточнюйте у відділі продажу» | Не називати лот вільним, створити задачу відповідальному менеджеру. |
Окремо погодьте значення «в наявності», «резерв», «бронь», «продано» та «приховано». Не замінюйте їх одним полем true/false: воно не пояснює причин недоступності й не дозволяє коректно налаштувати інтерфейс, рекламу та звітність.
Бронювання: найризикованіший момент процесу
Клік на кнопці «Забронювати» не дорівнює юридичному чи комерційному бронюванню. Якщо сайт приймає заявку, а CRM підтверджує наявність пізніше, покупцеві не можна обіцяти фіксацію лота. Безпечний сценарій: сайт створює лід із ID квартири, CRM перевіряє поточний статус і призначає менеджера; тільки після підтвердження менеджером або автоматичної перевірки бронювання стає чинним.
Що визначити до запуску
- Хто має право встановлювати бронювання: менеджер, керівник групи, автоматичне правило чи лише back office.
- Який строк дії тимчасового резерву та хто його продовжує.
- Що відбувається після спливу строку: автоматичне повернення у продаж чи перевірка відповідальним.
- Чи допускаються паралельні заявки на один лот і як пріоритезується контакт.
- Яке повідомлення отримує покупець, якщо квартира вже змінила статус.
Не показуйте «квартиру заброньовано для вас», доки CRM або інша уповноважена система не зафіксувала резерв і не повернула підтвердження.
Напрямки оновлення та захист від конфліктів
Оновлення каталогу нерухомості має працювати подієво для критичних змін: зміна статусу, створення бронювання, скасування резерву, корекція ціни. Періодичне звіряння за розкладом потрібне як страховка — воно знаходить записи, які не оновилися через збій вебхука, тимчасову недоступність API або помилку в даних.
Для кожної події передавайте ID лота, новий стан, час зміни, ID події та версію запису. Приймальна система має бути ідемпотентною: повторне надходження одного повідомлення не повинно створювати дублікати чи скасовувати новіший статус. Якщо подія надійшла із застарілою версією, її слід відхилити й записати в журнал.
Правила для конфліктних ситуацій
- Новіший запис перемагає лише тоді, коли обидві системи мають синхронізований час і визначеного власника поля.
- Для критичних статусів пріоритет має CRM, якщо саме там ведеться продаж.
- Ручна зміна на сайті не повинна непомітно перезаписувати дані CRM; вона або блокується, або створює контрольований запит на зміну.
- Якщо відповідь CRM недоступна, сайт не має позначати лот як гарантовано доступний.
Кешування і безпечні стани для покупця
Кеш прискорює каталог, але може показувати застарілий стан. Для статусів використовуйте короткий час життя кешу, адресне очищення після події та перевірку «свіжості» перед критичною дією. Необхідно відрізняти швидкість від достовірності: планування може кешуватися довше, ніж доступність конкретної квартири.
Продумайте fallback-стани. Якщо дані лота не оновлювалися довше допустимого для вашого процесу періоду або CRM тимчасово не відповідає, показуйте «Наявність уточнюйте у відділі продажу» і залишайте форму запиту. Не показуйте нульову ціну, випадковий старий статус або технічну помилку. Для маркетингу це краще, ніж втратити довіру через помилкову обіцянку.
Моніторинг, ручні правки та аудит
Інтеграцію не можна вважати завершеною після першої успішної передачі. Потрібен операційний контроль: черга помилок, сповіщення про невдалі події, звіт про лоти без оновлень, щоденна або інша погоджена звірка кількості статусів. Власником інциденту має бути конкретна роль, а не абстрактна «технічна команда».
Ручний override потрібен для нештатних випадків, але він має бути обмеженим. Зберігайте причину, користувача, дату, попереднє та нове значення, а також строк дії тимчасового винятку. Після завершення строку лот повинен повернутися під стандартну синхронізацію або потрапити на перевірку. Журнал змін допомагає розібратися, чому покупець бачив один статус, а менеджер — інший.
Чекліст перед запуском
- Затвердити систему-джерело для кожного поля картки квартири.
- Узгодити словник внутрішніх і публічних статусів.
- Перевірити незмінність ID лотів після імпорту, зміни секції чи планування.
- Протестувати одночасні заявки та зміну статусу під час відкритого каталогу.
- Налаштувати повторну доставку подій, журналювання та сповіщення про помилки.
- Перевірити очищення кешу після бронювання, продажу й скасування резерву.
- Погодити fallback-повідомлення для покупця та маршрут обробки такої заявки.
- Провести звірку CRM, сайту й рекламних фідів до запуску кампаній.
Якісна синхронізація — це не просто передавання статусу «вільна» на сайт. Це керований процес, у якому покупець отримує чесну інформацію, менеджер бачить актуальну чергу роботи, а девелопер може пояснити будь-яку зміну в каталозі. Починайте з правил даних і відповідальності, а вже потім обирайте технічну реалізацію.
