Налаштування дашбордів Bitrix24: чому звіти не сходяться
У керівника три цифри щодо однієї й тієї самої воронки — у звіті системи, у таблиці аналітика й у презентації комерційного директора.
Розбіжність майже ніколи не в арифметиці: кожне джерело по-своєму відповідає на питання, що вважати угодою, за який період і за яким моментом часу.
Причина в тому, як збирається управлінська звітність. Частина даних живе в картках угод, частина — в необов'язкових полях, які заповнюють через раз, а частина надходить вивантаженням угод із зовнішніх систем.
Звіт за замовчуванням бере дату створення, аналітик — дату оплати, керівник відділу — дату останнього дотику. Усі три числа коректні в межах свого визначення й несумісні між собою — звідси й «у нас продажі то більші, то менші».
Далі підключається ручне складання: вивантаження в таблицю, зведені, дописані формули, забуті фільтри. Кожна ітерація додає шар, який ніхто не переперевіряє, а відповідь на питання «скільки ми продали за квартал» потребує пів години й не відтворюється під час повторного запуску.
Для налаштування дашбордів Bitrix24 це означає одне: спочатку фіксуємо модель даних — які стадії вважаємо продажем, за якою датою, як враховуємо повернення, дублі та часткові оплати, як зводимо валюти.
Аналітика продажів Bitrix24 стає достовірною не від графіків, а від того, що всі панелі читають одне джерело за однаковими правилами. Розбираємо нижче, як це закривається.
Що дає керована аналітика продажів: вимірювані ефекти
Єдине джерело даних — те, що змінюється раніше за все. Поки угоди, завдання та дзвінки лежать у CRM, а зведення збираються вивантаженнями в таблиці, керівник і менеджер показують різні цифри за один і той самий період.
Аналітичний контур переносить події з CRM у сховище за розкладом і рахує воронку, план і факт за однією методикою. Розбіжність між звітом відділу та звітом комерційного директора перестає бути предметом суперечки — її просто не вдається відтворити.
Час складання звіту падає з кількох годин до відкриття дашборда керівника: період, воронка, менеджер і джерело перемикаються на місці, без вивантажень і склеювання файлів.
Окремий ефект — якість даних CRM: порожні поля, дублі контактів, угоди без наступного кроку та з простроченою датою закриття. Це перетворюється на правила: обов'язкові поля під час переходу між етапами, автозавдання на зміну стадії, звіт щодо дисципліни заповнення.
В галузевих оглядах Gartner з BI-аналітики повторюється один висновок: цінність дає не сама панель, а довіра до цифри та швидкість її отримання. Тому ефект впровадження аналітики вимірюють не кількістю графіків, а часткою рішень, ухвалених за даними.
Вбудовані звіти, зовнішній BI-шар чи гібрид: порівняння
Вибір між трьома схемами визначається обсягом угод, глибиною історії та тим, які питання керівник ставить щодня.
Вбудовані звіти Bitrix24 працюють на даних порталу без вивантаження: воронка, конверсія за стадіями та навантаження на менеджерів видно одразу, в актуальному стані, налаштування займає мінімум часу.
Обмеження вбудованих звітів проявляються зі зростанням бази: довільні зрізи за кількома воронками та періодами збираються помітно довше, частина розрахунків іде за поточним станом угоди, а історія переходів доступна не в усіх розрізах.
Зовнішній BI-шар знімає ці рамки, але додає свій контур — регулярне вивантаження у сховище, опис моделі даних і підтримку звірки з порталом.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані звіти порталу | Одна-дві воронки, горизонт до року, потрібні оперативні зрізи за стадіями та менеджерами | Довільні зрізи та зведення за кількома воронками рахуються повільно; історія переходів не в усіх розрізах; дані інших систем не підключаються |
| Зовнішній BI-шар | Кілька джерел, довга історія, складні зрізи та порівняння періодів | Потрібні регулярне вивантаження у сховище, опис моделі та підтримка; дані доступні із затримкою щодо порталу |
| Гібрид | Оперативні зрізи потрібні в моменті, а глибокий аналіз — раз на тиждень або місяць | Дорожче в налаштуванні: два контури, правила звірки показників і єдині довідники |
Гібридний варіант аналітики закриває обидві вимоги: щоденні зрізи залишаються в порталі, а глибокі — за довгими періодами, каналами та кількома джерелами — переходять у зовнішній шар.
Критерій вибору простий: якщо керівнику потрібна швидка відповідь на часте питання, залишаємо розрахунок у порталі; якщо потрібен розріз за роками та наскрізна звірка з іншими системами — рахуємо у сховищі.
Етапи впровадження аналітики продажів: від аудиту даних до регламенту
Порядок етапів важливіший за швидкість. Почнеш із дашбордів — керівник через місяць перестане їм вірити: цифри в CRM та обліковій системі розходяться, і кожна суперечка переходить у ручну звірку. Тому йдемо від даних до візуалізації.
- Аудит даних CRM. Дивимося, на що можна опертися: заповнюваність обов'язкових полів, дублі контактів і угод, угоди без відповідального, налаштування воронок і стадій, історію переходів між ними. Результат — карта джерел і список полів, які доведеться доналаштувати.
- Проєктування моделі даних. Фіксуємо визначення метрик: що вважаємо виручкою, що — закритою угодою, як враховуємо часткові оплати та повернення. Розділяємо показники за джерелами й задаємо ключ зв'язування записів.
- Налаштування інтеграцій. Вибудовуємо обмін між CRM, обліковою системою та зовнішніми джерелами: розклад завантаження, повтор при збої, зіставлення довідників — номенклатури, контрагентів, менеджерів. Розбіжності довідників і дають «плаваючі» цифри.
- Складання дашбордів за ролями. Керівнику відділу — воронка та завантаження менеджерів, комерційному директору — динаміка за каналами й план-факт, власнику — зведення за напрямами. Кожен показник розкривається до угоди.
- Перевірка збіжності цифр. Звіряємо підсумки з первинними документами та ручними вивантаженнями за минулі періоди. Задаємо допустиму розбіжність і розбираємо кожне відхилення до причини.
- Передача регламенту. Описуємо власника метрики, порядок оновлення полів і стадій, дії при зміні воронки та правила додавання нового показника.
Після цього звітність живе самостійно: зміни у воронці не ламають модель, а новий розріз додається за описаною процедурою, без повторного аудиту даних.
Що залишається у вас після впровадження: конфігурації дашбордів
Після здавання у вашому порталі залишається не набір скриншотів, а робоча конфігурація, яку можна розвивати без нас. Ми передаємо її разом з описом логіки — щоб новий адміністратор або аналітик розібрався в показниках, не перезбираючи звітність з нуля.
- Конфігурації дашбордів — подання під конкретні ролі: воронка за етапами та менеджерами, план-факт за періодами, динаміка середнього чека й довжини циклу угоди.
- Опис показників — для кожної метрики вказано формулу, джерело даних і те, які угоди до неї потрапляють, а які виключено.
- Ролі доступу до аналітики — які зрізи бачить керівник відділу, які комерційний директор, де діє обмеження за філією або напрямом.
- Регламент оновлення даних — періодичність підвантаження, вікно перерахунку й момент, на якому угода вважається закритою для звітності.
- Документація з аналітики — паспорт кожного звіту: призначення, власник, джерела, відомі обмеження.
- Карта джерел — які поля беруться з угод, які із завдань і дзвінків, де ручний ввід і де можливі розбіжності.
- Чек-лист приймання — контрольні цифри, за якими ви звіряєте дашборд з вихідними даними після правок воронки.
Конфігурація дашбордів залишається у вашому Bitrix24 і версіонується: перед будь-яким доопрацюванням видно, що саме змінилося в наборі показників і правилах їх розрахунку.
Кейс: як аналітика продажів скоротила ручну звірку звітів
Відділ продажів із чотирнадцяти людей вів воронку в Bitrix24, але зведення для керівника збирали вручну: вивантаження угод, зведення в таблицю, ручне групування за етапами.
На це йшло шість-вісім годин на тиждень, цифри в різних співробітників розходилися, а в частини угод залишалися порожні обов'язкові поля — звіт будувався на неповних даних.
Що змінили та що вийшло
Спочатку зафіксували обов'язкові поля на кожному етапі: без джерела, суми та дати наступного дотику угода далі не рухається. Потім зібрали дашборди — воронку продажів за етапами й відповідальними, конверсію між етапами, угоди без активності, середній цикл угоди. Керівник дивиться їх без вивантажень: дані оновлюються разом зі змінами в картках.
| Метрика | До | Після |
|---|---|---|
| Підготовка зведення для керівника | 6–8 годин на тиждень вручну | дашборд оновлюється сам |
| Заповнюваність обов'язкових полів | близько 60% угод | 96–98% угод |
| Розбіжності між звітами | до 15% за етапами воронки | зведені до нуля |
| Строк виявлення завислої угоди | 2–3 тижні | 2 дні |
Скорочення ручної роботи вийшло повним: час пішов не на зведення таблиць, а на розбір завислих угод. Дисципліна заповнення перестала залежати від нагадувань — поле блокує перехід за етапом, тому метрики до й після розходяться саме там, де раніше губилися дані.
Чим відрізняється вбудована аналітика від зовнішнього BI-шару?
Штатні звіти в Bitrix24 рахують за робочою базою: вибірка будується на льоту, агрегація обмежена полями угод і воронкою. Поки питання звучить як «скільки угод закрили цього місяця», цього достатньо.
Але щойно потрібен зріз за регіонами, менеджерами й товарними групами одночасно, запит починає перебирати всю таблицю — звіт відкривається хвилинами й навантажує систему, у якій працюють продавці.
Зовнішній шар даних влаштований інакше. Записи за розкладом вивантажуються в окреме сховище, приводяться до єдиної моделі — виміри та факти — і вже там рахуються зведені.
Важкі вибірки не торкаються робочої бази, історія зберігається роками, а джерела з'єднуються за спільними ключами.
BI-шар потрібен, коли джерел більше одного й частина даних лежить поза CRM; коли глибина історії перевищує те, що зручно тримати в системі; коли звіти потрібні за ролями та в довільних зрізах, а регламентне зведення має збиратися саме. Якщо завдання — один показник за однією воронкою, зовнішній шар надлишковий.
Складність підтримки аналітики при цьому зростає: з'являється другий контур — завантаження й модель. За схемою джерел потрібно стежити, при зміні полів правлять перетворення, а не лише сам звіт.
Зате масштабування звітності йде дешевше: нове джерело або розріз розширює модель, готові дашборди продовжують працювати.
Технічні сумніви: джерела даних, доступи, оновлення
Перед стартом технічний керівник ставить ті самі питання: звідки візьмуться цифри, хто що побачить, що робити з неповними даними й що зміниться після оновлення порталу. Нижче — короткі відповіді, деталі за будь-яким пунктом фіксуємо в плані робіт.
Звідки беруться дані для аналітики?
Основне — об'єкти самого Bitrix24: угоди, поля, стадії, довідники. Зовнішні джерела — облікову систему, телефонию, рекламу — підключаємо обміном в окреме сховище. Звітність читає копію, тому не сповільнює роботу менеджерів.
Як розмежувати доступ за відділами?
Права успадковуються від ролі в Bitrix24 і групи у звітності: керівник відділу бачить свою воронку та своїх співробітників, комерційний директор — зведення за всіма. Матрицю доступів узгоджуємо до старту.
Що робити з неповними даними в CRM?
Спочатку аудит заповненості полів: обов'язковість на стадії, довідники замість вільного вводу, автозаповнення з інтеграцій. Інакше звіт побудується, але довіри до цифр не буде.
Що буде після оновлення системи?
Збір даних тримаємо в окремому контурі, зіставлення полів і стадій — у конфігурації. Після релізу проганяємо звірку: розбіжності видно раніше, ніж у керівника.
Як звести кілька воронок і філій?
Єдина модель: довідники підрозділів і напрямів, спільні поля для зіставлення. Зведення за групою та деталізація до філії будуються з одних даних, тому різні процеси не заважають порівнювати результат.
Обговоримо завдання: зберемо схему аналітики під ваші процеси
Щоб обговорити завдання аналітики предметно, нам достатньо однієї розмови на 40–60 хвилин з вашого боку — зазвичай беруть участь керівник напряму й той, хто веде воронку в CRM.
До зустрічі корисно мати під рукою перелік джерел: угоди та їхні стадії, довідник відповідальних, правила розрахунку виручки й маржі. Цього достатньо, щоб повернутися з оцінкою та планом робіт, де буде зафіксовано склад показників, строки й точки контролю.
Що потрібно підготувати до старту, збираємо разом і за пунктами:
- які рішення керівник ухвалює за цифрами і як часто — від тижневого розбору до щоденного контролю;
- за якими стадіями воронки рахуємо конверсію і де фіксуємо причину відмови;
- звідки беруться планові значення і хто відповідає за їхню актуальність;
- які розрізи обов'язкові: менеджер, напрям, канал, регіон, товарна група;
- права доступу — хто бачить виручку й маржу, а хто лише активність за угодами;
- регламент оновлення даних і поріг, після якого показник вважається недостовірним;
- хто з боку замовника приймає перший дашборд для керівника й вносить правки.
На виході у вас залишається схема аналітичного контуру: джерела, правила розрахунку, розмежування доступу та порядок оновлення — за нею систему зможе розвивати будь-який інженер, а не лише автор налаштування. Опишіть завдання та поточні звіти — повернемося з оцінкою, планом і першим дашбордом керівника.
