Overview

Every GTM engineer has a folder of automation scripts that hold their pipeline together. The Clay-to-CRM sync that runs on a cron job. The enrichment script that waterfalls through three data providers. The weekly pipeline report that pulls from Salesforce and dumps a summary into Slack. These scripts are not glamorous, but they are the plumbing that makes modern go-to-market motions work.

The problem is that building and maintaining these scripts consumes a disproportionate amount of time. You spend 30 minutes fighting with an API's pagination logic, another hour debugging a rate limiting edge case, and by the time the script works, you have lost half a day on what should have been straightforward work. Claude Code, Anthropic's terminal-based agentic coding tool, changes this equation. Instead of writing every line yourself, you describe the automation you need, iterate on it conversationally, and let Claude Code handle the implementation details while you focus on the business logic.

This guide walks through the practical workflow of using Claude Code to build, test, debug, and deploy the automation scripts that GTM engineers write every week. Not the theory of AI-assisted coding, but the actual patterns: how to structure your project for maximum leverage, the specific script types that benefit most, and the iteration loops that turn a rough description into production-ready automation.

The CLI Workflow for GTM Engineers

Claude Code lives in your terminal. That matters because GTM automation work already happens in the terminal: running Python scripts, tailing logs, testing API calls with curl, managing virtual environments. Claude Code fits into this existing workflow rather than pulling you into a separate interface.

The Daily Rhythm

A typical session looks like this: you open your terminal, navigate to your automation project directory, and launch Claude Code. It reads your project structure, your CLAUDE.md configuration file, and any recently modified files. From that point, you work conversationally. You describe what you need, Claude Code writes the implementation, you run it, share any errors, and iterate until the script works.

# Start your session in the project root
cd ~/projects/gtm-scripts
claude

# Claude Code reads your project context automatically
# Now describe what you need:
> "Write an enrichment script that takes a CSV of company domains,
  looks up each one in Clearbit, falls back to Apollo if Clearbit
  returns nothing, and outputs the enriched data as a new CSV with
  columns for employee_count, industry, and annual_revenue."

The critical difference between this and pasting requirements into a chat interface is that Claude Code has your entire project as context. It sees your existing API clients, your utility modules, your configuration patterns. When it writes new code, it reuses what you already have rather than starting from scratch.

One-Shot vs. Interactive Mode

Claude Code supports two primary interaction modes. For quick, well-defined tasks, you can pass a prompt directly:

# One-shot for focused tasks
claude "Add retry logic with exponential backoff to the Salesforce
sync in integrations/salesforce_sync.py. Use our existing retry
decorator in utils/retry.py."

For more complex scripts that require back-and-forth, launch an interactive session and build the automation through conversation. This is typically better for new scripts where you are discovering requirements as you go.

Setting Up Project Context

The quality of scripts Claude Code produces correlates directly with the quality of context you provide. For GTM automation projects, this means establishing a clear project structure and a focused CLAUDE.md file that encodes your conventions.

Project Structure That Works

A well-organized project directory gives Claude Code the signals it needs to place new code correctly and follow existing patterns:

gtm-scripts/
├── CLAUDE.md              # Project context and conventions
├── scripts/
│   ├── enrichment/        # Lead and account enrichment scripts
│   │   ├── clearbit_enrich.py
│   │   └── waterfall_enrich.py
│   ├── sync/              # CRM and tool sync scripts
│   │   ├── clay_to_hubspot.py
│   │   └── salesforce_bi_sync.py
│   ├── reporting/         # Analytics and reporting scripts
│   │   ├── weekly_pipeline.py
│   │   └── attribution_report.py
│   └── routing/           # Lead routing and assignment
│       └── territory_router.py
├── integrations/          # Reusable API clients
│   ├── base_client.py
│   ├── hubspot.py
│   ├── salesforce.py
│   ├── clay.py
│   └── slack.py
├── utils/                 # Shared utilities
│   ├── config.py
│   ├── logger.py
│   ├── retry.py
│   └── rate_limiter.py
├── schemas/               # Data models and validation
│   ├── lead.py
│   └── company.py
├── tests/                 # Test files mirroring script structure
│   ├── fixtures/
│   ├── test_enrichment/
│   └── test_sync/
└── config/
    └── .env.example

When you ask Claude Code to "build a new enrichment script that pulls from ZoomInfo," it knows to place it in scripts/enrichment/, use the patterns from existing enrichment scripts, and leverage the base API client in integrations/.

Writing an Effective CLAUDE.md

Your CLAUDE.md is the single most impactful investment you can make in Claude Code productivity. Keep it concise and focused on information that applies across all tasks. Research suggests AI models handle roughly 150-200 discrete instructions reliably, so quality matters more than comprehensiveness.

# GTM Automation Scripts

