Проєктування карток угод у CRM Bitrix24

Проєктування карток угод у Bitrix24: де рветься воронка

Картка угоди — це не форма для заповнення, а контракт між етапами воронки: що має бути відомо про клієнта на момент передачі до наступного відділу.

Коли обов’язкові поля угоди проєктують «з пам'яті», картка живе за різними правилами в різних менеджерів: частина угод рухається далі з порожніми ключовими атрибутами, і звіт про конверсію описує вже не реальність, а звички конкретних співробітників.

Найдорожча втрата заявок у воронці — та, де заявка формально не втрачена. Угода залишається в базі, але джерело звернення не заповнене, тому її не видно ні в розрізі за каналами, ні в прогнозі.

Аналогічно з дублями: клієнт повертається, менеджер створює другу угоду або нового контакту — і історія звернень розходиться між двома записами, кожен з яких виглядає неповним.

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

Кожне копіювання — це затримка відповіді та новий шанс щось не донести: частина історії осідає в коментарях і чатах, до яких наступний учасник уже не дійде.

Усе це лікується не мотивацією і не регламентом, а проєктуванням карток угод: обов’язкові поля угоди з правилами заповнення та перевіркою на переході, автоматичне перенесення даних між етапами, відлов дублів до створення запису та наскрізна історія звернень в одній картці. Розбираємо, як це влаштовано.

Що змінюється після переробки логіки продажів

Ефект від переробки карток видно за метриками, які знімаються на одній і тій самій вибірці угод до змін і через місяць роботи в новій логіці. Нижче — те, що ми перевіряємо разом із замовником на живій воронці в Bitrix24.

• Скорочення часу обробки заявки. Картка заповнюється за 2–3 хвилини замість десяти: частина полів приходить із форми, решту вибирають із довідника. Менеджер займається клієнтом, а не перемиканням між вікнами та пошуком даних.
• Частка пропущених обов’язкових полів. Валідація на переході між стадіями не пропускає угоду без ключових даних — пропуски падають із половини карток до поодиноких випадків, і звітність перестає будуватися на здогадках.
• Прозорість етапів воронки. У кожної стадії одне визначення й один набір обов’язкових полів, тому керівник бачить реальну картину: де угоди стоять, де зависають і на якому кроці губляться.
• Усунені класи помилок. Подвійні картки за одним клієнтом, розірваний зв’язок угоди з контактом і компанією, розбіжності з обліковою системою під час перенесень. Ці помилки не «стали рідшими» — їх більше ніде припуститися.
• Єдині правила кваліфікації. Критерії переведення зафіксовані в полях і перевірках, а не в усних домовленостях, тому два менеджери за однакових вихідних даних ухвалюють однакове рішення.
• Швидкість відновлення після збою. Історія змін за полями та стадіями дозволяє повернути картку до попереднього стану точково, без розбору вивантажень і ручного відновлення зв’язків.

Показники знімаємо до і після на однакових періодах, інакше порівняння нічого не доводить.

Порівняння підходів до налаштування картки

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

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

Такий розріз знімає головний ризик проєктування — логіка, розмазана по налаштуваннях, ламається за першої ж зміни процесу.

Етапи впровадження: від аудиту до передачі регламентів

Картка угоди — це не форма, а модель даних: поля, зв’язки з контактом, компанією та рахунком, стадії, права ролей і роботи, які на все це реагують.

Якщо почати з перемальовування інтерфейсу, через місяць з’ясується, що частина полів дублюється, історія звернень не підтягується, а автоматизація спрацьовує не на тій стадії.

Тому порядок робіт фіксований: спочатку розбір даних і схеми, потім налаштування, потім перевірка на реальних сценаріях продажів.

1. Аудит CRM перед доопрацюванням. Вивантажуємо поточні сутності, поля, стадії, права та роботів, позначаємо дублі й невикористовувані поля, дивимося, де менеджери обходять систему вручну.
2. Схема полів і зв’язків. Карта: які поля обов’язкові, які обчислюються автоматично, як угода пов’язана з контактом, компанією, рахунком, завданням і зверненням із каналу зв’язку.
3. Налаштування стадій, правил і ролей. Збираємо воронки, тригери й обмеження прав за відділами, щоб картка показувала менеджеру рівно те, що потрібно на поточному кроці.
4. Перевірка сценаріїв продажів. Проганяємо типові та пограничні шляхи — повернення на попередню стадію, повторне звернення, угоду без компанії — на тестовому контурі з копією даних.
5. Перенесення історії звернень. Завантажуємо накопичені угоди та листування зі збереженням дат, авторства й зв’язків, звіряємо кількість записів до і після.
6. Обкатка на одному відділі. Вмикаємо нову схему для обмеженої групи, дивимося швидкість заповнення та частку карток без обов’язкових полів.
7. Передача регламентів. Віддаємо схему даних, опис ролей, інструкції та правила супроводу — щоб правки далі вносилися без нас.

Схеми даних, політики доступу та регламенти роботи

Проєктування карток угод завершується не налаштуванням полів, а комплектом артефактів. За ними команда супроводу розвиває систему, а відділ продажів працює без усних домовленостей про те, хто що заповнює.

