How to Do GTM Engineering

Your GTM motion is not under-staffed. It is under-engineered. When a team drowns in manual research, slow campaigns, and data cleaning, the fix is not more headcount; it is a system that does the work. That system is what GTM engineering builds: revenue engines that run on data, AI, and automation. Clay coined the role in 2023, and the method behind it is a loop. Find the highest-impact bottleneck, build the workflow in Clay, test it on a small batch, schedule the winner, and move to the next constraint. This is how to run that loop, step by step. (For the discipline itself, see the companion guide on GTM engineering.)

Step one: Pick the bottleneck that costs you the most

A GTM engineering system starts with a constraint, not a tool. A GTM engineer builds across every revenue function: RevOps, sales, marketing, inbound, and outbound. That cross-functional view is what lets them see where time is leaking. The work that deserves a workflow is the work a person repeats every day, that gates revenue, and that follows a rule you can write down. The fastest way to waste a month is to automate the task that was already cheap.

This is how Clay's own GTM engineering team works, and how Lovable runs it. At Lovable, the AI Ops engineer who builds the company's GTM workflows sits across the whole company on purpose. When he spots a bottleneck, he goes into Clay and tests whether a workflow fixes it. The sequencing matters: find the constraint first, then build.

Score your candidate bottlenecks before you build anything. The selector below ranks a workflow idea on the three things that decide whether it is worth engineering.

The pattern in the scores is the lesson. The work to engineer first is high-frequency, revenue-gating, and rule-bound at the same time. A one-off creative task scores low on all three and should stay manual.

Step two: Map the data and the trigger before you open a table

Every GTM workflow is a function: a state change fires it, data gets gathered, a decision gets made, and a record moves somewhere. Clay's GTM engineering team builds its plays around state changes, the moments when something about an account or a lead changes, and so should yours. Write those four things down before you build, because the build is just wiring them together.

Start with the trigger. A trigger is the state change that should kick the workflow off. An inbound form submission, a new account in the CRM, a target list you drop in for an outbound motion, or a recurring schedule are the four that cover most cases. In Clay, each maps to a specific source. An inbound trigger arrives through a webhook into a table. A CRM trigger comes from a Salesforce or HubSpot source. A list trigger is a CSV import or a Find Companies search, and a recurring trigger is a scheduled source or scheduled columns.

Then map the data path: what the trigger gives you, what you need to add, and where the finished record has to land. For an inbound qualification workflow the input is a name, an email, and a company. The data you add is firmographics, a fit score, and a research brief. The destination is the right rep, with the brief attached. Lovable runs exactly this: every company that reaches out gets researched in real time and matched to the best-fit rep with a pre-built brief.

Keep this map to one page. It is the spec for everything in the next steps.

Step three: Build the core workflow (source, enrich, research, verify, route)

One GTM workflow does the work of a team because it processes a whole batch through the same five moves at once. You build it once in a Clay table, where each column is a step and every row is a record moving through them in parallel.

The moves are always the same shape. Pull the records in, fill the firmographics with a waterfall, run AI research for the judgment work, verify what you will act on, then route the result.

Now the mechanics of each move, because the names matter and the wrong name builds the wrong thing.

• Source. Add the records with the trigger you mapped. Find Companies or Find People for cold lists, a Salesforce or HubSpot source for CRM records, a CSV import for a list you have, or a webhook for inbound. Find Companies filters on industry, size, revenue brackets, funding, and keywords; Find People filters on title, function, and company attributes.
• Enrich with a waterfall. Add an enrichment, pick the data point (company size, work email, phone), and order a sequence of providers. The waterfall tries them in order and stops at the first that returns a result, so you do not pay multiple providers for the same field. Order providers cheapest-first so the expensive ones only run when the cheap ones miss.
• Research with Claygent. This is the judgment work a list of fields cannot do. Use a Use AI column or a Claygent agent to read the company's own site and write a structured read: what they sell, who they sell to, and why they fit your ICP. Build the agent conversationally with Sculptor, test it free on production data, and deploy it across the table.
• Verify. Validate anything you will act on. For email, an enrichment returns a status of Valid, Invalid, Catch-all, Unknown, or Role-based; act on Valid, hold the rest. Inside a waterfall you can add an optional validation provider; there is no default, so you choose one. Set the validation strategy to Conservative, Balanced, or Aggressive based on how much you want to trust borderline results.
• Route. Score fit with a Formula column, then send each record to its destination. Records that clear the bar go to a rep; the rest go to a self-serve path. Use Send Table Data to move rows between tables, a Salesforce or HubSpot write to update the CRM, or a webhook to Slack to notify a rep. On a Salesforce write, the Update record action keys on the Record ID and the Upsert action keys on an external ID. Clay prevents duplicates by default, and writes cannot be undone. Test against the Salesforce Test Env connection first.

