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