1. Kontekst Projektu
Klientem był zespół sprzedaży, który długo pracował w CRM bez twardej dyscypliny danych. System miał przechowywać buyerów, kontakty, firmy, zamówienia i historię komunikacji, ale z czasem stał się bazą, której managerowie nie mogli już w pełni ufać
Problemem nie był sam CRM. Problemem było to, jak ludzie używali pól: imię trafiało do firmy, firma do imienia, notatka do kontaktu, specjalne typy organizacji miały losowe formaty, a jeden buyer potrafił istnieć w wielu kartach naraz
Moja rola polegała na przywróceniu porządku bez ryzykownego masowego cleanupu. Trzeba było wyciągnąć realny stan bazy, zaprojektować reguły normalizacji, pokazać dry-run, oddzielić bezpieczną automatyzację od manual review i dać zespołowi jasny canon pracy z CRM
2. Stan Początkowy
•CRM był zabrudzony ręcznym inputem: managerowie latami wrzucali wartości do złych pól, więc system mieszał buyerów, firmy, notatki, testowe rekordy i śmieciowe kartki
•Buyerzy się duplikowali: ten sam kontakt mógł mieć wiele kart przez różne zapisy imienia, telefonu, firmy lub źródła
•Nazwy były niespójne: firmy, fundacje, organizacje, instytucje i inne typy rekordów były zapisane różnym case'em, cudzysłowami, spacjami, skrótami i literówkami
•Notatki mieszkały w złych polach: w polu imienia pojawiały się komentarze managera, źródła zgłoszenia albo fragmenty opisu zamówienia
•Ślepa automatyzacja była niebezpieczna: prosty skrypt mógł usunąć przydatną historię, połączyć różne osoby albo zerwać powiązania z zamówieniami
3. Zakres
•Wyeksportować dane CRM przez API i zbudować lokalny audit snapshot
•Wykryć buyer duplicates, puste kartki, test records, unknown clients i rekordy bez wystarczających danych kontaktowych
•Zbudować reguły rozróżniające osobę, firmę, specjalny typ organizacji i notatkę operacyjną
•Zdefiniować naming canon: case, cudzysłowy, skróty, spacje i strukturę contact plus company
•Przygotować dry-run przed jakimikolwiek zapisami w live CRM
•Oddzielić safe automation od manual review, żeby wątpliwe rekordy nie były zmieniane bez człowieka
•Dać zespołowi jasny standard pracy z danymi po cleanupie
4. Rozwiązanie
CRM Audit & Data Snapshot
•Przez API pobrano buyerów, kartki, kontakty, firmy, telefony, zamówienia i pola systemowe
•Dane zapisano w lokalnych JSON/CSV artifacts, żeby analizę dało się powtarzać bez ciągłych ryzykownych live requestów
•Powstały osobne checki dla exact duplicates, fuzzy duplicates, phone duplicates, empty cards, missing contacts, weird names, all-caps names, transliteration i spam-like records
•Analiza nie opierała się na jednym kryterium. Telefon, imię, firma, liczba zamówień i jakość pola były oceniane razem
Canon For Buyers, Contacts & Companies
•Zaprojektowano jeden canon dla buyer profile: kto jest buyerem, kto contact person, co jest firmą, a co powinno stać się notatką
•Dla firm i organizacji opisano zasady skrótów, formatowania, cudzysłowów i wielkości liter
•Uporządkowano reguły cudzysłowów: gdzie nazwa ma je mieć, a gdzie dodają tylko szum
•Specjalne formaty organizacyjne potraktowano osobno, bo jedna zła spacja lub case potrafiła zepsuć search i grupowanie
•Dla notatek wpisanych przez managerów w pole imienia przygotowano reguły przeniesienia do właściwego kontekstu bez utraty treści
Duplicate Consolidation & Safe Merge Plan
•Live API audit objął 6,662 buyer records, 6,305 pipeline cards, 690 companies i 6 CRM pipelines
•Na poziomie pipeline cards wykryto 372 duplicate phone groups, obejmujące 1,043 cards
•Największy duplicate cluster miał 28 kart dla jednego contact key
•Audit pokazał też 1,533 cards without contact phone, 2,808 cards without contact name, 77 buyer records z legal/company markers w polu imienia oraz 163 all-caps company records
•To potwierdziło sedno problemu: baza nie była “trochę brudna”, tylko nie miała dyscypliny pól i stabilnego modelu buyer/contact/company
Manual Review Instead Of Blind Automation
•Wątpliwe rekordy nie były zmieniane automatycznie. Trafiały do manual review list z jasnym powodem
•Rekordy bez telefonu, bez zamówień albo z podejrzanie krótkim imieniem separowano osobno
•Dla niejednoznacznych firm generowano proposed-change report: stara wartość, nowa wartość i logika zmiany
•Zespół dostał transparentną tabelę decyzji, a nie efekt w stylu “coś wyczyściliśmy”
Execution & Guardrails
•Skrypty były ułożone jako powtarzalne kroki: audit, dry-run, report, review, safe update, verification
•Zapisy do CRM były punktowe, bez masowych niekontrolowanych overwrite'ów
•Po zmianach sprawdzano lost names, remaining duplicates, buyer links, company links, shipping names i rekordy, które mogły zostać przypadkowo naruszone
•Logika nie brzmiała “usunąć śmieci”, tylko “zachować historię handlową i usunąć chaos, który przeszkadza sprzedawać”
5. Efekt
•CRM przestał być zbiorem przypadkowo wypełnionych kart i dostał czytelny model buyer profile
•Zespół zobaczył realną skalę duplikatów, śmieci i ręcznego chaosu w bazie
•Powstał canon uzupełniania CRM: gdzie kontakt, gdzie firma, gdzie notatka i jak nie produkować nowych duplikatów
•Duplikaty i puste rekordy dostały bezpieczny plan obróbki z dry-run i manual review
•Managerowie dostali nie tylko czystszą bazę, ale standard, który nie pozwala wrócić temu samemu chaosowi za miesiąc
•Biznes dostał czystszą podstawę pod segmentację, repeat sales, reporting i marketing selections
6. Rezultat Techniczny
Ten case był o data discipline. CRM nie da się skalować, jeśli managerowie używają go jak luźnego notatnika. Najpierw każde pole musi mieć znaczenie, każdy buyer stabilny profil, a każda zmiana musi być weryfikowalna
Rezultatem nie był jeden cleanup script, ale kontrolowany data-cleanup pipeline: audit, classification, canonical rules, dry-run, manual review, safe update i verification. To różnica między dobrą CRM hygiene a niebezpieczną masową edycją żywej bazy
