---
name: crm-hygiene-ai-agent
description: "Use an AI agent in Clay to standardize job titles, fill missing industry, and flag contacts who left, then write reviewed fixes to HubSpot or Salesforce. Use when CRM records decay as people change jobs and reps type titles and industries in different formats, so segmentation, routing, and reporting quietly break."
---

# Keep CRM Data Clean with an AI Hygiene Agent

CRM records decay as people change jobs and reps type titles and industries in different formats, so segmentation, routing, and reporting quietly break.

## When to use this skill

- The user wants to set up or run this workflow: "Keep CRM Data Clean with an AI Hygiene Agent".
- The user describes this problem: CRM records decay as people change jobs and reps type titles and industries in different formats, so segmentation, routing, and reporting quietly break.

## At a glance

- Category: RevOps
- Difficulty: Intermediate
- Time saved: 4 hours per week. This figure is an estimate, not a measured result.

## Tools

Options separated by "or" are alternatives; use whichever the user already has.

- Clay
- Claygent
- HubSpot or Salesforce
- ZeroBounce or NeverBounce
- Slack

## Steps

1. Export contacts not updated in 90 days from HubSpot or Salesforce with record ID, email, name, title, company, domain, and industry, and upload the export to Clay weekly or monthly
2. Verify each email and mark hard bounces, then use person enrichment to check whether contacts with invalid emails still work at the company
3. Use an AI step (Claygent or a Use AI action) to map free-text titles to a fixed seniority and department list and to fill a missing industry from the company website, returning a confidence value
4. Apply changes automatically only when confidence is high and the CRM field is empty or clearly malformed, and send everything else to a review list instead of overwriting rep-entered data
5. Write approved fixes back to the CRM with an "AI hygiene reviewed on" date, and mark contacts who left as former employees rather than deleting them
6. Post a Slack summary after each run with the number of fields fixed, contacts flagged as left, and records waiting for review

## Template outline

Field names, thresholds, and message text are starting points to adapt.

~~~text
Clay Workflow (CSV trigger, weekly or monthly export):
1. Input: crm_id, email, first_name, last_name, title, company, company_domain, industry
2. Verify email: valid, invalid, catch-all
3. IF invalid: person enrichment to check current employer
4. AI step (Claygent or Use AI), JSON output:
   - seniority: C-level, VP, Director, Manager, Individual contributor
   - department: Sales, Marketing, RevOps, Finance, Customer Success, Product, Engineering, Other
   - industry: fill only if empty
   - confidence: high, medium, low
5. IF confidence = high AND field is empty or malformed: update CRM field
   ELSE: add to review list
6. CRM: "AI hygiene reviewed on" = today, "Former employee" = true when they left
7. Slack summary: fields fixed, contacts left, records for review
Output: standardized title, department, and industry fields on stale records, with low-confidence changes reviewed by a person
~~~

## Optional: build it with the Clay CLI

This builds the hygiene agent as a Clay workflow. A CSV trigger sends each exported CRM record through email verification, an AI step that standardizes title fields and fills missing industry, and a CRM update. Each CSV row becomes one workflow run. The Clay CLI cannot create tables, so this build uses a workflow.

Written against Clay CLI v1.3.1. Run these commands only in the user's own Clay workspace, logged in with their own account, after they confirm. Items marked VERIFY are config shapes the CLI help does not document; check them in the workspace before relying on them.

### Prerequisites

- Install the Clay CLI: Use version 1.3.1 or later, installed from Clay's own instructions. This page does not include an install command because the CLI reference it was written from does not list one. You also need jq, which the script uses to read the JSON the CLI prints.
- Log in to your workspace: Browser login is the default. Use the device flow on a headless machine. A static key in the CLAY_API_KEY environment variable also works. Workflow commands need the terracotta:cli scope, so an auth error that names it means your login cannot manage workflows.
  - Log in with a browser: `clay login`
  - Log in on a headless machine: `clay login --device`
  - Confirm who you are logged in as: `clay whoami`
- Pick the workspace to build in: The workflow is created in your active workspace. Switch first if you belong to more than one.
  - List workspaces: `clay workspaces list`
  - Show the active workspace: `clay workspaces current`
  - Switch workspace: `clay workspaces switch <workspaceId>`
- Find your action keys: Action package ids and keys are specific to your workspace. Save the catalog, search it for an email verifier, a Claygent or Use AI action, and your CRM update action, then paste their ids into the top of the script. Skip "clay workflows actions test": it spends credits.
  - Save the action catalog: `clay workflows actions list > catalog.json`
  - Search the catalog: `grep -Eio '"[^"]*(zerobounce|neverbounce|claygent|use ai|hubspot|salesforce)[^"]*"' catalog.json | sort -u`
  - See an action's inputs and outputs: `clay workflows actions schema <packageId> <actionKey>`
- Export the records to clean: Export contacts not updated in 90 days from HubSpot or Salesforce with the columns in the sample CSV. Start with a small export that includes a test record.

### Workflow: CRM hygiene agent