## What This Project Does
Python automation scripts for lead enrichment, CRM sync,
reporting, and lead routing. Integrates with Clay, HubSpot,
Salesforce, Outreach, Clearbit, and Slack.

## Key Commands
- Run a script: `python -m scripts.enrichment.waterfall_enrich`
- Run tests: `pytest tests/ -v`
- Run specific test: `pytest tests/test_enrichment/test_waterfall.py -v`
- Lint: `ruff check .`
- Type check: `mypy scripts/`

## Code Conventions
- All API clients inherit from `integrations/base_client.py`
- Use `utils/logger.py` for logging (never print())
- Config via env vars loaded through `utils/config.py`
- Rate limiting: use `utils/rate_limiter.py` for all API calls
- Error handling: try/except around API calls, log errors,
  raise custom exceptions from `utils/exceptions.py`
- All data models live in `schemas/` and use Pydantic

## Data Standards
- Timestamps: UTC ISO 8601 format
- Company IDs: strings (not integers)
- Lead schema defined in `schemas/lead.py`
- All enrichment scripts output to the standard lead schema

## Testing Requirements
- Every script needs unit tests with mocked API responses
- Fixtures go in `tests/fixtures/`
- Use pytest-mock for mocking external services
- Integration tests are tagged @pytest.mark.integration

Progressive Context with Docs

Instead of overloading CLAUDE.md, create focused documentation files that Claude Code can reference on demand. For teams managing complex multi-tool workflows, this approach scales much better:

docs/
├── api_auth_patterns.md       # How we handle auth for each API
├── enrichment_waterfall.md    # Waterfall logic and provider priority
├── deployment_runbook.md      # How to deploy scripts to production
└── data_flow_diagram.md       # How data moves between systems

Reference these in your CLAUDE.md with a brief pointer: "For enrichment waterfall logic and provider priority order, see docs/enrichment_waterfall.md." Claude Code will read the file when it needs the detail.

Script Pattern: Data Enrichment

Enrichment scripts are the most common automation GTM engineers build. They take sparse lead or account data and fill in the gaps by calling one or more data providers. The challenge is always the same: handling provider failures gracefully, managing rate limits, and producing consistent output regardless of which provider returned the data.

Building a Waterfall Enrichment Script

Describe the business logic and let Claude Code handle the implementation details:

> "Build a waterfall enrichment script that takes a list of company
  domains and enriches them with firmographic data. Try Clearbit first.
  If Clearbit returns no data or errors, fall back to Apollo. If Apollo
  also fails, try ZoomInfo as a last resort. For each company, I need:
  employee_count, industry, annual_revenue, headquarters_city,
  and tech_stack. Output should conform to our company schema in
  schemas/company.py. Include progress logging and a summary at the end
  showing how many were enriched by each provider."

Claude Code will examine your existing API clients, understand your schemas, and generate a script that handles the waterfall logic, error recovery, and output formatting. The result typically includes proper rate limiting (using your existing utility), structured logging, and a clean summary output.

Iterating on the Implementation

The first pass rarely captures every requirement. The iteration loop is where Claude Code becomes genuinely useful:

> "The Clearbit client is returning 429 errors after about 100 requests.
  Add adaptive rate limiting that backs off when we start getting
  throttled, then gradually increases speed when the errors stop."

> "Add a --dry-run flag that processes the first 5 companies and
  prints the output without writing to the output file."

> "The Apollo fallback is hitting their bulk endpoint instead of
  the single-lookup endpoint. Fix it to use the person enrichment
  endpoint at /v1/people/match."

Each iteration builds on the previous context. Claude Code remembers the script it wrote, understands the changes you are requesting, and applies them without you needing to re-explain the full requirements.

Script Pattern: Data Sync and Integration

Sync scripts keep your GTM systems in agreement. They move data between platforms, resolve conflicts, handle field mapping, and ensure that a lead updated in one system reflects that change everywhere it matters. These scripts are also the most fragile: API changes, schema drift, and timing issues can break them silently.

Building a CRM Sync Script

CRM sync is where Claude Code saves the most time because the boilerplate-to-business-logic ratio is enormous. Authentication, pagination, rate limiting, field mapping, conflict resolution, and error logging all need to be correct before you get to the actual sync logic.

> "Build a bi-directional sync between our lead database (Postgres)
  and HubSpot contacts. When a lead is created or updated in our
  database, push the changes to HubSpot. When a contact is updated
  in HubSpot, pull changes back. Use HubSpot's v3 contacts API.
  Handle conflicts by preferring the most recent modification
  timestamp. Map fields according to our schema mapping in
  docs/hubspot_field_mapping.md."

Claude Code will reference your field mapping documentation, use your existing HubSpot client, and implement the sync with proper change detection and conflict resolution. For teams managing continuous CRM data updates, this type of script is foundational.

Clay-to-Sequencer Pipelines

