Як підготувати знеособлений CRM-експорт до аналізу

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

Нижче розберемо підготовку знеособленого файлу, типові помилки та питання для аналізу. Інструмент аналізу CRM-експорту FBD допомагає опрацювати CSV у браузері. Використовуйте лише поля, потрібні для конкретного розрахунку.

Визначте запитання до даних

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

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

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

Які дані підготувати для CSV

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

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

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

Зокрема, перевіряйте існування календарної дати у вихідному файлі: запис на кшталт 2026-02-30 є некоректним. Перед експортом також переконайтеся, що програма правильно перетворила вихідні дати. Без часу в обох полях неможливо надійно визначити інтервал відповіді в хвилинах. Інструмент обчислює фактичний інтервал між внесеними моментами, а не виключає автоматично неробочі години чи вихідні.

Як прибрати персональні та чутливі дані

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

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

Європейська комісія пояснює, що псевдонімізовані дані, за якими людину можна повторно визначити, залишаються персональними даними в розумінні GDPR. Це пояснення стосується права ЄС; застосовні до вашої ситуації правила перевіряйте окремо.

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

Що показує зріз етапів

Уявімо, що знеособлений файл містить 100 рядків: 40 на етапі «нове звернення», 30 у роботі, 20 із пропозицією і 10 завершених. Це розподіл за поточними статусами на момент експорту.

Не можна автоматично зробити висновок, що з 40 нових звернень 10 стали завершеними. У файлі можуть бути записи, створені в різний час, а деякі угоди ще не завершилися. Для конверсії між етапами потрібно визначити одну групу звернень і мати надійну історію переходів.

Перевірте також, чи значення статусів написані однаково. Наприклад, «Пропозиція» і «пропозиція надіслана» можуть описувати один етап або різні. Рішення про їх об’єднання має ґрунтуватися на правилах вашої команди, а не лише на схожості слів.

Умовний приклад перевірки невеликого експорту

Уявімо навчальний файл із 12 рядків про окремі угоди. На дату експорту п’ять записів мають статус «нове звернення», чотири позначені «у роботі», два мають статус «пропозиція», а в одному статус не заповнений. Сума груп становить 5 + 4 + 2 + 1 = 12 рядків. Частка записів без статусу дорівнює 1 / 12 × 100%, приблизно 8,3%.

Це сигнал уточнити один запис у джерелі, а не доказ, що менеджер пропустив звернення. Якщо інструмент показує іншу кількість, перевірте, чи не було порожніх рядків, повторів або помилок підготовки файлу. Оскільки окремі рядки він не показує, перевірку робіть у вихідній копії без персональних даних. Умовний розподіл показує стан на дату зрізу, а не переходи між етапами.

Для трьох записів із перевіреними часом створення та першої відповіді припустімо інтервали 10, 20 і 60 хвилин. Середнє становить 90 / 3 = 30 хвилин, медіана 20 хвилин. Інші дев’ять записів у цьому прикладі не включено до розрахунку, тому висновок стосується лише трьох коректних пар дат. Причини пропусків потрібно з’ясувати окремо.

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

Як аналізувати час відповіді

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

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

Припустімо, п’ять коректних інтервалів становлять 5, 10, 15, 20 і 100 хвилин. Медіана дорівнює 15 хвилинам, а середнє 30 хвилинам. Ці значення описують різні властивості одного набору й самі по собі не пояснюють причину довгого очікування.

Коли можна порівнювати повторні покупки

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

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

Когортний режим на сторінці працює окремо від аналізу CSV. Спочатку підготуйте зведені кількості для кожної групи, а потім внесіть їх вручну. Експорт автоматично не створює когорти й не переносить дані між режимами.

Зміна частки повторних покупок не доводить, чому вона відбулася. Окремо перевіряйте склад аудиторії, продукт, канали та сезонність. Інструмент описує введені дані, але не визначає причину автоматично.

Як перевірити якість результату

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

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

Запишіть обмеження: за якою датою зроблено експорт, що означають статуси, які колонки неповні та які записи виключено. Перед передачею висновку команді відділіть факти від припущень. Наприклад, «у 12 рядках немає дати відповіді» є спостереженням; «команда не відповіла 12 клієнтам» потребує додаткової перевірки.

Якщо CRM ще не налаштована, почніть із підготовки до впровадження CRM. Для планування потоку та часу команди також можна використати калькулятор потужності відділу продажів.

Типові помилки

Завантаження всіх колонок без перегляду. У примітках чи назвах файлів можуть бути персональні дані. Створіть окремий мінімальний експорт.

Трактування зрізу як історії руху. Поточний статус не доводить, через які етапи і коли пройшла угода. Для цього потрібні відповідні події або дати.

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

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

Поширені запитання

Чи потрібна повна база клієнтів?

Ні. Для кожного запитання підготуйте лише потрібні знеособлені поля. Для простого розподілу за стадіями достатньо статусу кожного рядка.

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

Ні. Він допомагає проаналізувати введений файл і не організовує комунікацію з клієнтами.

Чи можна вважати результат фінальним звітом?

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

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