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