1. Project Overview
The client was a sales team that had used its CRM for a long time without strict data discipline. The system was supposed to store buyers, contacts, companies, orders and communication history, but over time it became a database the managers could no longer fully trust
The issue was not the CRM itself. The issue was how people used the fields: a person name could sit inside the company field, a company could sit inside the name field, a note could be stored as a contact, military-unit records appeared in random formats, business entities had no naming standard, and one buyer could exist across many cards
My role was to restore order without reckless mass cleanup. I had to extract the real state of the database, design normalization rules, show a dry run, separate safe automated changes from manual review and give the team a clear canon for future CRM data entry
2. What The Client Had
•CRM was polluted by manual input: managers had been placing values into wrong fields for years, so the system no longer clearly separated buyers, companies, notes, test records and junk cards
•Buyers were duplicated: the same contact could exist across many cards because of different spelling, phone formats, company names or intake channels
•Names were inconsistent: private entrepreneurs, companies, NGOs, funds, public institutions and special organization types were written with different casing, quotes, spaces, abbreviations and mistakes
•Notes lived in the wrong fields: the name field sometimes contained service comments, manager notes, source hints or fragments of order descriptions
•Blind automation was risky: a simple script could delete useful history, merge different people or break links to orders
3. Scope
•Export CRM data through the API and build a local audit snapshot
•Detect buyer duplicates, empty cards, test records, unknown clients and records without enough contact evidence
•Build rules that distinguish a person, company, private entrepreneur, military unit, charitable fund, NGO and operational note
•Define a naming canon: casing, quotes, abbreviations, spacing and the structure of contact plus company
•Prepare a dry run before any live CRM writes
•Separate safe automation from manual review so questionable records would not be changed without a human decision
•Give the team a clear standard for data entry after cleanup
4. Solution
CRM Audit & Data Snapshot
•Pulled buyers, cards, contacts, companies, phones, orders and service fields through the API
•Saved the data into local JSON/CSV artifacts so analysis could be repeated without constant risky live requests
•Built checks for exact duplicates, fuzzy duplicates, phone duplicates, empty cards, missing contacts, strange names, all-caps names, transliteration and spam-like records
•The analysis did not rely on a single criterion. Phone number, name, company, order count and field quality were evaluated together
Canon For Buyers, Contacts & Companies
•Designed one canon for buyer profiles: who is the buyer, who is the contact person, what belongs to the company field and what should become a note
•Defined rules for organization names and abbreviations: private entrepreneurs, companies, public organizations, funds, public institutions and military-unit style records
•Normalized quote rules: where a company name should have quotes, and where quotes only add noise
•Treated special organization formats separately, because one wrong space or casing difference could break search and grouping
•Prepared rules for moving manager notes out of the name field into the right context without losing meaning
Duplicate Consolidation & Safe Merge Plan
•The live API audit covered 6,662 buyer records, 6,305 pipeline cards, 690 companies and 6 CRM pipelines
•At pipeline-card level, it found 372 duplicate phone groups covering 1,043 cards
•The largest duplicate cluster had 28 cards for one contact key
•The audit also found 1,533 cards without contact phone, 2,808 cards without contact name, 77 buyer records with legal/company markers inside the name field and 163 all-caps company records
•This confirmed the core issue: the database was not merely “a bit dirty”; it lacked field discipline and a stable buyer/contact/company model
Manual Review Instead Of Blind Automation
•Questionable records were not changed automatically. They were moved into a manual review list with a clear reason
•Records without phone numbers, without orders or with suspicious short names were separated
•For ambiguous company names, the system generated a proposed-change report: old value, new value and the logic behind the change
•The team received a transparent decision table, not a vague “we cleaned something” result
Execution & Guardrails
•Scripts were structured as repeatable steps: audit, dry-run, report, review, safe update and verification
•CRM writes were precise updates, not uncontrolled mass overwrites
•After changes, checks looked for lost names, remaining duplicates, buyer links, company links, shipping names and records that could have been affected accidentally
•The logic was not “delete junk”. It was “preserve commercial history and remove the chaos that blocks selling”
5. Outcome
•CRM stopped being a pile of randomly filled cards and received a clear buyer-profile model
•The team saw how much duplication, junk and manual chaos actually existed in the database
•A CRM data-entry canon was created: where the contact goes, where the company goes, where the note goes and how to avoid duplicate profiles
•Duplicates and empty records received a safe processing plan with dry-run and manual review
•Managers received not just a cleaner base, but a standard that prevents the same mess from returning in a month
•The business received a cleaner foundation for segmentation, repeat sales, reporting and marketing selections
6. Technical Result
This case was about data discipline. You cannot scale CRM operations if managers use the system as a free-form notebook. First, every field needs meaning, every buyer needs a stable profile and every change needs to be verifiable
The result was not one cleanup script, but a controlled data-cleanup pipeline: audit, classification, canonical rules, dry-run, manual review, safe update and verification. That is the difference between proper CRM hygiene and dangerous mass editing of a live database
