CRM для будівельної компанії: від заявки до договору

Чому «програма для будівельної компанії» зазвичай про об’єкти

Комерційний пошук веде до лендингів, де в центрі вже підписаний об’єкт: бригади, етапи, гроші, матеріали. Для компанії, яка вже працює на майданчиках, це логічно. Але біль до договору інший. Поки клієнта ще немає в роботі, ви втрачаєте не бетон і не плитку — ви втрачаєте людину між менеджером, замірником і кошторисником.

CRM для ремонту квартир і програма для підрядника часто обіцяють «усе в одному». На практиці власник дивиться гарний список функцій і пропускає єдине питання: де в системі живе заявка, поки кошторис ще не виставлено? Якщо відповіді немає — далі будуть об’єкти, а до них — діра.

Як було: заявки в месенджерах, замір і кошторис губляться між людьми

Типова картина ремонтної чи будівельної компанії середнього розміру. Заявки сипляться з сайту, Instagram, рекомендацій і вхідних дзвінків. Менеджер фіксує ім’я й телефон у нотатках або одразу пише в спільний чат: «хто вільний на замір у середу?».

Замірник виїжджає, робить фото, іноді креслить на папері, іноді скидає голосове. Кошторисник отримує це «коли встигне». Якщо замірник у відпустці або змінив телефон — частина деталей зникає. Клієнт чекає кошторис «до кінця тижня». Тиждень минає. Менеджер пише «уточню». Клієнт уже підписав у конкурента.

Власник наприкінці місяця питає: скільки було заявок, скільки замірів, скільки кошторисів, скільки договорів? Відповідь збирають із чатів і пам’яті. Цифри не сходяться. Ніхто не винний особисто — просто немає однієї картки, де видно, на якому кроці застряг кожен клієнт.

Умовні цифри, не з кейсів: за місяць прийшло 20 заявок. До заміру дійшли 12. Кошторис виставили 8 клієнтам. Договір підписали 5. Арифметика проста: до договору дійшла лише чверть заявок: 5 із 20. Без статусів власник не відрізнить «мало заявок» від «багато заявок, але діра між заміром і кошторисом».

Що має вміти CRM на етапі до договору

Нижче чекліст саме воронки продажів, а не обліку матеріалів і не синхронізації виконроба з офісом після старту робіт. З ним зручно дивитися будь-який готовий сервіс або обговорювати систему під ваш процес.

1. Одна картка клієнта

Ім’я, телефон, джерело заявки, адреса об’єкта, тип робіт, листування й файли — в одному місці. Не «у менеджера в нотатках», не «у замірника в галереї», не «у кошторисника в окремій теці». Новому співробітнику має бути видно картку без дзвінка колезі.

2. Статуси: заявка → замір → кошторис → договір

Кожен крок має явний статус. «У роботі» без уточнення — не статус. Потрібні зрозумілі переходи: заявка прийнята, замір призначено, замір зроблено, кошторис у підготовці, кошторис надіслано, переговори, договір, відмова з причиною. Тоді список клієнтів перестає бути звалищем імен.

3. Відповідальний на кожному кроці

У заявки є менеджер. У заміру — замірник і дата. У кошторису — кошторисник і строк. У договору — хто веде погодження. Якщо відповідального не призначено, система має це показувати, а не ховати порожнє поле. Естафета без імені — це майже гарантована втрата.

4. Строки відповіді клієнту

Клієнт чекає не «коли вийде», а конкретний горизонт: коли приїде замір, коли надійде кошторис, коли можна обговорити правки. У картці корисні дедлайни й сигнал, якщо строк зірвано. Не для штрафів співробітникам — для власника, який інакше дізнається про зрив від самого клієнта.

5. Звіт власнику за воронкою

Раз на тиждень або частіше власник бачить: скільки заявок, скільки призначених замірів, скільки надісланих кошторисів, скільки договорів і відмов. Умовний приклад знову на тих самих 20 → 12 → 8 → 5: якщо замірів багато, а кошторисів мало, проблема не в рекламі — вона між виїздом і документом. Якщо кошторисів багато, а договорів мало — дивіться швидкість відповіді й якість комерційної пропозиції.

Як стало: одна картка від заявки до договору

