Проєктування мультиворонок CRM Бітрікс24

Проєктування мультиворонок CRM Бітрікс24

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

Мультиворонки в Бітрікс24 — це архітектурне рішення, а не просто «ще одна вкладка».

Архітектура мультиворонок

У Бітрікс24 мультиворонки реалізовані через механізм напрямків (crm_category). Кожен напрямок — окремий просторово ізольований набір стадій. Технічно:

• Напрямки зберігаються в таблиці b_crm_category
• Стадії кожного напрямку — в b_crm_status з ENTITY_ID = DEAL_STAGE_{categoryId}
• Угода належить конкретному напрямку через поле CATEGORY_ID у b_crm_deal

Важливі обмеження платформи:

• Перемістити угоду з одного напрямку в інший можна лише через API (crm.deal.update зі зміною CATEGORY_ID) або спеціальний інтерфейс — звичайним перетягуванням не можна.
• Призначені користувачем поля створюються для всієї сутності «Угода», а не для конкретного напрямку. Приховати поле лише для одного напрямку через стандартний інтерфейс не можна — лише через рольову конфігурацію картки.
• Автоматизація (роботи) налаштовується окремо для кожного напрямку.

Коли потрібні мультиворонки

Мультиворонки виправдані, якщо:

1. Різні команди менеджерів працюють з різними типами клієнтів — кожній команді потрібна своя аналітика.
2. Різні цикли продажів — короткострокові угоди (1–3 дні) і довгострокові проєкти (3–12 місяців) не повинні змішуватися в одному звіті.
3. Різні набори обов'язкових полів — у одного типу угод потрібні реквізити і договір, у іншого лише ім'я і сума.
4. Різні джерела лідів з несумісною логікою кваліфікації.

Мультиворонки не потрібні, якщо відмінність між типами угод покривається кастомним полем «Тип» і невеликою варіацією в стадіях.

Проєктування: від бізнес-процесів до архітектури

Крок 1. Інвентаризація типів продажів. Разом з керівництвом фіксуємо всі типи угод компанії. Для кожного типу: хто веде, який цикл, чим принципово відрізняється від інших.

Крок 2. Критерії розділення. Не кожна відмінність вимагає окремої воронки. Ставимо питання: якщо змішати ці типи угод в одній воронці, що саме зламається? Якщо відповідь — лише візуальна незручність, достатньо поля-фільтра. Якщо відповідь — стадії принципово різні і автоматизація різна — потрібна окрема воронка.

Крок 3. Архітектура переходу між воронками. Нерідко бізнес-процес передбачає перехід угоди з однієї воронки в іншу: кваліфікований лід → стандартна угода → сервісний контракт після закриття. Це потрібно спроєктувати явно: через автоматизацію (crm.deal.add в іншому напрямку при закритті поточної угоди) або через ручне перенесення з задокументованим процесом.

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

Крок 5. Окрема автоматизація. Роботи і тригери налаштовуються для кожного напрямку окремо. Це дозволяє мати різні сценарії сповіщень і завдань для різних воронок — саме це і є архітектурним змістом розділення.

Кейс: три воронки для компанії-дистриб'ютора

Клієнт — оптовий дистриб'ютор побутової хімії. Три канали продажів: роздрібні мережі (контракти на постачання), HoReCa (готелі, ресторани), інтернет-магазини (агрегатори).

Початкова ситуація: одна воронка «Угоди» з 6 стадіями. Керівник не міг зрозуміти, чому конверсія «нормальна», але виторг не зростає: контракти з роздрібними мережами (довгий цикл, великий чек) змішувалися зі швидкими угодами HoReCa (цикл 3–7 днів, середній чек у 10 разів менший).

Воронка «Роздрібні мережі» (8 стадій, цикл 30–90 днів): Переговори → Матрицю погоджено → Комерційні умови → Договір на погодженні → Договір підписано → Перше постачання → Регулярні постачання → Розірвання

Воронка «HoReCa» (5 стадій, цикл 3–14 днів): Звернення → КП надіслано → Тестове постачання → Регулярне замовлення → Втрата клієнта

Воронка «Маркетплейси» (6 стадій): Звернення → Анкету заповнено → Документи передано → Лістинг створено → Перші замовлення → Активний партнер

Для воронки «Роздрібні мережі» налаштували автоматичне створення завдання «Погодити ціни з комерційним директором» на стадії «Комерційні умови». Для воронки «HoReCa» — нагадування менеджеру через 2 дні після надсилання КП без відповіді.

Після впровадження керівник вперше побачив роздільну конверсію за каналами: роздрібні мережі — 18% з переговорів у контракт, HoReCa — 42%. Стало зрозуміло, куди спрямовувати зусилля.

Типові помилки при проєктуванні

Занадто багато воронок. Більше 6–8 напрямків — вже складно керувати. Якщо воронок багато, частину з них варто розглянути як смарт-процеси.

Воронки без власників. Кожен напрямок повинен мати відповідального керівника, який стежить за актуальністю стадій і автоматизації.

Забули про звітність. Стандартні звіти Бітрікс24 вміють агрегувати дані за кількома напрямками, але нестандартні зрізи потребуватимуть кастомних звітів через crm.deal.list або BI-інструменти.

Терміни

Проєктування мультиворонкової архітектури (2–3 напрямки) — 8–15 робочих днів: інтерв'ю, архітектурна схема, погодження, реалізація кожного напрямку, автоматизація, тестування і навчання команд.