Clay Workflows With Claude: 5 GTM Blueprints for Small Revenue Teams

Key takeaways

• Clay Workflows can be built from inside Claude Code through the Clay Agent Plugin, so an operator describes the play in plain language instead of assembling nodes by hand.
• A Clay Workflow and a Clay Function are two different objects. A Workflow runs a multi-step play. A Function is one reusable step that can be exposed to a rep through Clay MCP.
• The five blueprints below cover hiring signals, website visits, funding and launch events, inbound forms, and closed-lost reactivation.
• The blueprints include a human approval step before any outreach sends. That single rule is what separates a useful system from an expensive mistake.
• Clay Workflows is in open beta as of August 2026, so availability and limits vary by plan. Worth checking your own workspace before you build.

---

What are Clay Workflows and Clay Functions?

A Clay Workflow is a multi-step play that runs on a trigger. It pulls records, researches them, scores them, branches on the result, and writes the decision back.

A Clay Function is one reusable step. Score an account. Find a contact. Check a CRM record. A Function can be turned on for MCP, which lets an approved person call it from a Claude chat without opening Clay.

The difference matters for a small team. Operations builds Workflows. Reps call Functions. You test both inside Clay before anyone else touches them.

A pattern we keep seeing at BuildWire AI: most seed to Series A teams do not need more tools. They need the three or four plays they already run by hand to run the same way every time, with the evidence attached.

---

Two paths into Clay: which one do you need?

Most teams start with the builder path, then expose two or three Functions once the Workflows are stable.

---

Setup checklist

Builder path: Claude Code to Clay Workflows

1. Confirm Clay Workflows is available in your workspace.
2. Install the Clay Agent Plugin in Claude Code.
3. Sign in to Clay through OAuth.
4. Describe the play: trigger, inputs, branches, outputs.
5. Open the saved Workflow in Clay.
6. Test one record before you run a segment.
7. Read the trace: credits, actions, errors, branch decisions.

Clay's own setup instruction for a coding agent is a single line:

Set up the Clay plugin by following the steps in https://github.com/clay-run/agent-plugins

User path: Claude to Clay Functions

1. Build and test the reusable Function in Clay.
2. Turn the Function on for MCP in its Clay settings.
3. Set user access and credit budgets.
4. Connect Clay to Claude.
5. Ask Claude to run the named Function.
6. Require approval before messages, CRM changes, or paid actions.

---

Blueprint 1: Hiring signal to qualified account

The job: find accounts hiring for a role that maps to your product, then route the qualified ones to an owner.

Inputs you need: target account segment, hiring signal or job-title rule, ICP criteria, territory and owner rules, approved research sources, a Slack review channel or CRM destination.

The flow:

1. Trigger when a target account posts a matching role.
2. Pull the account's existing Clay record.
3. Research the role, company, technology, and recent activity.
4. Score the account against ICP criteria.
5. Branch by score and territory.
6. Draft a short outreach angle for qualified accounts.
7. Send the draft to a human review queue.
8. Write the score and decision back to Clay.

Build prompt for Claude Code:

Build a Clay Workflow for accounts in my target segment that post a matching role. Research the company, score it against my existing ICP Function, assign the correct owner, and send accounts above the agreed score to a Slack review channel with a draft outreach angle. Write the score, evidence, owner, and review status back to the account record. Ask me for each missing field before saving the Workflow.

Approval point: a person approves the account and the message before outreach starts.

What you get: a reviewed account queue with evidence, score, owner, and an outreach angle.

---

Blueprint 2: Website visitor to sales alert

The job: match a high-intent website visit to an account, score it, and alert the right owner.

Inputs you need: website visitor source, target page or event rules, an account-match provider, ICP criteria, exclusions for existing customers and open opportunities, owner-assignment rules.

The flow:

1. Trigger on a qualified website event.
2. Match the visitor to a company record.
3. Check CRM status, ownership, and open opportunities.
4. Pull firmographic, hiring, funding, and technology data.
5. Score fit and intent separately.
6. Exclude customers, competitors, and active opportunities.
7. Send qualified accounts to the owner for review.
8. Store the evidence and the routing decision.

Build prompt for Claude Code:

Build a Clay Workflow that starts when a company visits one of my selected high-intent pages. Match the visit to an account, check CRM status, enrich the company, score fit and intent, apply the exclusion rules, assign the correct owner, and post qualified accounts to the review channel. Store every input, score, exclusion, and routing reason on the Clay record.

Approval point: the owner reviews the alert before contacting the account.

What you get: a sales alert carrying account context, intent evidence, exclusions, score, and owner.

The exclusion step is the one people skip. A visitor alert that pings a rep about an account already in a live deal is worse than no alert.

---

Blueprint 3: Funding or launch signal to outreach angle

The job: turn a current company event into a researched, relevant reason to make contact.

Inputs you need: target segment, accepted event types, an event recency window, ICP criteria, an approved message structure, CRM and owner rules.

The flow:

