Should you fix your CRM before building AI GTM workflows?
The answer is a sequence, not a side. Fix the fields the first workflow reads, ship the workflow, and let it expose the next fields worth fixing. A full cleanup first is the Foundation-First trap.
[ key takeaways ]
- Six CRM columns all named champion with none authoritative is what one audit found, and our working explanation, a hypothesis, is that no standard existed, so no decision violated one.
- A full cleanup before any AI work is the Foundation-First trap: its documented cost is no visible wins for 60 to 90 days, which is what kills the plan.
- The working rule is one authoritative field per concept that the first workflow reads, then ship, then let the workflow expose the next fields worth fixing.
- The cleanup and the AI build are one loop, and the teams that run them that way get both.
Should you fix your CRM before building AI GTM workflows?
Fix the fields the first workflow reads, ship the workflow, then let production expose the next fields worth fixing. That sequence is the whole answer, because the two projects the question usually offers, a full cleanup or a build on the CRM as it stands, each fail on their own. The rule underneath is that before a workflow reads a concept, that concept needs one authoritative field.
What does the CRM behind this question look like?
The examples below are from our own audits, reduced to mechanism so that no company is identifiable.
In one audit we counted six columns whose names all meant champion, added by different teams in different years for different tools, none marked authoritative, so the reports, workflows and reps that needed the concept each picked a column, and picked differently. In the same class of engagement we find lead scoring fields still on the records while the edit history shows the model behind them dead for years, with no replacement and no note telling a new hire to ignore the number. We find lifecycle states that only move forward, so a churned account cannot become a prospect again and the reactivation list cannot be built. In another audit, reported pipeline read an order of magnitude larger than the number the team was actually managing, and it took stripping renewals out of the view to see it, so allocation decisions made from that number had inherited the inflation. And we find paid leads landing in a spreadsheet export and aging out there, because the handoff into the CRM had no owner.
Our explanation is a hypothesis: each field was added by a reasonable person solving a real problem that day, and no standard said which field was authoritative, which directions a lifecycle may move, or what counts as pipeline, so no individual decision broke a definition. We reconstruct this from edit histories after the fact, so it does not control for fields added for reasons the history cannot show.
Why does a full CRM cleanup before any AI work fail?
We call this the Foundation-First trap, and it starts from the most responsible-sounding plan in the room: data quality first, automation second. Our sequencing framework, on the how we work page, puts that path's cost at no visible wins for 60 to 90 days, which is what kills it here. The cleanup has no prioritization signal, so effort spreads evenly across hundreds of fields, most of which the first workflow will not read, and the finish line is the word clean, which has no test, so the project ends by exhaustion rather than by completion.
Clean is relative to a read: until something consumes a field, cleanliness has no definition. The first workflow settles that by existing, because it names the exact fields, the exact values they must hold, and the exact moment a bad value causes visible damage.
Why does skipping the CRM entirely fail too?
The opposite failure is quieter and does more damage, because the workflow appears to work. A workflow that needs the champion and finds six candidate fields does not stop. It picks one, without the context a rep carries about which column their team maintains, and at volume it sends the follow-up to a contact who left last year, congratulates the wrong person, or routes the account to a rep who has not touched it. The sum of small errors is a team that quietly stops trusting the system and goes back to working from memory while the tooling spend continues.
The dead scoring field shows where this road ends. The observation, from the audits above, is a model dead for years and still scoring records. Our explanation is a hypothesis: scoring models die when the people working the leads did not help build them, so a rep treats the score as someone else's guess and routes around it on instinct, usually rightly. That does not control for models that died because the data behind them changed or the tool that computed them was retired. It is still why the scoring rule is social before technical: the reps define the tiers, in their own words, before the build starts.
How do you decide which fields to fix first?
The workflow decides, so choose the first workflow before touching a field. Choose it where leads are visibly dying this month. In the audits above that was the spreadsheet, because routing those leads into the CRM is the fix and the workflow at once. Then walk the reads: list every field the workflow will read or write, give each concept one authoritative field, and leave the fields not on the list alone, on purpose, in writing, so the cleanup instinct has an official place to stop.
[ fig. 01 · decide by symptom ]
What is minimum viable hygiene?
Minimum viable hygiene is the set of field conditions the first workflow needs and nothing beyond it, and each item comes with a test a non-admin can run in five minutes.
[ fig. 02 · minimum viable hygiene ]
The test. Ask three people which field holds the champion and get one answer.
The test. Nothing writes to it any more, and nothing new is allowed to read it.
The test. A churned account can become a prospect again without an admin ticket.
The test. The pipeline number the workflow reads is one the team would defend in a forecast review.
The test. The spreadsheet stops receiving rows, and its old rows are imported or archived.
The test. A rep can recite the tiers from memory, because the reps wrote them.
The stopping rule. Any item that names a field the first workflow never reads belongs to a later cycle, however untidy the field is. Untidy and unread is a stable, harmless condition.
What happens after the first workflow ships?
Production becomes the audit. The first workflow exposes, in order of actual damage, the fields worth fixing next, and each finding arrives attached to a lead that mis-routed this week. The routing workflow runs into the one-way lifecycle the day someone asks it for a reactivation list. Each collision names one concept, that concept gets its authoritative field, and the loop repeats. After a few cycles the CRM has received most of the cleanup the Foundation-First plan promised, in an order set by usage, with a working capability to show for each cycle. The fields, definitions and workflows live in the client's own CRM and run without us, which is the structure described in how we work.
So, should you fix your CRM before building AI GTM workflows? Only the fields the first workflow reads, and only as part of shipping it. The cleanup and the AI build are one loop, and the teams that run them that way get both.