Воронка продажів Битрикс24: де губляться угоди
Угоди в Битрикс24 майже ніколи не губляться в одному місці — вони застрягають на межах стадій і дублюються при повторних зверненнях.
Воронка продажів Битрикс24, зібрана «за логікою відділу», зазвичай відтворює звичні етапи, але не описує, чим саме одна стадія відрізняється від іншої.
У підсумку завислі угоди виглядають як активні, а втрата угод виявляється на звірці з оплатами, коли повернути клієнта вже складно.
Перша типова причина — розмиті межі стадій угоди. Якщо перехід не прив'язаний до події, яку можна перевірити (надіслано пропозицію, отримано контакт погоджувача, підписано документ), менеджер рухає картку за відчуттям.
Звіт за етапами перестає відображати реальність: прогноз завищений, а в завислих угодах накопичуються ті, що не рухаються місяцями.
Друга — обов'язкові поля не на тому кроці. Вимога заповнити все при створенні картки змушує або заводити угоду пізніше, або ставити заглушки, які потім ніхто не чистить.
Налаштування воронки продажів працює, коли дані запитуються там, де вони з'являються: джерело й контакт — на першому дотику, умови та строки — на погодженні.
Третя — відсутність правил повернення. Без них угода після відмови клієнта залишається на просунутій стадії, а повторне звернення заводиться другою карткою, і частина завдань губиться між дублями.
Розбираємо, як це закривається налаштуванням воронки: критеріями переходу, які можна перевірити, полями на своїх кроках і сценаріями повернення угоди назад.
Що дає перезбирання: ефект у вимірюваних показниках
Перезбирання воронки в Битрикс24 змінює не «зручність інтерфейсу», а час, за який угода проходить шлях від першого звернення до рахунку. Раніше менеджер переносив картку вручну, дублював дані в таблиці та погоджував знижку в листуванні — на кожній стадії губилися години.
Після того як переходи між етапами, обов'язкові поля та відповідальних прив'язали до правил, картка рухається сама, а менеджер займається клієнтом.
Що дає автоматизація продажів у вимірюваних величинах:
- Швидкість обробки звернення — заявка з сайту, пошти й телефону потрапляє в одну картку без ручного введення, а перша відповідь перестає залежати від того, хто чергує.
- Конверсія за стадіями — видно, на якому кроці відпадає найбільше угод; частіше вузьке місце — погодження або виставлення рахунку, а не переговори.
- Частка завислих угод — правило «немає активності довше заданого строку → завдання й нагадування» повертає в роботу те, що раніше тихо лежало в базі.
- Час відновлення після збою процесу — якщо обмін із зовнішньою системою відвалився, заявки не губляться: черга дограється, а відповідальний отримує повідомлення.
Прозорість відділу продажів — наслідок того самого: керівник бачить воронку в реальному часі, а не збирає звіт за підсумками місяця з чужої таблиці. Зникає цілий клас відмов — забуті угоди, звернення без відповідального, етапи, які ніхто не контролює.
Схеми воронки: варіант, обмеження, коли підходить
Схема воронки задає не лише вигляд картки угоди, а й правила переходів, обов'язкові поля на стадії, права ролей і роботів, які рухають угоду без участі менеджера.
Тому схему обирають до наповнення бази: зміна варіанта на живих даних обнуляє зіставність етапів і ламає звітність за минулі періоди.
Різнорідність угод — головний критерій вибору. Якщо продукт один і цикл у всіх клієнтів однаковий, зайві воронки лише дроблять аналітику; якщо напрямів кілька, спільна воронка усереднює строки та конверсію до безглуздих значень.
| Схема воронки | Коли підходить | Обмеження |
|---|---|---|
| Одна спільна воронка | Один продукт, однаковий цикл угоди, єдиний відділ продажів | Різні сегменти змішуються: середній строк і конверсія рахуються «в середньому», правила переходів доводиться робити м'якими |
| Воронки за напрямами, зокрема для кількох продуктів | Різні продукти, цикли та сценарії кваліфікації | Потрібна синхронізація довідників і полів; порівняння напрямів — лише зведеними звітами, а не однією діаграмою |
| Воронка з етапами кваліфікації та повернення | Довгий цикл, угоди зависають, частина клієнтів повертається після відмови | Більше стадій — вища ціна помилки: без дисципліни заповнення й налаштувань роботів воронка заростає «мертвими» угодами |
Правила переходів фіксуємо явно: які поля обов'язкові на стадії, де заборонено перестрибування етапів, яке завдання ставить робот і через скільки днів угода йде в повернення або відмову.
Такий каркас робить воронку і робочим інструментом менеджера, і джерелом достовірних даних для прогнозу.
Етапи впровадження: від аудиту до передачі в роботу
Порядок етапів тут не формальність: кожен наступний крок спирається на результат попереднього, і пропущена ланка повертає проєкт до ручного виправлення за фактом. Нижче — послідовність, за якою ми ведемо впровадження воронки продажів у Битрикс24.
- Аудит воронки продажів. Вивантажуємо стадії, поля та історію угод, рахуємо, скільки угод зависає на кожному етапі й хто останнім змінював картку. На виході — карта проблем: дублі полів, стадії без правил переходу, звіти, які ніхто не читає.
- Проєктування стадій. Збираємо схему під реальний цикл угоди: скільки стадій потрібно, які поля обов'язкові на кожній, де дію виконує автоматика, а де рішення залишається за людиною.
- Налаштування прав доступу. Ролі під завдання: менеджер веде свої угоди, керівник бачить відділ, службові поля закриті від правок. Видалення карток і зміну стадії заднім числом обмежуємо окремо.
- Складання автоматизації. Роботи, тригери та завдання всередині стадій: нагадування при простої, завдання після погодження, повідомлення відповідального при зміні етапу.
- Перевірка на тестовому контурі. Проганяємо сценарії на копії порталу: угода проходить усі стадії, звіти сходяться, права не заважають роботі. Схему правимо до перенесення, а не після.
- Навчання та регламент. Показуємо команді нову логіку на їхніх же угодах і віддаємо короткі інструкції: яке поле коли заповнюється і що робити з нестандартною угодою.
- Передача в експлуатацію. Переносимо налаштування на робочий портал, перші тижні звіряємо звіти й знімаємо спірні місця за фактичними угодами.
Кожен етап закривається артефактом — схемою, матрицею прав або регламентом, тому результат можна прийняти частинами.
Що замовник отримує на руки після впровадження
Після впровадження логіка воронки перестає триматися на пам'яті інтегратора — вона зафіксована в документах, за якими відділ продажів працює самостійно. Нижче перелік того, що передається замовнику у фіналі проєкту.
- Схема воронки продажів — стадії та умови переходу між ними, обов'язкові поля на кожному кроці, прив'язка автоматики: автозавдання, повідомлення, зміна відповідального при простої угоди.
- Матриця прав доступу — які ролі бачать, змінюють і видаляють угоди, хто вивантажує базу та править налаштування; розмежування йде за відділами, а не «на всіх одразу».
- Регламент роботи з угодами — що менеджер робить на кожній стадії, у який строк, які дані зобов'язаний заповнити до переходу далі.
- Інструкція для менеджерів — покрокові сценарії під ролі: завести угоду, перевести за стадією, повернути з відмови, долучити документ, передати угоду колезі.
- Політики доступу та журнал перевірок — хто і коли змінював налаштування воронки, історія правок полів і статусів, порядок планових звірок.
- Документація по системі — карта зв'язків із 1С, телефонією та поштою, опис роботів, правила обробки помилок при обміні.
Документи пишуться під ваш процес, а не під шаблон, і перевіряються на реальних угодах до здачі. Коли етапи або відповідальні змінюються, схему та регламент оновлюємо — співробітники залишаються на актуальній версії, а не на усних домовленостях.
Кейс: перезібрали стадії та прибрали завислі угоди
Відділ продажів із розподіленою командою: шість менеджерів у трьох містах, спільний потік звернень із сайту, пошти та месенджерів. У Битрикс24 воронка продажів на момент розбору складалася з 12 стадій — три з них менеджери перестрибували, а п'ять не містили обов'язкових полів.
Угода йшла в «Успіх» без дати оплати та рішення щодо відвантаження, і у звіті керівника такі продажі місяцями значилися активними.
Що змінили в стадіях і правах
Стадії скоротили до семи, у кожної з'явилася ознака переходу та обов'язкові поля: дата наступного дотику, відповідальний, джерело, сума.
Права перебудували так, що переведення далі без заповнення полів неможливе, а повернення до попередньої стадії робить лише керівник і з коментарем. Додали етап погодження договору з чек-лістом і робота: п'ять днів без активності — завдання менеджеру, десять — ескалація керівнику.
Метрики до і після
Частка угод без руху знизилася з 34% до 11% — тепер у кожної видно точку зупинки й відповідального за наступний крок. Середній строк угоди скоротився з 47 до 29 днів, конверсія зі звернення в рахунок зросла майже на п'яту частину.
Кількість угод, за якими у звіті немає даних, звели до нуля. Стадія перестала бути ярликом і стала точкою контролю: завислі угоди видно на другий день, а не в кінці місяця, коли менеджер уже не пам'ятає контексту розмови.
Що робити, якщо угоди вже ведуться за своїми правилами
Так, перехід роблять на працюючій системі, без зупинки відділу. Порядок такий: спочатку на Битрикс24 добудовують додаткові воронки поруч із чинною — задають стадії, права, обов'язкові поля — і лише після прогону на тестовому контурі переносять угоди. До дня перемикання менеджери працюють у попередньому режимі.
Налаштування наявної системи починається з інвентаризації, а не з чищення: які стадії реально використовуються, де угоди зависають, які поля заповнюються, а які вже ніхто не веде.
Старі статуси не видаляємо — закриваємо для ручного вибору, але залишаємо доступними, щоб картки не втрачали зв'язок з історією.
Перенесення угод іде порціями за відповідальним або за датами, із зіставленням статусів і збереженням дати створення, суми, прив'язки до контакту та компанії.
Кожна картка отримує зовнішній ідентифікатор: повторний запуск вивантаження не створює дублів, а спірні записи потрапляють у звіт і добираються окремо — без ручного розбору всього масиву.
Звітність ламається не від перенесення, а від неповних проміжних стадій.
Тому на перехідний період довідники та причини відмови тримаємо узгодженими в обох схемах: видно, де угода була раніше і де вона зараз, і воронка продажів залишається зшитою, а не розпадається на два незв'язані набори цифр.
Коли звірка сходиться, відділ перемикається на нові контури, а попередні залишаються архівом для аудиту.
Технічні питання щодо стадій, прав і звітів
Стадії, права та звіти в системі пов'язані: правка однієї сутності змінює поведінку решти. Зібрали п'ять сумнівів, які найчастіше виринають на етапі проєктування, з короткими відповідями по суті.
Чи можна показати співробітнику лише частину стадій?
Так. Доступ налаштовується ролями й профілями: свій відділ бачить воронку цілком, суміжні підрозділи — лише потрібні ділянки та поля картки. Обмеження задаються на рівні прав, а не ручною фільтрацією у звітах, тому їх не можна обійти з інтерфейсу.
Що зміниться у звітах, якщо перейменувати або переставити стадії?
Історія за угодами зберігається, але звіти з фільтром за конкретною стадією доведеться перезібрати: частина метрик прив'язана до ідентифікатора стадії, а не до її назви в інтерфейсі. Тому зміни вносимо за регламентом і одразу перевіряємо здану звітність.
Як заявка з сайту потрапляє одразу в потрібну стадію?
Форма передає набір полів, за якими спрацьовує умова розподілу: джерело, напрям, тип запиту. Заявка створюється на стартовій стадії, далі переміщується автоматично, відповідальний призначається за правилом. Якщо форм кілька, кожну пов'язуємо зі своїм сценарієм, щоб потоки не змішувалися.
Чи потрібно кожному напряму робити окрему воронку?
Це залежить від того, чи різняться етапи та відповідальні. Якщо так, окрема воронка дає чисту конверсію за напрямом. Якщо процеси збігаються, краще одна воронка з розділенням за полями — інакше звіти доведеться зводити вручну.
Чи ламає статистику повернення угоди на попередню стадію?
Ні, це штатний сценарій: угода йде назад, у картці зберігається причина, а конверсія рахує повторні проходження окремо від первинних. Без обов'язкової причини повернення такі угоди розмивають картину, тому поле варто закріпити у формі.
Обговоримо задачу: склад робіт і порядок старту
Розбір починається з розмови по суті, а не з оглядової презентації: щоб повернутися з оцінкою та планом робіт, нам потрібно побачити вашу поточну воронку продажів у Битрикс24 — стадії, роботів, права, інтеграції. Чим більше контексту на вході, тим точніша оцінка і тим менше уточнень на етапі впровадження.
- Доступ до порталу на читання або до тестового контуру, де можна відтворити поточні налаштування воронки.
- Перелік воронок і напрямів із зазначенням, які з них живі, а які залишилися від попередніх схем.
- Опис процесу продажу від ліда до угоди: хто і на якому кроці змінює стадію, що вважається результатом етапу.
- Список автоматизації: роботи, тригери, бізнес-процеси, шаблони листів і завдання, які вже працюють.
- Інтеграції, що впливають на стадії: телефонія, пошта, форми на сайті, обмін із 1С і зовнішніми сервісами.
- Ролі та права за відділами — від них залежить, які переходи між стадіями доступні якій команді.
Ми розбираємо історію угод, дивимося, де вони залипають і на якому переході губиться найбільше, і звіряємо це з логікою стадій.
На виході ви отримуєте схему воронки, карту автоматизації та план робіт за етапами зі зрозумілим порядком старту: спочатку проєктування стадій на тестовому контурі, потім перенесення на робочий портал без зупинки продажів. Опишіть задачу — повернемося з оцінкою та планом робіт.