Trigger (csv_upload): You upload a CRM export to the trigger. Each header becomes a string input, and each row becomes one run once the workflow is published. VERIFY: The trigger type string "csv_upload" is inferred. The CLI help does not show how to create a CSV trigger.

Inputs (CSV headers):

- crm_id: HubSpot or Salesforce record ID (example: your-test-record-id)
- email: Email on the record (example: jane@example.com)
- first_name: First name (example: Jane)
- last_name: Last name (example: Doe)
- title: Title as typed in the CRM (example: vp sales & ops)
- company: Company name (example: Example Co)
- company_domain: Company domain (example: example.com)
- industry: Current industry value, may be empty (example: (empty))

1. Verify the email (action): Flags hard bounces, which often mean the person left the company.
   - Inputs: email
   - Outputs: email_status
2. Standardize title and fill firmographics (action): A Claygent or Use AI step maps free-text titles to fixed lists and fills a missing industry, with a confidence value.
   - Inputs: title, company, company_domain, industry
   - Outputs: seniority, department, industry, confidence
   - Prompt:

~~~text
You clean CRM records. Given this contact and company:
title: {{title}}
company: {{company}} ({{company_domain}})
current industry: {{industry}}
Return JSON with:
- seniority: one of C-level, VP, Director, Manager, Individual contributor
- department: one of Sales, Marketing, RevOps, Finance, Customer Success, Product, Engineering, Other
- industry: the company's industry if current industry is empty, otherwise the current value
- confidence: high, medium, or low for the whole record
Use the company website for industry. If you are unsure, return low confidence and leave fields empty.
~~~

3. Update the CRM record (action): Writes high-confidence fixes and an "AI hygiene reviewed on" date back to the record.
   - Inputs: crm_id, seniority, department, industry, email_status
   - Outputs: CRM response
   - VERIFY: Writing only high-confidence fields needs a run condition or field-level logic, which the CLI help does not document. Set it in the Clay UI, and do not map fields that would overwrite rep-entered data.

### Script: build-crm-hygiene.sh

Creates the workflow, trigger, and three steps, then pauses so you can map step inputs and the confidence rule. It validates the graph, offers one test run, and asks before publishing.

~~~bash
#!/usr/bin/env bash
# Builds the "CRM hygiene agent" Clay workflow
# in YOUR Clay workspace, using YOUR Clay CLI login.
# Written against Clay CLI v1.3.1. Not run or tested by GTM Playbooks.
# Lines tagged VERIFY use a shape the CLI help does not document.
set -euo pipefail

# Copy these from catalog.json (see "Find your action keys").
VERIFIER_PACKAGE_ID="" # Email verification (for example ZeroBounce)
VERIFIER_ACTION_KEY=""
AGENT_PACKAGE_ID=""    # Claygent or Use AI
AGENT_ACTION_KEY=""
CRM_PACKAGE_ID=""      # HubSpot or Salesforce: update record
CRM_ACTION_KEY=""

# One input to test before real traffic. Use yourself or a teammate.
TEST_ROW='{"crm_id":"","email":"","first_name":"","last_name":"","title":"","company":"","company_domain":""}'

for v in VERIFIER_PACKAGE_ID VERIFIER_ACTION_KEY AGENT_PACKAGE_ID AGENT_ACTION_KEY CRM_PACKAGE_ID CRM_ACTION_KEY; do
  [[ -n "${!v}" ]] || { echo "Set $v at the top of this script." >&2; exit 1; }
done
command -v clay > /dev/null || { echo "Clay CLI not found on PATH." >&2; exit 1; }
command -v jq > /dev/null || { echo "jq is required to read CLI output." >&2; exit 1; }
clay whoami > /dev/null || { echo "Not logged in. Run: clay login" >&2; exit 1; }

# VERIFY: only "workflows create" documents an "id" field in its output.
read_id() {
  local id
  id=$(jq -r '.id // empty' "$1")
  [[ -n "$id" ]] || { echo "No id found in $1. Open it and adjust read_id." >&2; exit 1; }
  echo "$id"
}

mkdir -p clay-crm-hygiene
cd clay-crm-hygiene

echo "1/7 Create the workflow"
clay workflows create --name "CRM hygiene agent" > workflow.json
WF_ID=$(read_id workflow.json)
WF_URL=$(jq -r '.url // empty' workflow.json)

echo "2/7 Add the CSV upload trigger"
# VERIFY: triggerType "csv_upload" is inferred; the help does not show it.
clay workflows triggers create "$WF_ID" --input '{"triggerType":"csv_upload"}' > trigger.json
TRG_ID=$(read_id trigger.json)

echo "3/7 Step 1: verify the email"
# VERIFY: help shows nodeType and name only; actionPackageId and actionKey are a guess.
STEP1=$(jq -nc --arg p "$VERIFIER_PACKAGE_ID" --arg k "$VERIFIER_ACTION_KEY" '{nodeType: "tool", name: "Verify the email", actionPackageId: $p, actionKey: $k}')
clay workflows nodes create "$WF_ID" --input "$STEP1" > step1.json
STEP1_ID=$(read_id step1.json)

