Where AI Actually Helps in a GTM Workflow
Outcome: you can look at any step in a workflow and say whether it should use AI, a lookup, or a plain filter — before you spend credits finding out.
- Surface
- App and MCP server
- Level
- Intermediate
- Uses
- No actions — decision framework
- Credits
- 0
- Prerequisite
- SyncGTM 101, or a table you already run
The test
Use AI where the alternative is a person reading something.
That is the entire rule. Everything below is a consequence of it.
If a value can be looked up, look it up — a provider returns the headcount faster, cheaper and more accurately than a model estimating it. If a value can be derived with a filter, filter it. AI earns its cost only where the input is unstructured and a human would otherwise have to interpret it.
Where it pays
Four places, one per stage of the framework:
| Stage | AI job | Why a lookup cannot do it |
|---|---|---|
| Find | Describing an ICP loosely and finding accounts that resemble it | ”Companies like our best customers” is not a filter until something interprets it |
| Research | Answering an open question from whatever page holds the answer | The answer’s location is not known in advance |
| Enrich | Turning free text into a fixed value — a category, a tier, a yes/no | The input is prose; the output needs to be filterable |
| Outreach | Writing a sentence that uses a fact from the row | The fact is different on every row |
The Enrich row is the one teams underuse. Classification is the cheapest reliable AI job there is: the input is already on the row, the output is one of five known values, and correctness is easy to spot-check. Lessons 11 and 12 build it.
The test does not change with the surface. In a table you decide it per column; through the MCP server you decide it per step of a chain, and the model does the assembling. Lesson 04 covers that shift.
Where it does not pay
Facts a provider already has
Headcount, funding, tech stack, job listings. Asking a model is slower, costs more and is sometimes wrong in ways you cannot detect. Use enrichment actions.
Anything a filter can decide
“Employees over 50” is a filter. Routing it through a model adds cost and a failure mode, and buys nothing.
Questions with no public answer
A model asked something unanswerable rarely returns nothing. It returns a guess in the same confident format as a real answer, and that is worse than an empty cell.
Volume you have not sampled
Any AI step run across 500 rows before you have read five outputs. The output shape is what breaks, and it breaks identically on every row.
The cost ordering
Every stage in a table costs more per row than the one before. AI steps sit near the top, and generated copy sits at the very top.
| Step type | Relative cost | Put it |
|---|---|---|
| Filter on existing column | Free | First |
| Database enrichment | Low | Early |
| Scrape a known page | Low to medium | Early |
| AI research on an open question | Medium to high | After filtering |
| AI classification of existing text | Low to medium | After the text exists |
| Generated outreach copy | Highest | Last, on survivors only |
Build in that order and every row reaching an expensive column has already survived a cheap one. Build in any other order and you pay full price for rows you were always going to drop.
Lesson 03 turns this into a checklist you can run against an existing table. Most tables built without it have at least one expensive column sitting above a filter that would have cut half the rows.
A worked decision
Say you want to know whether an account sells to enterprise.
- Wrong: an AI research agent asking “do they sell to enterprise?” on all 800 rows. Highest cost, and the answer is a judgment call the model makes differently each time.
- Better: filter on headcount first, cutting to 300. Then scrape their pricing page — a known location — for the presence of a “contact sales” tier. Then classify that scraped text into
enterprise/self-serve/both.
Same answer, a third of the rows, cheaper steps, and every stage checkable. The AI step is doing the one job only AI can do: turning a page of prose into one of three values.
Check your work
Take a table you already run and answer:
- Which columns use AI for something a provider could have returned?
- Is your cheapest disqualifying filter above or below your most expensive column?
- For each AI column — could you tell, by looking, if it silently started returning wrong answers?
The third question is the one that catches people. If the answer is no, lesson 16 covers making failures visible.
Where this breaks
AI steps fail quietly. A provider lookup that fails returns an empty cell you can filter for; a model that fails returns fluent text in the right shape. Never ship an AI column without a checkable constraint on its output — a fixed set of allowed values, a required citation, or a “return NONE if not found” instruction you actually test by running it on a row where the answer does not exist.
Further automation
The classification and scoring patterns from lessons 11 to 13 are the ones worth saving as Templates — they generalize across segments in a way that research prompts usually do not.
On the MCP side the equivalent is a skill file: a chain that already passes this test, scoped and capped, triggered by one command. Check GTM agents before building your own.
Next lesson
02 — The AI toolkit in Sync GTM, mapping each AI feature to the job it is actually good at.
Reference for this lesson: AI Agents, Actions, Credits, MCP prompting guide.