Another common pattern is piping enriched data from Clay into a sales sequencer. The script needs to pull completed Clay tables, filter for qualified leads, format the data for the sequencer's API, and enroll leads without creating duplicates:

> "Write a script that polls our Clay table for newly enriched leads
  (status = 'enriched'), checks if they already exist in Outreach,
  and if not, creates prospects and adds them to the appropriate
  sequence based on their persona tag. Use the sequence mapping
  in config/sequence_map.yaml."

This workflow connects directly to the full pipeline from Clay research through qualification to sequence enrollment. Claude Code handles the integration plumbing while you define the routing logic.

Handling Common Sync Challenges

Script Pattern: Reporting and Analytics

Reporting scripts are the unsung heroes of GTM operations. They pull data from multiple systems, calculate metrics, and deliver insights to Slack channels, dashboards, or email inboxes on a schedule. They are also surprisingly tedious to build because the logic is straightforward but the data wrangling is not.

Weekly Pipeline Report

A classic GTM reporting script aggregates pipeline data and delivers a formatted summary:

> "Build a weekly pipeline report script that:
  1. Pulls all opportunities from Salesforce created or updated
     in the last 7 days
  2. Groups them by stage and calculates total value per stage
  3. Identifies opportunities that moved backward (stage regression)
  4. Calculates week-over-week change in total pipeline value
  5. Formats the output as a Slack message with sections for each
     metric and sends it to #sales-pipeline
  Include a --week-of flag to generate reports for previous weeks."

Claude Code will build the Salesforce query, the aggregation logic, the Slack formatting, and the CLI argument parsing. Teams running automated outbound pipelines find these reports essential for tracking whether automation is actually moving the needle.

Enrichment Coverage Report

For teams investing in data enrichment, monitoring coverage rates across your database is critical:

> "Create a report that analyzes our lead database and calculates
  enrichment coverage: what percentage of leads have complete
  firmographic data, what percentage have email verified, what
  percentage have phone numbers. Break it down by lead source
  and by date range. Output as both a Slack summary and a CSV
  for the data team."

Attribution Tracking

Multi-touch attribution scripts that trace pipeline back to source channels are notoriously complex. Claude Code handles the recursive logic of tracing touchpoints while you define the attribution model:

> "Build a linear attribution script that distributes pipeline credit
  equally across all touchpoints for each opportunity. Pull touchpoint
  data from HubSpot marketing events and Salesforce campaign members.
  Output a report showing attributed pipeline by channel and campaign."

Iterating with Claude Code

Building the first version of a script is only the beginning. The real productivity gain comes from how efficiently you can iterate: adding features, handling edge cases, and refining the implementation based on real-world behavior.

The Feedback Loop

The most effective iteration pattern is: describe, run, share errors, fix, repeat. Claude Code maintains session context, so each iteration builds on what came before:

Effective Prompting Patterns

The way you communicate with Claude Code significantly impacts output quality. Here are patterns that work consistently for GTM automation work:

When to Start a New Session

Claude Code's context window is large but not infinite. For long sessions, context can become diluted. Start a new session when you are switching to an unrelated script, when the conversation exceeds roughly 30-40 exchanges, or when Claude Code starts forgetting earlier decisions. Your CLAUDE.md ensures the new session picks up project context immediately.

Testing and Debugging

GTM automation scripts interact with external APIs, process variable data, and run on schedules without supervision. Testing is not optional. Claude Code can both generate tests and help you debug failures, creating a tight feedback loop that catches issues before they hit production.

Generating Tests

After building a script, ask Claude Code to write tests that cover the important paths:

> "Write tests for the waterfall enrichment script. Include:
  - Happy path where Clearbit returns data
  - Fallback to Apollo when Clearbit returns 404
  - Fallback to ZoomInfo when both Clearbit and Apollo fail
  - Handling of rate limit errors from any provider
  - Handling of malformed API responses
  - Correct output schema validation
  Mock all external API calls using pytest-mock."

Claude Code generates tests that follow your existing test patterns, use your fixtures directory, and mock external services consistently. Because it has read your other test files, it knows whether you prefer fixtures, parametrize decorators, or factory functions.

Running and Fixing Tests

Have Claude Code run the tests and fix any failures:

> "Run pytest tests/test_enrichment/test_waterfall.py -v and fix
  any failures"

Claude Code executes the tests, reads the output, identifies failures, and applies fixes. This cycle often catches issues that would otherwise surface in production: null pointer errors on missing fields, incorrect status code handling, or timezone-related bugs in timestamp comparisons.

Debugging Production Failures

When a script fails in production, share the relevant context with Claude Code:

> "The Clay-to-HubSpot sync failed last night. Here's the error log:
  [paste log excerpt]. The script processed 847 out of 1200 records
  before failing. What happened and how do we fix it?"