• Схема сутностей CRM: угоди, компанії, контакти, товарні позиції та додаткові сутності — типи полів, зв’язки й правила перенесення значень між стадіями.
• Матриця прав за ролями: хто читає, хто редагує, хто бачить лише свої записи — аж до окремого поля; перевіряється тестовими обліковими записами до запуску.
• Регламент заповнення полів: обов’язкові поля для кожної стадії, умови переходу далі та порядок дій, коли даних не вистачає.
• Правила автоматизації: роботи, тригери й бізнес-процеси з умовами спрацювання, постановкою завдань, зміною відповідального та обробкою помилок.
• Інструкція для відділу продажів: покроковий сценарій роботи з карткою — що заповнювати під час дзвінка, перед пропозицією та під час закриття угоди.
• Порядок внесення правок: як заводиться запит на нове поле або стадію, хто погоджує, як зміна тестується й відкочується.
• Карта міграції: зіставлення полів із попередньої системи з новою схемою та журнал розбіжностей для ручного розбору.

Комплект передається і як документація, і як робочі налаштування — його достатньо, щоб новий адміністратор увів систему в дію без автора схеми.

Кейс: єдина модель даних для трьох напрямів продажів

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

Обов’язкові поля не збігалися, частину реквізитів менеджери дублювали в коментарях, повторний клієнт заводився другою карткою — типовий кейс впровадження CRM, де проблема не в налаштуваннях, а у відсутності спільної моделі даних.

Що було до

Заявки губилися на стику між відділами: угода переходила на наступний етап, але відповідальний не змінювався — частка втрат сягала п’ятої частини нових звернень. Дублі становили близько третини угод, історія за клієнтом не збиралася.

Середній строк проходження етапу вимірювався днями й у кожного відділу рахувався за своїми статусами, порівняти напрями було неможливо. Підтримка отримувала десятки питань на тиждень лише про те, як правильно заповнити картку.

Що змінили

Спроєктували єдину модель: спільний довідник полів з обов’язковістю, прив’язаною до стадії, правило зміни відповідального під час переходу між напрямами та перевірку контакту за номером і поштою перед створенням нової угоди. Напрями розвели за окремими воронками зі спільною аналітикою.

Після запуску частка втрачених заявок упала з 18% до 2%, дублі — з 30% до 3%, середній строк проходження етапу скоротився вдвічі, а кількість звернень до підтримки щодо заповнення — утричі. Звітність за трьома напрямами вперше збиралася з одного джерела.

Що робити, якщо система вже розгорнута і полів занадто багато

Переповнена структура полів майже ніколи не потребує зупинки відділу продажів. Обов’язковість, порядок і видимість полів, підказки, нові значення довідників змінюються прямо в робочому контурі — за хвилини, без вивантажень і пауз у переговорах.

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

Причина проста: картка — не ізольована форма, а вузол зв’язків. На значення полів спираються звіти, автоматизації, права ролей і обмін з обліковою системою. Тому застаріле поле не можна вимкнути однією дією — спочатку потрібно побачити, хто і що з нього читає. Інвентаризація за фактом використання займає пару днів і знімає основну частину ризиків.

Далі працює поетапна переробка CRM, де кожен крок оборотний:

Між кроками тримаємо паузу — тиждень спостереження за зверненнями до поля та помилками обміну. Такий порядок дозволяє закривати угоди на кожному етапі: недоступним стає лише те, що вже виведено з використання і не потрапить у звітність.

Технічні сумніви: обмеження, міграції, інтеграції

Картка угоди — не окрема форма, а надбудова над штатним об’єктом CRM: поля, стадії, права й правила автоматизації живуть у тій самій сутності, що й стандартні. Тому заперечення в інженерів повторюються — розберемо чотири найчастіші.

Що буде з обміном, якщо облікову систему замінять?

Обмін будується на постійних ідентифікаторах: угода, контрагент і позиції пов’язуються за зовнішнім ключем, а не за назвою.

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

Чи збережеться історія угод?

Закриті угоди залишаються зі своїми стадіями, відповідальними та листуванням, нові поля заповнюються в міру руху. Зміни значень пишуться в журнал — видно, хто і коли їх вніс, що закриває питання аудиту під час зміни команди.

Що входить у супровід після передачі?

Регламент змін, схема полів і ролі доступу. Правки в стадіях і правилах автоматизації йдуть через погоджений порядок і тестовий контур — картка не «розповзається» через пів року після запуску.

Обговоримо задачу — повернемося з оцінкою та планом

Щоб спроєктувати картки угод під ваш процес, а не під середній шаблон, потрібен короткий розбір поточного стану. Достатньо надіслати те, що вже є, — чого бракує, уточнимо на дзвінку.

• Склад ролей і напрямів: хто працює в CRM — продажі, сервіс, постачання, керівництво — і які зони відповідальності за ким закріплені.
• Поточна структура полів: обов’язкові й необов’язкові поля, дублі, формат ведення довідників і контрагентів.
• Етапи угоди: стадії воронки, що вважається результатом етапу і де потрібні обов’язкові перевірки перед переходом далі.
• Наявні інтеграції: 1С, телефонія, пошта, сайт, зовнішні сервіси — що синхронізується і за якою ознакою зіставляються записи.
• Вимоги до звітності: які зрізи потрібні керівництву, з якою періодичністю і в яких розрізах — напрям, співробітник, період.
• Розмежування доступу: кому видно які поля й розділи, чи потрібен журнал дій за карткою.

Далі обговорюємо задачу автоматизації, звіряємо список і повертаємося з оцінкою та планом робіт: схема полів, порядок перенесення даних, етапи впровадження та точки контролю.

Обсяг і послідовність ви бачите до старту — правки на цьому етапі коштують дешевше, ніж переробка воронки після запуску.