The research step is the one most worth getting right, because a list of fields cannot judge fit. A research prompt that returns a usable brief looks like this:

Two meters track the cost as the batch runs. Actions cover the orchestration, one for each step on each row. Data Credits cover provider results, charged only when a provider returns data. Formatters and formulas spend Actions but no Data Credits.

Step four: Test on a small batch before you scale it

The discipline that separates GTM engineering from a one-off automation is testing small before you spend on the whole list. Run the workflow on 25 to 50 rows first. Read every output by hand. The research brief is where most workflows fail quietly: a prompt that looks fine on three rows starts hallucinating triggers or misreading ICP fit on row forty.

This is the literal method Ludvig runs at Lovable, and it is why a 150-person company can operate like a much larger one: build small, validate, then scale.

Check three things on the small batch. Did the waterfall fill the fields you need, or do you need another provider in the chain? Did Claygent's brief match what you would have written reading the site yourself? Did the routing send the right records to the right place? Fix the prompt and the provider order on 50 rows where a miss costs pennies, not on 5,000 where it costs real money and real rep time.

The auto-playing comparison below shows why the small-batch habit pays for itself.

The race makes the math plain. The test batch is not a delay. It is the cheapest insurance you can buy on a workflow that is about to touch thousands of records.

Step five: Put the working workflow on a schedule

A GTM workflow that only runs when you click it is a manual task with extra steps. The payoff comes from making it run on its own. Once the small batch validates, set the trigger to fire without you.

For an inbound workflow, the webhook already fires on every form submission, so it is live the moment you point your form at the Clay table. For a list or CRM workflow, use a scheduled source to pull new records on a cadence, or scheduled columns to re-run enrichment so fields like headcount, funding, and tech stack stay current. You choose the frequency: daily and weekly on most plans, hourly on Enterprise, for all columns or only the ones you select.

This is where the word engineering earns its place. Clay's own GTM engineering team runs like a product engineering team, with sprints, version control, and release notes, because a scheduled workflow is software: you build it, ship it, and maintain it. You are not running the workflow; you built a system that runs it. Lovable's inbound qualification researches and routes thousands of leads a month on its own, which is what lets each rep carry a larger book and still close at a higher rate.

A scheduled workflow also fails silently if you let it, so build one guardrail in. Add a credit spend limit on the workbook so a runaway batch cannot drain your account, and route any record that fails verification to a review lane instead of straight to a rep.

Step six: Measure the result and decide what to scale or cut

The output of a GTM engineering loop is not a workflow. It is a measured result that tells you what to build next. Before you scale, define the one number the workflow is supposed to move: qualified meetings, response rate, routing accuracy, time-to-first-touch. Then read it against a baseline.

The measurement is what makes the loop a loop. A workflow that moved the number gets scaled to the full volume and left to run. A workflow that did not gets cut or rebuilt, not kept around out of sunk cost. Rippling's growth team treats Clay as its first move on any new idea precisely because the cost of testing is so low that killing a loser is painless.

Once a workflow proves out and runs on its own, you are back at step one with capacity freed up. Pick the next bottleneck and run the loop again. At Clay, the same loop turns internal problems into customer features: a play the GTM team builds to fix its own bottleneck often becomes something customers use. The point of running it is the original question every growth team is asking, how to grow revenue without adding headcount. The system below shows the loop running continuously, which is the actual shape of a GTM engineering practice.

The counter ticking up each lap is the point. Output compounds because every loop hands you back the time to run the next one.

Common failure modes to avoid

Most GTM engineering attempts stall for one of four reasons, and all four are avoidable.

1. Automating the wrong task: a workflow built for a bottleneck that was never expensive saves nothing.
2. Skipping the small-batch test, which lets a broken prompt or a thin provider chain compound across thousands of records before anyone notices.
3. Building a workflow and never scheduling it, which leaves you doing the same manual clicks with more setup overhead.
4. Shipping AI research with no verification step, so unverified emails and hallucinated briefs reach reps and burn the trust that makes anyone use the system at all.

Each one maps back to a step in this guide. Pick the right bottleneck, test small, schedule the winner, and verify before you act. Run that loop and the system gets stronger every pass.