Проектування структури CRM-сутностей Бітрікс24

Проектування структури CRM-сутностей Бітрікс24

Одне з найчастіших питань при впровадженні Бітрікс24: «А навіщо нам ліди, якщо є угоди?» Або навпаки: «Давайте все зберігатиметься як контакти, навіщо ускладнювати?» Неправильна відповідь на початку проекту призводить до того, що через півроку CRM забита дублями, менеджери не розуміють, де шукати історію клієнта, а звіти не працюють так, як очікувалося.

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

Карта сутностей Бітрікс24 CRM

Бітрікс24 надає такий набір вбудованих сутностей:

• Лід (crm_lead, таблиця b_crm_lead) — некваліфікований інтерес, потенційний клієнт до перевірки його цінності.
• Контакт (crm_contact, b_crm_contact) — фізична особа, з якою ведеться комунікація.
• Компанія (crm_company, b_crm_company) — юридична особа або організація.
• Угода (crm_deal, b_crm_deal) — конкретний продаж або проект із сумою та воронкою.
• Рахунок (crm_invoice) — комерційний документ, прив'язаний до угоди або контакту.
• Пропозиція (crm_quote) — комерційна пропозиція до виставлення рахунку.
• Смарт-процеси (crm_dynamic_*) — користувацькі сутності з довільною структурою полів і воронкою.

Принципові архітектурні питання

Ліди увімкнені чи вимкнені?

Це перший і найважливіший вибір. У Бітрікс24 можна працювати в «класичному» режимі (ліди → угоди) або в «простому» (одразу угоди, ліди вимкнені). Ліди потрібні, коли:

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

Якщо компанія невелика і кожен вхідний запит одразу кваліфікований — ліди додають зайвий крок без користі.

Коли потрібні смарт-процеси?

Смарт-процеси (з'явилися в Бітрікс24 наприкінці 2021 року) — це налаштовувані сутності. Технічно вони зберігаються в b_crm_dynamic_{type_id} — окрема таблиця на кожен тип. Використовуються, коли:

• Потрібна сутність із власною воронкою, але не «продаж» (наприклад: «Заявка на сервіс», «Рекламація», «Проект»)
• Стандартні поля угоди не покривають потрібну логіку
• Потрібна окрема аналітика, не змішана з угодами

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

Зв'язки між сутностями.

Контакт може бути прив'язаний до компанії (відношення M:1). Угода може бути прив'язана до контакту та/або компанії. Лід при конвертації створює контакт, компанію та/або угоду. Ці зв'язки зберігаються в b_crm_entity_link.

Проектуючи структуру, потрібно вирішити: чи обов'язкова прив'язка угоди до контакту? Чи може угода існувати без компанії? Що відбувається при видаленні контакту — видаляються пов'язані угоди?

Кейс: структура CRM для сервісного центру

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

Проблема: угода закривалася, але клієнт приходив знову — створювалася нова угода без зв'язку з історією. Через рік CRM містила 3 200 «Іваненків» без розуміння, скільки разів кожен із них звертався.

Спроектована структура:

Контакт — фізична особа (клієнт). Обов'язковий. Зберігає історію всіх звернень.

Смарт-процес «Пристрій» — кожен прилад, який коли-небудь здавався в ремонт. Поля: серійний номер, модель, бренд, рік покупки. Прив'язаний до контакту. Один контакт — кілька пристроїв.

Угода «Ремонт» — конкретний випадок ремонту. Прив'язана до контакту і до смарт-процесу «Пристрій». Поля: опис несправності, діагноз, вартість робіт, вартість запчастин, статус гарантії.

Результат: історія ремонтів за пристроєм видна в одному екрані. Повторні звернення клієнта пов'язані через контакт. З'явився звіт «найчастіше ламані пристрої» — це виявився реальний інсайт для відділу закупівлі запчастин.

Користувацькі поля vs смарт-процеси

Поширена помилка — додавати 20–30 користувацьких полів у стандартну угоду замість створення окремої сутності. Симптоми: картка угоди перетворюється на анкету на 4 екрани прокрутки, менеджери заповнюють третину полів, аналітика не працює.

Правило: якщо група полів описує окремий об'єкт (не сам продаж) — розглядаємо смарт-процес. Якщо поля доповнюють продаж — залишаємо в угоді, але групуємо за вкладками.

Терміни

Проектування структури CRM-сутностей для типового B2B-бізнесу — 4–8 днів: інтерв'ю, аналіз, проектування схеми зв'язків, погодження, реалізація базової структури, документація. Складні структури з кількома смарт-процесами і нестандартними зв'язками — 2–4 тижні.