Finding 44K members missing from the CRM
From my résumé Figures from my résumé; examples are made up
Helped move the organization’s CRM to EveryAction, then traced a membership count that disagreed by about 44K people to a sync that had been switched off.
- Status
- My job at EDF · no employer data shown
- Relevant to
- CRM and RevOps, Data engineering
Results · Figures from my résumé; examples are made up
- From my résuméFrom my résumé, for my job at Environmental Defense Fund. The records, queries and internal figures behind it stay private.people missing from the CRM’s member count, traced to one disabled syncFrom my résumé
- From my résuméFrom my résumé, for my job at Environmental Defense Fund. The records, queries and internal figures behind it stay private.members by engagement, against ~68K in the CRMFrom my résumé
The problem
Membership counted from engagement came to about 112K people, while the CRM said about 68K. Both numbers fed reporting, and nobody could say which was right or why they differed.
My role
I helped move the CRM to EveryAction, working on data integration, Snowflake reporting and data governance across teams. On the membership gap, I traced the cause, quantified the impact and set priorities for the fix.
How it works
1.Define
Write down what counts as a member in each system, including the date window.
2.Count
Count members in each system with its own definition.
3.Join
Match people across systems and sort every person into: in both, only in one, or in the other.
4.Trace
Follow the people missing from the CRM back through the pipeline to where their records stopped flowing.
5.Prioritize
Quantify the impact and agree the order of fixes with the teams that own the systems.
What I built
- Data integration and Snowflake reporting for the move to EveryAction, with data governance across teams.
- A person-level reconciliation between engagement-based membership and the CRM’s count.
- The root cause: a disabled Adestra-to-Salesforce sync, so new members stopped reaching the CRM.
- An impact estimate and a prioritized fix plan.
Decisions and tradeoffs
- Reconcile people, not totals
- Two totals can match while the people inside them differ. Sorting every person into in-both, only-here or only-there shows where the gap really is.
- Agree the definition before arguing about the number
- Both counts were right by their own definitions. Writing the definitions down first turned an argument about numbers into a question about data flow.
Challenges
- Each count was correct under its own definition, so the first step was separating definition differences from missing data.
- The cause wasn’t in either system’s reporting but in the connection between them, so the trace had to follow records across systems.
Validation
- The gap was explained person by person, so the size of the fix could be checked against the people it should bring back.
Limitations
- Described without employer data: no records, queries or system internals.
Why it matters for the job
Most RevOps and data roles spend real time on exactly this: two systems that disagree, a migration, and a sync that quietly broke. Finding the root cause and getting it fixed is the job.
Stack
Snowflake, SQL, EveryAction/VAN, Salesforce NPSP, Adestra
Related work
- Finding duplicate people in a 1.2M-record CRM
My job at EDF · no employer data shown
- Choosing the right phone number for every supporter
My job at EDF · no employer data shown
- Measuring what new supporters do next
My job at EDF · no employer data shown