1. Огляд проєкту
Клієнт — команда продажів, яка довго працювала в CRM без жорсткої дисципліни даних. Система мала зберігати покупців, контакти, компанії, замовлення й історію комунікації, але поступово перетворилась на базу, якій менеджери вже не могли повністю довіряти
Проблема була не в самій CRM. Проблема була в тому, як люди користувались полями: ім'я могло лежати в компанії, компанія — в імені, нотатка — в полі контакту, військова частина — у довільному форматі, ФОП/ТОВ/ГО/БФ — без єдиного канону, а один покупець міг існувати в десятках карток
Моя роль була навести порядок без грубого масового “почистити все”. Я мав витягнути реальний стан бази, побудувати правила нормалізації, показати dry-run, відділити безпечні автоматичні зміни від ручного розбору і дати команді чіткий канон заповнення CRM надалі
2. З чим прийшов клієнт
•CRM була забруднена ручним вводом: менеджери роками кидали значення в неправильні поля, тому система не розрізняла нормального покупця, компанію, нотатку, тестовий запис або сміттєву картку
•Покупці дублювались: один і той самий контакт міг мати багато карток через різні написання імені, телефону, компанії або каналу звернення
•Назви були неконсистентні: ФОП, ТОВ, ГО, БФ, військові частини, державні установи й приватні компанії були записані у різному регістрі, з різними лапками, пробілами, скороченнями й помилками
•Нотатки жили не там, де треба: у полі імені траплялись службові коментарі, уточнення менеджера, джерела звернення або шматки опису замовлення
•Автоматична чистка була небезпечною: простий скрипт міг би стерти корисну історію, злити різних людей або зламати прив'язку до замовлень
3. Поставлені завдання
•Вивантажити CRM-дані через API і сформувати локальний audit snapshot
•Знайти дублікати покупців, порожні картки, тестові записи, “невідомих” клієнтів і записи без достатніх контактних ознак
•Побудувати правила, які відрізняють фізичну особу, компанію, ФОП, військову частину, благодійний фонд, громадську організацію та службову нотатку
•Сформувати канон написання назв: регістр, лапки, скорочення, пробіли, структура “контакт + компанія”
•Підготувати dry-run перед будь-якими записами в CRM
•Відділити safe automation від ручного review, щоб сумнівні записи не змінювались без людини
•Дати команді зрозумілий стандарт, як заповнювати CRM після чистки
4. Рішення та хід роботи
CRM Audit & Data Snapshot
•Через API витягнуто покупців, картки, контакти, компанії, телефони, замовлення і службові поля
•Дані збережено локально у JSON/CSV artifacts, щоб аналіз можна було повторювати без постійних небезпечних live-запитів
•Побудовано окремі перевірки для exact duplicates, fuzzy duplicates, phone duplicates, empty cards, missing contacts, weird names, caps names, transliteration і spam-like records
•Логіка аналізу не покладалась на один критерій. Телефон, ім'я, компанія, кількість замовлень і якість поля розглядалися разом
Canon For Buyers, Contacts & Companies
•Спроєктовано єдиний канон для buyer profile: хто є покупцем, хто є контактною особою, що є компанією, а що має бути нотаткою
•Для компаній описано правила скорочень і форматування: ФОП, ТОВ, ПП, ПрАТ, АТ, ГО, БФ, БО, державні установи, військові частини
•Вирівняно правила лапок: де назва має бути в лапках, а де лапки тільки створюють шум
•Окремо оброблено військові частини та організації, де неправильний пробіл або регістр ламав пошук і групування
•Для нотаток, які менеджери писали в поле імені, підготовлено правила перенесення в правильний контекст без втрати змісту
Duplicate Consolidation & Safe Merge Plan
•Live API audit показав 6,662 buyer records, 6,305 pipeline cards, 690 companies і 6 CRM pipelines
•На рівні pipeline cards виявлено 372 duplicate phone groups, які покривали 1,043 картки
•Найбільший duplicate cluster мав 28 карток на один контактний ключ
•Додатково знайдено 1,533 картки без телефону контакта, 2,808 карток без імені контакта, 77 buyer records із legal/company markers у полі імені та 163 компанії в all-caps форматі
•Це підтвердило головну проблему: база була не просто “трохи брудна”, а системно не мала дисципліни полів і стабільної моделі buyer/contact/company
Manual Review Instead Of Blind Automation
•Сумнівні записи не змінювались автоматично. Для них формувався manual review list із причиною, чому запис не можна безпечно обробити скриптом
•Записи без телефону, без замовлень або з короткими/підозрілими іменами виносились окремо
•Для компаній із неоднозначною назвою генерувався proposed change report: старе значення, нове значення, логіка зміни
•Менеджери отримували не магічний “ми щось почистили”, а прозору таблицю рішень і правил
Execution & Guardrails
•Скрипти писались як повторювані кроки: audit, dry-run, report, review, safe update, verification
•Для API-змін використовувались точкові updates, а не масова неконтрольована перезаписка
•Після змін перевірялись втрачені імена, залишкові дублікати, buyer links, company links, shipping names і картки, які могли бути зачеплені помилково
•Логіка була не “видалити сміття”, а “зберегти комерційно важливу історію і прибрати хаос, який заважає продавати”
5. Що отримав клієнт
•CRM перестала бути набором випадково заповнених карток і отримала зрозумілу модель buyer profile
•Команда побачила, скільки саме дублювання, сміття й ручного хаосу сидить у базі
•Було створено канон заповнення CRM: де контакт, де компанія, де нотатка, як писати ФОП/ТОВ/ГО/БФ/ВЧ і як не плодити дублікати
•Дублікати й порожні записи отримали безпечний план обробки з dry-run і manual review
•Менеджери отримали не просто очищену базу, а стандарт, який не дає повернути старий хаос через місяць
•Бізнес отримав чистішу основу для сегментації, повторних продажів, звітності й маркетингових вибірок
6. Технічний результат
Цей кейс був про дисципліну даних. CRM не можна масштабувати, якщо менеджери використовують її як вільну форму для нотаток. Спочатку треба зробити так, щоб кожне поле мало сенс, кожен покупець мав стабільний профіль, а кожна зміна була перевірюваною
Результатом став не один “скрипт чистки”, а контрольований data-cleanup pipeline: audit, classification, canonical rules, dry-run, manual review, safe update і verification. Саме це відрізняє нормальну CRM-гігієну від небезпечної масової правки живої бази
