Коротко: у Business Central є вбудований механізм можливостей із етапами, ймовірністю й прогнозом. Для B2B-компанії з довгим циклом і невеликою кількістю угод його зазвичай достатньо. Проблема майже завжди не в функціях, а в тому, що воронку не заповнюють.
Що є у вбудованій CRM
Base-функціонал працює на трьох сутностях, і їх варто розрізняти.
Контакти — люди й компанії, зокрема ті, що ще не стали клієнтами. Контакт перетворюється на клієнта, коли справа доходить до продажу; до того він живе окремо й не засмічує довідник клієнтів.
Можливості — власне угоди. У кожної є етап, очікувана сума, дата закриття, ймовірність і відповідальний.
Взаємодії — історія контактів: дзвінки, листи, зустрічі. Прив'язуються до контакту чи можливості.
Головна перевага перед зовнішньою CRM — воронка живе в одній базі з обліком. Видно не тільки те, що продали, а й що продали цьому клієнту раніше, скільки він винен і чи не перевищено кредитний ліміт. Ширший огляд — CRM у Business Central.
Як задавати етапи
Етапи налаштовуються під ваш процес, і тут легко помилитися у двох напрямках.
Забагато етапів. Вісім-десять стадій виглядають детально й не заповнюються: менеджер не пам'ятає різниці між «уточнення потреби» і «формування рішення». На практиці працює чотири-шість.
Етапи за вашими діями замість дій клієнта. «Надіслали пропозицію» — це те, що зробили ви, і воно нічого не каже про ймовірність. «Клієнт погодив бюджет» — подія на його боці, і вона реально змінює шанси.
Робочий набір для B2B зазвичай виглядає так: кваліфікація → потреба підтверджена → пропозиція обговорена → рішення на узгодженні → закрито. Кожен перехід має мати ознаку, за якою його видно, а не «здається, просунулися».
Ймовірність і зважений прогноз
Кожному етапу призначається ймовірність, і система рахує зважений прогноз: сума × ймовірність.
Дві речі, які варто знати. Перша: ймовірності треба брати зі своєї статистики, а не зі стандартних. Якщо у вас із етапу «пропозиція обговорена» доходить до продажу третина угод, ставте 33%, а не 60%, як у прикладі з документації.
Друга: зважений прогноз працює тільки на великій кількості угод. Якщо у вас п'ять угод у роботі, множення на ймовірність дає число, яке не настане ніколи — реальність буде або більшою, або меншою. При п'ятдесяти угодах статистика починає працювати.
Для компаній із малою кількістю великих угод корисніший не зважений прогноз, а сценарії: песимістичний, реалістичний, оптимістичний, зібрані вручну.
Що рахувати
| Показник | Про що каже |
|---|---|
| Конверсія по етапах | Де саме втрачаються угоди |
| Середній час на етапі | Де воронка стоїть |
| Угоди без руху понад N днів | Що насправді мертве |
| Середній чек по джерелах | Звідки приходять великі клієнти |
| Причини втрат | Тільки якщо їх фіксують |
Найкорисніший — третій рядок. Угоди, які висять на етапі три місяці, формально в роботі, а фактично мертві, і вони роздувають прогноз. Регулярне чищення воронки робить прогноз чеснішим швидше за будь-яке налаштування.
Останній рядок працює тільки за умови дисципліни: якщо причини втрат не фіксують, ця аналітика недоступна — і жоден AI її не відновить.
Головна проблема — не функції
Найчастіший сценарій провалу виглядає так: воронку налаштували, менеджери заповнили її в перший місяць, потім перестали. Через квартал у системі десять угод, а насправді в роботі шістдесят.
Причина зазвичай одна: заповнення воронки не приносить менеджеру нічого. Він витрачає час, а користь отримує керівник. Три речі, які це змінюють:
- Мінімум полів. Якщо для створення можливості треба заповнити дванадцять полів, її не створять. Три-чотири обов'язкові — межа.
- Користь для самого менеджера. Історія по клієнту, нагадування, швидке формування пропозиції з наявних даних. Тоді система економить його час, а не забирає.
- Прив'язка до мотивації. Якщо бонус рахується з даних системи, дані з'являються. Але тут є пастка — бонус від відвантаження вбиває дебіторку, тож рахувати варто від оплаченого.
Що дає зв'язок воронки з обліком
Головна причина вести воронку саме в Business Central, а не в окремій системі, — те, що угода бачить облікову історію клієнта.
Практично це означає чотири речі, які в зовнішній CRM потребують інтеграції. Менеджер бачить, скільки клієнт винен і чи не прострочив — до того, як пообіцяв відстрочку. Видно, що клієнт брав раніше, тож пропозиція збирається з фактичних позицій, а не з пам'яті. Ціна підтягується з прайсу саме цього клієнта, а не загального. І при закритті угоди замовлення створюється з можливості, без повторного введення.
Останній пункт недооцінюють, а він і вирішує проблему заповнення: якщо з можливості одним рухом народжується замовлення, менеджеру вигідно її створити. Якщо ні — він створить замовлення напряму, і воронка залишиться порожньою.
Коли вбудованого не вистачає
Чесний перелік ситуацій, у яких потрібна повноцінна CRM.
- Великий потік вхідних лідів із маркетингу з автоматичним розподілом і кампаніями.
- Складні багатоетапні продажі з кількома учасниками рішення на боці клієнта.
- Польові продажі з активною роботою з мобільного.
- Маркетингова автоматизація: розсилки, сегменти, скоринг.
Якщо нічого з цього немає — вбудованого модуля вистачить, і окрема CRM додасть інтеграцію та розбіжності між системами замість користі. Питання вибору розібране в матеріалі CRM чи ERP: що впроваджувати першим.
З чого почати
- Опишіть етапи так, як вони є зараз, — за подіями на боці клієнта.
- Скоротіть до чотирьох-шести.
- Визначте, що саме має статися для переходу на наступний етап.
- Задайте ймовірності зі своєї статистики за минулий рік.
- Обмежте обов'язкові поля трьома-чотирма.
- Домовтеся про правило чищення: угода без руху N днів закривається або переноситься.
- Через місяць звірте кількість угод у системі з реальністю. Це головна перевірка.
Крок 7 показує все: якщо в системі вдвічі менше угод, ніж у роботі, проблема не в налаштуванні, а в тому, що воронку не заповнюють.
Часті запитання
Чи вистачить вбудованої CRM замість окремої системи?
Для B2B-компанії з довгим циклом і невеликим потоком угод — зазвичай так. Окрема CRM потрібна при великому потоці вхідних лідів, маркетинговій автоматизації або активних польових продажах.
Скільки етапів робити?
Чотири-шість. Вісім-десять виглядають детальніше й не заповнюються: менеджер не пам'ятає різниці між сусідніми стадіями, і дані стають випадковими.
Чи можна довіряти зваженому прогнозу?
Тільки при достатній кількості угод. На п'яти угодах множення на ймовірність дає число, яке не настане ніколи. При п'ятдесяти статистика починає працювати.
Що робити, якщо менеджери не заповнюють воронку?
Скоротити обов'язкові поля до трьох-чотирьох і зробити так, щоб система економила час самого менеджера — історія по клієнту, швидке формування пропозиції. Примус без користі не працює довше за місяць.
Чи покаже система причини втрат угод?
Тільки якщо їх фіксують при закритті. Це поле, яке треба зробити обов'язковим саме на етапі втрати — інакше аналітики причин не буде взагалі.