Turning CRM Chaos into Operational Trust

At doxy.me, I became the de facto owner of data hygiene across customer and revenue systems during a five-year period of rapid growth, tool expansion, and constant operational change. Our CRM and customer data across Intercom, HubSpot, Stripe, Segment, Tray.io, Snowflake, Sigma, and internal product tables were frequently polluted by duplicate records, incorrect attributes, broken integrations, and unclear ownership.

The visible symptoms were serious: wrong emails, degraded customer segments, incorrect routing, unreliable campaign targeting, inaccurate billing/subscription data, duplicate Stripe values in Intercom, weakened churn and upgrade flows, and reduced trust in platform-level reports and dashboards. Leadership knew dirty data was a recurring issue, but the root causes were difficult to isolate because the problems crossed BI, engineering, CRM configuration, product events, third-party integrations, and manual process changes.

For the first several years, I actively patched and repaired bad data so CS, CSM, marketing, and revenue workflows could continue operating. I learned SQL, improved my Python and JavaScript, queried Snowflake directly, built analysis tables in Sigma, exported datasets for stakeholders, and used Python/API update loops to clean records at scale. I cleaned up hundreds of thousands of duplicate records, including approximately 250,000 duplicate Intercom contact records caused by Segment-to-Intercom identity and API-versioning issues. I also resolved duplicate data caused by call center integrations, including roughly 20,000 affected users, and helped create Tray.io automations to merge call center leads with actual user records.

Over time, my work shifted from cleanup to root-cause resolution. I traced polluted data back to its source by fingerprinting records using fields such as user ID, email, Intercom ID, Stripe values, signup data, timestamps, and platform-specific attributes. I filed 40+ Jira tickets for data fixes, many of which included SQL evidence, diagrams, acceptance criteria, data mappings, cleanup plans, and QA steps. In several cases, I did the discovery and technical legwork so BI, data engineering, and product engineering could implement fixes with minimal ambiguity.

In the final year, as part of the founding Revenue Operations team, we moved from reactive cleanup to a more mature data governance model. We documented data sources, clarified who had access to change them, locked down write access across critical platforms, defined required fields and naming conventions, created import and escalation processes, and established clearer ownership of customer and revenue data. I contributed heavily to this maturity phase through documentation, Lucidchart diagrams, stakeholder communication, QA, process enforcement, and cross-functional coordination.

I also built technical solutions where gaps existed. I wrote Node.js webhook listener code for Userpilot and Intercom event ingestion, then worked with BI and engineering to route those events through Segment into Snowflake. This gave RevOps far better visibility into in-app behavior and Intercom activity than the native integrations allowed, especially because Segment’s Intercom integration relied on older API behavior and lacked many newer Intercom 2.x properties. These pipelines helped support robust customer segmentation and more complete RevOps dashboards.

The larger lesson I learned was that platforms are rarely “the problem” by themselves. Platforms are passive; the real issue is usually what is being fed into them, who has permission to change data, whether source-of-truth rules are clear, and whether the organization has enough governance to keep pace with growth. My role was to translate messy operational symptoms into technical root causes, then build enough process, documentation, cleanup tooling, and cross-functional alignment to make the systems trustworthy.