Заявка потрапляє в систему одразу — з сайту, з форми або після дзвінка одним записом менеджера. Далі в тій самій картці призначається замір: дата, адреса, хто їде. Після виїзду фото й нотатки кріпляться до картки, а не їдуть в особистий чат. Кошторисник бачить усе потрібне без «скинь ще раз».

Статус змінюється за фактом кроку. Клієнт отримує кошторис у погоджений строк — або власник бачить прострочення до дзвінка «ну як там мій кошторис?». Коли договір підписано, картка закриває воронку продажів і передає об’єкт далі в роботу.

Таку зв’язку зручно збирати через автоматизацію процесів: заявки, таблиці, статуси та звіти як одна система: вхідні заявки, статуси й короткий звіт власнику перестають жити в трьох месенджерах. Якщо поруч потрібні замовлення, склад і гроші вже на етапі робіт, дивіться також системи для виробництва, де замовлення, склад і фінансовий облік працюють разом — логіка одна: одне місце правди замість розрізнених чатів.

Готовий сервіс чи система під ваш процес

Готовий галузевий сервіс часто добре закриває базові заявки, календар замірів і шаблони кошторисів. Якщо у вас короткий цикл, мало ролей і простий прайс, такий сервіс може бути достатнім стартом. Немає сенсу будувати своє лише тому, що «власна розробка звучить солідніше».

Система під ваш процес потрібна, коли:

• заявки йдуть із кількох каналів, і без єдиної картки частина просто «губиться в повітрі»;
• в естафеті беруть участь різні ролі — менеджер, замірник, кошторисник, інколи окремий комерційний — і відповідальність стрибає;
• строки відповіді клієнту критичні: кошторис через три дні й через три тижні — це різні бізнеси;
• власнику потрібен звіт за воронкою в месенджер, а не лише екран усередині чужого кабінету;
• готовий сервіс змушує підганяти ваш процес під чужі поля вже третій місяць поспіль.

Критерій простий: якщо готовий сервіс закриває ваші реальні правила воронки без щоденних милиць в Excel і чатах — беріть його. Якщо співробітники обходять систему стороною, бо «так швидше в Telegram» — дивіться систему навколо вашого процесу, а не навпаки.

Що далі після договору: кейс BuildControl

Воронка до договору — лише вхід. Коли клієнт підписав, починається інша робота: об’єкт, бюджет, матеріали, витрати. Тут якраз корисний кейс BuildControl: облік витрат і матеріалів за об’єктами, введення з телефона, контроль бюджету.

Важливо не змішувати шари. Спочатку одна картка доведе клієнта до підписання. Потім той самий принцип «дані в момент дії» триває на об’єкті: витрата й матеріал потрапляють у систему з телефона, а не через нічне зведення чеків.

Чому власник часто дізнається про проблеми вже на об’єкті постфактум — окрема тема: виконроб і офіс не синхронізовані. Ця стаття про діру до договору; та — про діру після старту робіт. Разом вони закривають шлях від першого повідомлення клієнта до контролю на майданчику.

З чого почати, не зупиняючи продажі

1. Випишіть ланцюжок: заявка → замір → кошторис → договір. Хто відповідає на кожному кроці сьогодні — за іменами, не «усі в чаті».
2. Тиждень фіксуйте кожну нову заявку в одній таблиці: дата, джерело, статус, відповідальний, дата наступного контакту з клієнтом.
3. Окремо позначте, де найчастіше рветься ланцюг: до заміру, між заміром і кошторисом, між кошторисом і договором.
4. Порахуйте за тиждень просту воронку в абсолютних числах — без гарних часток «на око».
5. Лише після цього дивіться демо сервісів або обговорюйте систему під процес: уже буде зрозуміло, що автоматизувати першим.

Чого це не зробить

Система не замінить якість заміру й кошторису: якщо на виїзді зняли неповні розміри або в документі помилка в обсягах, картка зі статусами буде акуратною і все одно призведе до суперечки з клієнтом. Звіт за воронкою чесний лише якщо статуси оновлюють у момент кроку, а не «пачкою в п’ятницю ввечері».

З чого почати

Три робочі дні записуйте кожну нову заявку в одну таблицю з п’яти полів: дата, джерело, статус, відповідальний, дата обіцяної відповіді клієнту. Через три дні буде видно, де ланцюг рветься — ще до вибору програми.

Автоматизація процесів та інтеграції →