1. Trigger on new funding, a product launch, a market entry, or a senior hire.
2. Verify the event date and the primary source.
3. Check whether the account matches the target segment.
4. Pull CRM history and current ownership.
5. Research the business effect of the event.
6. Draft one outreach angle tied to the verified event.
7. Route the draft for review.
8. Save the source, date, reasoning, and decision.

Build prompt for Claude Code:

Build a Clay Workflow that monitors my target accounts for the approved event types. Verify each event through a primary source, check ICP fit and CRM history, identify the likely business effect, and draft one outreach angle. Send the draft to the account owner for review. Store the source URL, publication date, evidence, and routing decision in Clay.

Approval point: a person checks the event, the timing, and the message before outreach.

What you get: a source-backed outreach brief tied to a current, verifiable company event.

Step 2 is doing most of the work here. An outreach angle built on a funding round from fourteen months ago reads worse than a plain cold email.

---

Blueprint 4: Inbound form to qualified owner

The job: research and route an inbound lead while the request is still current.

Inputs you need: a form or webhook, required form fields, ICP criteria, qualification branches, territory rules, a CRM destination, review and alert channels.

The flow:

1. Trigger when the form arrives.
2. Validate the submitted data.
3. Enrich the company and the contact.
4. Check CRM history and ownership.
5. Score the lead on ICP, use case, and timing.
6. Branch into qualified, nurture, disqualified, or manual review.
7. Assign the correct owner.
8. Write the decision to the CRM and alert the owner.

Build prompt for Claude Code:

Build a Clay Workflow that starts when a demo-request webhook arrives. Validate the form, enrich the company and contact, check CRM history, score the lead against our ICP and qualification rules, branch into the approved outcomes, assign the correct owner, and write the decision to the CRM. Alert the owner with the evidence and score. Stop for approval before any external message sends.

Approval point: the owner reviews any generated reply before it sends.

What you get: a routed lead record with research, score, branch, owner, and next action.

---

Blueprint 5: Closed-lost account reactivation

The job: find closed-lost accounts that now have a new reason to talk.

Inputs you need: the closed-lost segment, a cooling period, accepted new signals, an open-opportunity exclusion, contact and ownership rules, an approved reactivation structure.

The flow:

1. Run a scheduled scan of closed-lost accounts.
2. Check for new hiring, funding, leadership, product, or engagement signals.
3. Exclude accounts with an open opportunity or active owner action.
4. Review the original loss reason and account history.
5. Find current contacts and remove CRM duplicates.
6. Draft a reactivation angle tied to the new signal.
7. Send the account and draft to the owner for review.
8. Record the signal, evidence, contacts, and decision.

Build prompt for Claude Code:

Build a scheduled Clay Workflow for closed-lost accounts past the cooling period. Check the approved signals, exclude accounts with open opportunities or active owner work, review the original loss reason, find current contacts without creating CRM duplicates, and draft one reactivation angle. Send qualified accounts to the owner for approval and store the evidence and decision in Clay.

Approval point: the owner confirms the account, the contact, and the message.

What you get: a reviewed reactivation list with current signals, account history, contacts, and a message angle.

This is often the highest-return blueprint for a team under three years old, because the closed-lost list is already qualified. Someone took a call. The loss reason is recorded. The only missing piece was timing.

---

Governance checks before you launch

• Test each Workflow on one record.
• Review every branch and every exclusion.
• Add a human approval step before outreach.
• Set Function permissions before you turn on MCP.
• Set per-user credit budgets.
• Keep CRM deduplication active.
• Store source URLs and dates for event-based research.
• Read the Claygent reasoning in the run trace, not only the output.
• Check node-level credit and action use.
• Keep sensitive data inside approved systems.

Product limits worth checking first

Clay Workflows is in open beta. Clay has said that sourcing through search and some waterfall enrichment features are still being added. Waterfall enrichment can run through a Function in the meantime. Plan access also varies by account type.

Verify current availability and limits inside your own Clay workspace before you build. The blueprints above assume you have the triggers and data sources your plan allows.

---

Summary

Clay Workflows plus Claude gives a small revenue team a way to run repeatable plays without a dedicated RevOps hire. The build path runs through Claude Code and the Clay Agent Plugin. The daily-use path runs through Clay MCP and approved Functions.

The five blueprints cover the signals most seed to Series A teams already watch by hand: hiring, website intent, funding and launches, inbound forms, and closed-lost accounts. Each one keeps a person in the loop before anything sends.

We are still testing where the limits sit, and Clay is still shipping into open beta, so treat these as starting structures rather than finished systems. Curious what other teams are finding once these run past the first few hundred records.

---

Sources

• Clay Workflows announcement: https://www.clay.com/blog/introducing-workflows
• Clay inside Claude and ChatGPT: https://www.clay.com/blog/how-clay-uses-clay-from-inside-claude-and-chatgpt
• Clay MCP and Functions: https://www.clay.com/blog/clay-mcp
• Clay Agent Plugin repository: https://github.com/clay-run/agent-plugins

Sources last checked: August 20, 2026.

Frequently asked questions

Last reviewed 20 August 2026. Clay product behavior, plan availability, and documentation checked on 20 August 2026. Features and limits may change.