Проєктування користувацьких полів CRM Бітрікс24 під ключ

Проєктування користувацьких полів Бітрікс24: де ламається облік

Картка угоди живе довше, ніж регламент, за яким її заводили. Спочатку з’являється поле «Коментар для складу», потім «Коментар для складу (нове)», потім хтось додає термін постачання рядком — і в одній сутності вже три поля про одне й те саме.

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

Паралельно розходиться довідник: значення вводять руками — «ТОВ Ромашка», «Ромашка ТОВ», «ромашка», три записи замість одного.

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

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

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

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

Що дає єдина схема атрибутів у картках угод

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

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

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

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

Цілісність даних у звітах тримається на тому, що всі картки описуються одними й тими самими атрибутами.

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

Зникає цілий клас помилок: дублі контрагентів, різні позначення одного й того самого значення, поля, заповнені «на око» і загублені під час зміни відповідального.

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

У Бітрікс24 така схема лягає на користувацькі поля, довідники та картки типових сутностей — але проєкт має сенс лише тоді, коли атрибути виведені з реальних маршрутів угоди, а не зібрані «за мотивами» поточного інтерфейсу.

Варіанти реалізації довідників: порівняння підходів

Довідник у Бітрікс24 можна зібрати чотирма способами, і вибір між ними визначає не звичка розробника, а те, хто володіє даними, як часто вони змінюються і чи потрібні зв’язки з іншими сутностями. Нижче — коли кожен варіант доречний і на чому він починає впиратися в обмеження.

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

Порядок робіт: від розбору карток до регламенту

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

1. Аудит карток. Вивантажуємо структуру лідів, угод, контактів і смарт-процесів: список полів, типи, дублі, порожні та застарілі.

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

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

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

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

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

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

Що передаємо на руки: конфігурації, схеми, інструкції

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

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

Що входить у комплект

• Налаштовані поля та права — перелік усіх створених полів із типом, обов’язковістю, значеннями за замовчуванням, прив’язкою до стадій і ролей. Окремо позначено, які поля системні, а які наші: це знімає питання «чи можна чіпати».
• Схема зв’язків полів — як поля залежать одне від одного, з якими сутностями пов’язані, де спрацьовує автозаповнення та перерахунок, що йде у звіти.
• Політика доступу — матриця «роль — поле — дія»: читання, запис, зміна. З обґрунтуванням, чому частину полів приховано на певних стадіях і ділянках воронки.
• Інструкція для співробітників — пам’ятка щодо заповнення та розбір типових ситуацій: поле не заповнюється, значення підтягнулося неправильно, співробітник пішов у відпустку і дані не рухаються.
• Журнал змін — що, коли і за чиїм узгодженням змінювалося в структурі полів, чим це загрожувало звітам і як відкотити правку.
• Регламент розширення — порядок додавання нового поля: які перевірки пройти, щоб не зламати наявні зв’язки, вивантаження та вибірки.
• Карта вивантажень — які поля йдуть у зовнішні системи та у звітність, із зазначенням періодичності й відповідального.

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

Кейс: як прибрали ручне введення в картках відділу продажів

Відділ продажів працював у картці, де на угоду припадало 34 поля, і більш ніж половину менеджери заповнювали руками. На одну заявку йшло близько 11 хвилин, а кожна п’ята поверталася на доопрацювання — дані в картці розходилися з договором.

Розбираємо кейс впровадження, де ми перепроєктували користувацькі поля в Бітрікс24 під реальний процес продажу.

Що змінили

Спочатку пройшли воронкою і виписали, які дані справді потрібні на кожному кроці. Із 34 полів залишили 12 обов’язкових, решту згорнули в блоки за стадіями.

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

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

Метрики до і після

• Полів у картці: 34 → 12, час заповнення скоротився майже втричі.
• Час обробки заявки: з 11 хвилин до 4.
• Частка ручних операцій: з 58% до 19%.
• Заявки, повернені на доопрацювання: з 21% до 5%.

Через пару місяців команда відмовилася від паралельної таблиці для обліку — даних у картці стало достатньо і для звітності, і для контролю якості роботи менеджерів.

Що робити, якщо в Бітрікс24 вже створено власні атрибути?

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

Так видно, які атрибути дублюють одне одного, які створено під разове завдання і давно пустують, а які тримають на собі розрахунки та воронку.

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

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

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

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

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

Часті технічні сумніви перед стартом робіт

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

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

Чи не з’являться два поля з однаковим змістом?

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

Чи піде нове поле в 1С і повернеться назад?

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

Чи зламає поле наявні звіти та воронку?

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

Чи не зросте навантаження на відділ?

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

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

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

Що зняти з вашого боку заздалегідь:

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

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