Міф: чим більше полів в CRM, тим краще керування

Чую цю фразу на кожному другому брифінгу: «Давайте додамо ще поле, щоб точно нічого не загубити». І ще одне. І ще. За годину обговорення картка клієнта виглядає як анкета на візу.

Міф звучить так: чим детальніша картка клієнта в CRM, тим краще власник бачить бізнес і тим суворіше контролює менеджерів. Логіка проста — більше даних, більше контролю. На практиці все рівно навпаки.

Чому в цей міф так легко повірити

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

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

Я регулярно бачу це в проєктах: замовник приходить з готовим списком із 30-40 полів, скопійованим з якогось «ідеального чек-листа CRM» з інтернету. Половина цих полів існує, бо «а раптом знадобиться». За рік роботи системи реально використовується частина з них, решта просто захаращують екран і сповільнюють кожну дію менеджера.

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

Що насправді відбувається з зайвими полями

Коли в картці 15+ обов'язкових полів, менеджер починає їх заповнювати як завгодно, аби система пропустила далі. Ставить перший варіант зі списку, копіює попереднє значення, лишає заглушку «уточнити пізніше» і більше ніколи не уточнює.

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

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

Приклад з практики: тендери Prozorro

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

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

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

Коли міф усе ж має рацію

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

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

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

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

Коротко про головне

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