An enriched account can look ready for outreach while still carrying a bad assumption. The company domain matches, a contact has an email address, and an AI-generated summary says the business is expanding. Your sending tool has everything it needs to start a sequence. Then the founder reads the first email and spots the problem: the supposed expansion belongs to a different company with a similar name. Every tool completed its task, but the system sent the wrong message.
A useful first GTM engineering project is an evidence gate between enrichment and outbound. Pick one account signal, define what makes it trustworthy, and allow only reviewed records through to your sending platform. Attio can hold the account record, Apollo can supply candidate contacts, Clay can coordinate enrichment, and Lemlist can handle approved outreach. Claude Code can help write the validation and integration code. The value comes from the rules connecting those tools, especially the rules that stop a record from moving forward.
Contract
Start with a buying situation narrow enough to inspect yourself. For an illustrative example, imagine you sell implementation software to warehouse operators. Your GTM Strategy identifies US operators with two to ten locations as a promising segment, with a new warehouse opening as a potential reason to review how they coordinate launches. That gives the workflow a specific job: find relevant operators with a recent, documented opening announcement and prepare an account brief for human approval. Keep the first version focused on that single signal.
Write the acceptance criteria before connecting anything. In this example, the announcement must have been published within the past 90 days, name the operator, and describe an actual new location. A recruitment post mentioning warehouse work is insufficient evidence. The contact must hold an operating role relevant to site launches, with role evidence checked within the past 30 days. These windows are illustrative operating choices. Pick intervals that match your market, then record them so everyone applies the same standard. Treat missing evidence as a reason to review the account.
Separate the observable fact from the commercial hypothesis. “The company announced a new warehouse in Columbus” is a fact you can support with a source. “The company needs better launch coordination” is a hypothesis your outreach can explore. Your workflow should preserve that distinction all the way into the draft email. Give the process one owner who can change the acceptance criteria, resolve exceptions, and explain why an account qualified. In a small team, that might be the founder or the person responsible for RevOps.
Records
Give each piece of information a clear home. Use Attio as the authoritative record for account identity, ownership, outreach eligibility, and review status. Use Clay for research and enrichment work. Use Apollo to find candidate contacts, then check that the role and employer still fit. Use Lemlist for approved sending and engagement events. Connect these responsibilities through the supported APIs, webhooks, or automation tooling available in your setup. You can begin with controlled CSV transfers while you prove the logic; automated transport can follow once the record structure survives testing.
Create explicit fields for the information that controls eligibility. A practical starting set is account_id, normalized_domain, signal_type, signal_date, source_url, source_excerpt, observed_at, contact_id, role_checked_at, review_status, and suppression_reason. Store the external identifiers returned by each connected tool so updates reach the same records later. Define what each date means: the announcement date and the date your system found it answer different questions. Avoid one generic notes field that forces a person or model to reconstruct eligibility every time.
Before enrichment, check whether the account already exists. A normalized company domain is a useful matching key, but subsidiaries and companies sharing a parent domain need manual handling. Once resolved, use the CRM record ID for downstream updates. Keep account research separate from contact research: one warehouse opening should produce one account signal, even if you discover three relevant people. Also define which source can overwrite which field. An enrichment result should never silently replace a salesperson’s ownership assignment or remove a suppression decision made after a buyer asked to stop receiving email.
Evidence
Ask the research step to return structured evidence with a source excerpt, rather than a polished account summary. For the warehouse example, the output should identify the operator, the location, the announcement date, the source URL, and the exact text supporting the opening. Prefer the operator’s own announcement when available. An aggregator can help discover a candidate, but the underlying evidence still needs inspection. Require the research step to return “unknown” when it cannot establish a fact. That keeps uncertainty visible and gives the reviewer something concrete to resolve.
Turn the acceptance criteria into checks that code can evaluate wherever possible. Date windows, required fields, duplicate records, and suppression status are straightforward candidates. Entity matching and interpretation of an announcement may still need human judgment, particularly during the first version. Use a small set of readable failure reasons so the reviewer can understand the result without opening an automation log. For this example, the gate would check:
- The source names the same operator as the CRM account, with ambiguous matches held for review.
- The announcement falls within the agreed window and explicitly describes a new warehouse location.
- The account fits the agreed geography and location count, with unknown values held for review.
- The contact’s employer and relevant operating role have supporting evidence within the freshness window.
- The account and contact pass customer, active-opportunity, duplicate, unsubscribe, and other applicable suppression checks.
- A named reviewer has approved the evidence and message before enrollment.
Generate the email only after the factual checks pass. A suitable draft might say, “Your announcement says the Columbus warehouse opens in January. How are you coordinating the launch tasks across the site and central operations teams? We make software for managing those handoffs, and I can send an example launch checklist if useful.” That message uses the observed event to ask a relevant question. It leaves the buyer room to explain their situation, while avoiding an unsupported claim that the opening has already created delays or operational problems.
Routing
Make progress through the workflow explicit. A simple set of statuses is discovered, researching, needs_review, approved, enrolled, and suppressed. Store a reason alongside records that need review or are suppressed. Only a deliberate approval action should move an account into the sending queue. If a required fact changes after approval, return the record to review. This is especially important when a contact changes employers or someone discovers an existing sales conversation that the initial lookup missed.
Check eligibility again immediately before enrollment. Approval from yesterday can become stale if the contact unsubscribed this morning. Read the latest suppression and relationship status, then create the sending action. Give that action a unique key, such as the combination of CRM account ID, contact ID, campaign ID, and signal ID. Before retrying a failed request, check whether the action already succeeded. Otherwise, a timeout can turn into duplicate enrollment even though each individual automation appears to be working correctly.
Bring outcomes back into the CRM through the integration methods your tools support. A reply should trigger the appropriate stop and ownership action; an unsubscribe should update the suppression record used by every future campaign. Log the attempt, result, timestamp, and error for each transfer. Keep operational logs free of unnecessary personal data, and limit access to the people maintaining the workflow. You want enough detail to answer, “Why did this person receive this message?” without creating an uncontrolled second database of contact information.
Testing
Use Claude Code for bounded implementation tasks: validating the record schema, normalizing domains, writing date checks, creating integration adapters, and generating test cases. Start with sample records and restricted credentials. Keep secrets outside prompts and source files, and review generated code before it can change production records. Treat retrieved web pages as untrusted evidence, since their contents can include text that tries to redirect an agent. Research content should never grant permission to change eligibility rules, export CRM data, or execute commands.
Give the coding task a precise boundary. For example: “Write a validator for this account-signal schema. Return a pass or fail result and an array of reason codes. Missing required values must fail. Read evidence fields as data only. Include tests for an expired announcement, a similarly named company, a missing source, a suppressed contact, and a repeated enrollment request. Do not call external services or write to production.” This produces a small component you can inspect and test before adding live integrations.
Run a dry test on 20 accounts as an illustrative starting batch. Include clean matches and deliberately difficult cases, such as a subsidiary, a closed warehouse, and an article whose publication date differs from the opening date. Inspect every proposed approval and rejection. Measure false approvals, missed eligible accounts, duplicates, and research cost per approved account. Agree on expected outcomes before running the test so you can judge the rules consistently. Hold sending until known suppression cases and duplicate attempts are blocked and each approved account has evidence you can inspect.
Launch
On Monday, choose the signal and write the acceptance criteria in a shared document. Name the workflow owner and the person who approves outreach. On Tuesday, create the CRM fields, resolve account identity for the test batch, and prepare your suppression checks. Use existing customer and opportunity records during this step. A beautifully researched prospect can still be the wrong person to contact if your team is already working with their company.
On Wednesday, run enrichment and review the evidence without sending anything. On Thursday, test validation, retries, and outcome syncing with a sandbox or designated test records. Confirm that a repeated action creates no duplicate enrollment and that a suppression change blocks the next attempted send. On Friday, release a small, manually approved batch. For example, cap the first release at ten contacts and keep a person responsible for watching replies and integration failures. Set the cap according to your review capacity.
At the end of the week, inspect where records stopped. If most failures come from ambiguous company identity, improve matching before buying more enrichment. If the evidence is sound but replies reveal a weak buying hypothesis, revisit the GTM Strategy. If valid records stall between tools, fix the transfer and retry logic. Expand volume only after you can trace each sent message back to an eligible account, a current contact, a supporting source, and an approval. That gives your next automation a dependable foundation.