Claude Code can trace through the code, correlate the error with specific logic paths, and suggest fixes. For intermittent failures, it can also add diagnostic logging to help catch the issue next time. Teams managing data quality across their pipeline find this debugging workflow significantly faster than manual investigation.

Deploying Automation Scripts

A script that works on your laptop is not the same as a script that works in production. Deployment involves scheduling, monitoring, credential management, and failure alerting. Claude Code can help build the deployment infrastructure alongside the scripts themselves.

Scheduling with Cron or Task Runners

Most GTM automation scripts run on a schedule. Ask Claude Code to generate the supporting infrastructure:

> "Create a deployment setup for the enrichment script:
  1. A Dockerfile that installs dependencies and runs the script
  2. A cron schedule that runs it every 4 hours
  3. Environment variable configuration for API keys
  4. Health check endpoint that reports last successful run
  5. Slack notification on failure"

For teams already using workflow orchestrators, Claude Code can generate Airflow DAGs, Prefect flows, or GitHub Actions workflows that wrap your scripts with proper scheduling, dependency management, and alerting.

Monitoring and Alerting

Production scripts need observability. Ask Claude Code to add monitoring hooks:

> "Add monitoring to the Salesforce sync script:
  - Log the number of records processed, created, updated, and failed
  - Track execution duration
  - Send a Slack summary after each run with these metrics
  - Alert #ops-alerts if the failure rate exceeds 5%
  - Alert if the script runs longer than 30 minutes"

Version Control and CI

Claude Code integrates directly with Git, making it natural to build version control into your workflow:

> "Create a branch called feature/zoominfo-enrichment, commit
  the new enrichment script and its tests, and write a PR
  description summarizing the changes"

For teams with CI pipelines, Claude Code can also generate the GitHub Actions or GitLab CI configuration that runs your test suite on every push. This ensures that changes to one script do not break another, which becomes increasingly important as your automation library grows. Teams following SOPs for reliable automation find that CI enforcement is the single most effective quality gate.

Deployment Checklist

Beyond Individual Scripts

Claude Code is exceptional at helping you build and iterate on individual automation scripts. But as your script library grows, a different problem emerges: each script operates with its own view of the world.

Your enrichment script knows about Clearbit data. Your CRM sync script understands HubSpot field mapping. Your lead scoring script has its own copy of qualification criteria. Your reporting script pulls raw data from Salesforce and applies its own logic. None of these scripts share context with each other, and none of them have access to the strategic GTM context that shapes how they should actually behave: your ICP definitions, persona messaging frameworks, competitive positioning, or current campaign priorities.

At five scripts, this is manageable. At fifty, across multiple team members, it becomes a coordination problem. One engineer updates the lead scoring criteria but forgets to update the routing script that depends on those scores. A PMM changes the messaging framework for a persona, but the sequence generation scripts are still using last quarter's positioning. The data is technically flowing, but the context is fragmented.

This is where a shared context layer becomes essential. Instead of encoding GTM knowledge into individual scripts, you centralize it in a system that every script, tool, and team member can query. ICP definitions, persona pain points, competitive intel, enrichment rules, qualification criteria: all maintained in one place and accessible at runtime.

Platforms like Octave solve this through an MCP server that exposes your GTM context as callable tools. Claude Code can connect to Octave's MCP server directly, which means your automation scripts can query live GTM context: "What are the qualification criteria for the enterprise persona?" or "What messaging framework should I use for prospects in the fintech vertical?" Instead of hardcoding this knowledge into each script, your automation stays aligned with the team's current strategy automatically. When the PMM updates positioning in Octave, every script that generates messaging reflects those changes immediately.

For teams building AI-powered SDR automation at scale, this context layer is what transforms a collection of independent scripts into a coherent GTM system.

FAQ

Conclusion

The scripts that power GTM automation are not complex in concept. Enrich leads, sync CRMs, generate reports, route prospects. The complexity lives in the implementation details: API pagination, rate limiting, error handling, field mapping, conflict resolution, and all the other plumbing that separates a working prototype from production-ready automation.

Claude Code handles this plumbing. You describe the business logic, iterate on the implementation, and deploy scripts that would have taken days in a fraction of the time. The key is investing in the right setup: a clean project structure, a focused CLAUDE.md, and clear documentation that gives Claude Code the context it needs to produce code that fits your stack.

Start with one script. Pick the integration or report that has been sitting on your backlog because the implementation work felt disproportionate to the value. Build it with Claude Code in an afternoon. Once you see the workflow in action, you will start approaching your entire automation backlog differently: not as a list of engineering projects, but as a list of conversations waiting to happen.

Related Articles

• What Is GTM Engineering? Responsibilities and Stack
• Best Platforms for GTM Engineers in 2026
• GTM Engineering Has A Context Problem
• The Definitive Guide to AI SDR Automation with Octave and Clay
• Runbooks and SOPs for Reliable AI Outbound