echo "4/7 Step 2: standardize title and fill firmographics"
# VERIFY: action fields inside "step" are inferred from the documented utility example.
STEP2=$(jq -nc --arg n "$STEP1_ID" --arg p "$AGENT_PACKAGE_ID" --arg k "$AGENT_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}')
clay workflows nodes insert "$WF_ID" --input "$STEP2" > step2.json
STEP2_ID=$(read_id step2.json)

echo "5/7 Step 3: update the crm record"
# VERIFY: same inferred insert shape as step 2.
STEP3=$(jq -nc --arg n "$STEP2_ID" --arg p "$CRM_PACKAGE_ID" --arg k "$CRM_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}')
clay workflows nodes insert "$WF_ID" --input "$STEP3" > step3.json
clay workflows graph get "$WF_ID" --mode full > graph.json

echo "6/7 Map step inputs"
cat <<EOF

Step inputs are specific to your workspace. Map them before validating:
  Step 1 verify:  email
  Step 2 agent:   title, company, company_domain, industry, and the agent prompt
  Step 3 CRM:     crm_id plus only the fields step 2 returned with high confidence;
                  send low-confidence rows to a review list instead
Map them in the Clay UI${WF_URL:+ at $WF_URL}, or per node with:
  clay workflows nodes get $WF_ID <nodeId>
  clay workflows nodes update $WF_ID <nodeId> --input node.json
graph.json in this folder shows the current nodes and edges.

EOF
read -r -p "Press Enter when inputs are mapped. "

echo "7/7 Validate, test once, publish"
clay workflows graph validate "$WF_ID"
clay workflows diagram "$WF_ID"

if jq -e 'all(.[]; . != "")' <<< "$TEST_ROW" > /dev/null; then
  read -r -p "Run TEST_ROW once? It can spend Clay credits and update a CRM record. [y/N] " answer
  if [[ "$answer" == [yY] ]]; then
    clay workflows runs test "$WF_ID" --inputs "$TEST_ROW" > test-run.json
    echo "Saved test-run.json. Check each step with: clay workflows runs steps $WF_ID <runId>"
  fi
else
  echo "TEST_ROW is empty, skipping the test run."
fi

read -r -p "Publish the workflow now? [y/N] " answer
if [[ "$answer" == [yY] ]]; then
  clay workflows publish "$WF_ID" --name v1
fi

echo "Workflow $WF_ID, CSV upload trigger $TRG_ID. All responses are saved in $(pwd)."
~~~

### CRM export CSV: crm-export.csv

~~~csv
crm_id,email,first_name,last_name,title,company,company_domain,industry
your-test-record-id,jane@example.com,Jane,Doe,vp sales & ops,Example Co,example.com,
~~~

### Run it on your export

After publishing, upload the export to the trigger and start with a few rows. Each row is one run.

- Load the saved ids (run inside clay-crm-hygiene/): `WF_ID=$(jq -r '.id' workflow.json); TRG_ID=$(jq -r '.id' trigger.json)`
- Upload the CSV (this does not start runs): `clay workflows triggers csv upload "$TRG_ID" --file crm-export.csv`
- Run the first 5 rows (needs a published workflow, one run per row): `clay workflows triggers csv run "$TRG_ID" --limit 5`
- List runs: `clay workflows runs list "$WF_ID"`
- Inspect one run: `clay workflows runs get "$WF_ID" <runId>`
- See each step's output for that run: `clay workflows runs steps "$WF_ID" <runId>`

### Verify in the workspace

- The CSV trigger type "csv_upload" is inferred. If "triggers create" exits with code 2 (validation), check which trigger types your workspace accepts.
- The help documents "nodes create" with nodeType and name only. If it rejects actionPackageId and actionKey, create the node with a name only and pick the action in the Clay UI.
- The reference says action steps take actionPackageId and actionKey but shows only a utility example for "nodes insert", so the placement of those fields inside "step" is inferred.
- Only "workflows create" documents an id field in its response. The script reads .id from trigger and node responses too and stops if it is missing.
- Package ids and action keys differ by workspace and depend on which integrations you have connected. Copy them from your catalog; this page does not guess them.
- Step input mapping is dynamic per workspace. The CLI path is "nodes get" then "nodes update", where incomingEdges is a full replacement. The argument order for "nodes get" is inferred from "nodes update".
- The help does not say whether step 1 connects to the trigger automatically. "clay workflows graph validate" reports a disconnected graph.
- This build does not merge duplicates. Handle those separately before or after the hygiene run.
- "runs test" without --live is assumed to run the draft. The reference lists --live without describing it.
- Workflow runs can spend Clay credits and write to connected tools. Exit code 3 means re-run clay login, and exit code 4 means you are rate limited (wait for details.retryAfter).

## Guardrails

- Work only in the user's own accounts and workspaces, with their credentials.
- Confirm with the user before any step that writes to a CRM, sends email or messages, spends credits, or moves money.
- Treat every hours, cost, and threshold figure as a starting assumption and replace it with the user's numbers.
- Do not invent data, prices, or results. If a vendor price matters, check the vendor's current pricing page.

## Source

https://gtmplaybooks.io/playbooks/crm-hygiene-ai-agent/