Проектування воронок продажів у CRM Бітрікс24
Проектування воронок продажів у CRM Бітрікс24
Воронка, налаштована «за замовчуванням», — це майже завжди воронка з проблемами. Стадії називаються «Нова», «В роботі», «Закрита успішно», менеджери не розуміють різниці між «В роботі» і «Переговори», а керівник не може отримати з CRM відповіді на питання «де зависли гроші». Проектування воронки — це не про красиві назви стадій. Це про модель прийняття рішень у продажах, перенесену в інтерфейс.
Архітектура воронок у Бітрікс24
У Бітрікс24 воронки реалізовані через STAGE_SEMANTIC_ID — семантичне значення стадії: P (in progress), S (success), F (fail). Кожна стадія належить до однієї з трьох категорій. Стадії зберігаються в таблиці b_crm_status, прив'язані до типу сутності через ENTITY_ID (наприклад, DEAL_STAGE для угод, STATUS для лідів).
У багатоворонковій моделі (з версії Бітрікс24, що підтримує напрямки) кожен напрямок (crm_category) має власний набір стадій. Технічно це реалізовано через окремі ENTITY_ID вигляду DEAL_STAGE_1, DEAL_STAGE_2 тощо, де число — ID напрямку.
Чому воронку потрібно проектувати, а не «просто створити»
Воронка — це операційна інструкція для менеджера, виражена в стадіях. Якщо стадія не відповідає на питання «що повинно відбутися, щоб угода перейшла сюди?» — це не стадія, це просто назва. Хороша воронка будується навколо вимірних критеріїв переходу.
Крім того, стадії воронки безпосередньо впливають на:
- Тригери й автоматизацію — дії виконуються при вході/виході зі стадії.
- Бізнес-процеси — запускаються при зміні стадії.
- Звіти та аналітику — конверсія між стадіями рахується саме за моделлю воронки.
- Права доступу — можна обмежити, хто має право переводити угоду в певну стадію.
Якщо воронку «намалювали швидко» і потім переробляли — всі накопичені дані по конверсії стадій обнуляються. Це болісно для відділу продажів, який уже місяць працював із CRM.
Процес проектування
Інтерв'ю з продажами. Починаємо з розмови з керівником відділу продажів і 2–3 менеджерами. Завдання — відтворити реальний процес продажу: з моменту першого контакту до оплати та повторної покупки. Важливо зафіксувати: де приймається рішення про продовження роботи з угодою, хто приймає це рішення, що є доказом переходу на наступний крок.
Визначення типів угод. Якщо компанія продає різні продукти або працює з різними сегментами клієнтів — воронки будуть різними. Процес продажу послуги підтримки та продаж разової поставки — це різні воронки, навіть в одній CRM.
Карта стадій. Для кожної стадії фіксуємо:
- Назву і зміст (що значить «бути в цій стадії»)
- Критерій входу (що повинно відбутися)
- Відповідальний (або роль)
- Максимальний час у стадії до ескалації
- Можливі переходи (в які наступні стадії можна перейти)
Стадії відмови. Окрема історія — «програшні» стадії. Їх потрібно проектувати як класифікатор причин відмови: «Відмова — немає бюджету», «Відмова — пішли до конкурента», «Відмова — не наш клієнт». Це не косметика — це дані для аналізу втрат.
Кейс: воронка для B2B-продажів програмного забезпечення
Клієнт — дистриб'ютор ПЗ, 12 менеджерів. Початкова воронка: 5 стадій, однакова для всіх типів продажів. Проблема: угоди на «прямі продажі» та угоди на «тендерні закупівлі» мають принципово різні строки та процеси, але змішані в одній воронці. Прогнозувати виручку неможливо.
Рішення: спроектували три воронки.
Воронка 1 — Прямі продажі (7 стадій, цикл 14–30 днів): Лід кваліфікований → Виявлення потреби → КП надіслано → КП погоджено → Рахунок виставлено → Оплата отримана → Ліцензія передана
Воронка 2 — Тендерні закупівлі (9 стадій, цикл 30–120 днів): Тендер виявлено → Прийнято рішення брати участь → Документація підготовлена → Заявку подано → Очікування результатів → Перемога → Договір підписано → Постачання → Закрито
Воронка 3 — Продовження ліцензій (4 стадії, цикл до 30 днів): Сповіщення надіслано → В роботі → Рахунок виставлено → Продовжено
Кожній воронці призначені окремі автоматизації: нагадування, сповіщення керівникові при перевищенні часу в стадії, автоматичне створення завдань при переході на стадію «Рахунок виставлено».
Через два місяці після впровадження клієнт отримав перші прогнози виручки з точністю ±15% — проти попереднього «приблизно стільки ж, як минулого місяця».
Автоматизація стадій
Автоматизація в Бітрікс24 налаштовується через роботів (b_crm_automation_trigger, b_crm_automation_action) — це спрощений варіант бізнес-процесів. Кожен робот прив'язаний до конкретної стадії конкретної воронки. При проектуванні важливо зафіксувати: які роботи працюють на вході в стадію, які — при затримці, які — на виході.
Терміни
Проектування однієї воронки (до 10 стадій) із налаштуванням у Бітрікс24 — 3–5 днів. Багатоворонкова модель для кількох типів продажів — 8–15 днів з урахуванням інтерв'ю, погодження, реалізації та навчання команди.