--- name: gtm-workflow-owner-audit description: "Inventory every Clay table, CRM workflow, Zap, Make scenario, and AI agent: one owner, one metric, write scope, a break alert, and a kill switch each. Use when Clay tables, CRM workflows, Zaps, Make scenarios, and AI agents pile up faster than anyone tracks them, so when one stops running or writes bad data nobody knows who owns it, what it was for, which fields it can change, or how to stop it, and unowned automations keep spending credits and writing to the CRM." --- # Audit Every GTM Automation and Agent for an Owner, a Metric, and a Kill Switch Clay tables, CRM workflows, Zaps, Make scenarios, and AI agents pile up faster than anyone tracks them, so when one stops running or writes bad data nobody knows who owns it, what it was for, which fields it can change, or how to stop it, and unowned automations keep spending credits and writing to the CRM. ## When to use this skill - The user wants to set up or run this workflow: "Audit Every GTM Automation and Agent for an Owner, a Metric, and a Kill Switch". - The user describes this problem: Clay tables, CRM workflows, Zaps, Make scenarios, and AI agents pile up faster than anyone tracks them, so when one stops running or writes bad data nobody knows who owns it, what it was for, which fields it can change, or how to stop it, and unowned automations keep spending credits and writing to the CRM. ## At a glance - Category: RevOps - Difficulty: Intermediate - Time saved: 1.5 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. - Google Sheets - Clay - HubSpot or Salesforce - Zapier or Make - Slack ## Steps 1. Pull the inventory from each system instead of from memory, one row per active automation in a Google Sheet: Clay tables with auto-run or scheduled sources and published Clay workflows (clay workflows list in the Clay CLI), active HubSpot workflows, active Salesforce flows and any remaining workflow rules or Process Builder processes (Setup, or the Tooling API), Zaps that are on, active Make scenarios, and every AI agent or script that holds an API key or OAuth connection, found in each vendor's admin console and the CRM's connected apps 2. Record what each automation can write: the systems, objects, and fields it can create, update, or delete, and the credential it runs as (a named user, an integration user, or an API key); flag anything that runs on a person's own login or an admin-scoped key, because it stops or keeps too much access when that person leaves 3. Give every row one named owner, a person and not a team, who answers when it breaks and approves changes; use the creator from the system's audit fields as the first candidate and confirm with them, and mark the row unowned if the creator has left or will not take it 4. Write down the one metric each automation moves and where to see it, such as share of inbound leads with an owner within 5 minutes or data credits per enriched record; a row whose owner cannot name a metric is marked metric-less 5. Set a break alert per row and post it to the owner in Slack: zero runs or zero rows processed in 24 hours while its source had input, an error rate above 3 times its 14-day average (an assumption you can change), credits or actions over its monthly budget, or a write to a field outside its declared list; read run counts from Zapier task history, Make scenario history, HubSpot workflow history, Salesforce failed flow interviews, and Clay run history with a daily job that writes them to a run_log tab, and escalate to a shared channel when an alert is not acknowledged within 4 business hours (an assumption) 6. Document a kill switch per automation and per agent: the single action that stops its writes, who may use it, and how long it takes; turn off the HubSpot workflow, deactivate the Salesforce flow or remove the integration user's permission set, turn off the Zap, deactivate the Make scenario, turn off auto-run or unpublish in Clay, and for AI agents a stop flag the agent reads before every write, with revoking its API key as the backstop; test each switch once on a quiet day and record the time to stop 7. Move unowned and metric-less rows to a delete-or-adopt list: each gets 14 days (an assumption) to find an owner and a metric; after that, turn it off rather than delete it, keep a config export, and delete it after 30 more days if nobody asked for it 8. Review monthly: diff each system's export against the inventory to catch new automations, check owners against the HRIS for leavers, count alerts fired and time to acknowledge, list kill switch tests that are older than a quarter, and post a short summary to Slack ## Cost, time saved, and break-even This is mostly a process with tools you already pay for, so tool cost is an input, and the data credit price is Clay's listed rate as checked on 2026-10-21. Every other number below is an assumption; replace each with your own figure. ### Listed prices - Clay data credits: From $0.05 each ### Inputs (every value is an assumption; replace it with your own figure) - B = 4 (assumption): Automation breaks or bad writes per month that someone has to trace. Count last quarter's incidents in Slack and tickets where an automation stopped or wrote bad data, and divide by 3. - H = 3 (assumption): Hours to trace one break today, without an owner or an alert. Ask who handled the last few breaks how long it took to find what ran, who owned it, and how to stop it. - H2 = 1 (assumption): Hours to handle one break with a named owner, an alert, and a kill switch. Time the first breaks after the audit. - V = 1.5 (assumption): Hours a month for the review and the delete-or-adopt follow-up. Time the first two monthly reviews. - I = 10 (assumption): One-time hours to build the inventory. Count systems and automations first; the first export of each system is most of the work. - U = 1,500 (assumption): Data credits a month used by Clay tables that get turned off. Read each delete-or-adopt table's usage in Clay. Use 0 if none of them auto-run. - P = $0.05 (assumption): Dollar cost per Clay data credit. Clay lists data credits from $0.05 (checked 2026-10-21). For your plan, divide the data credit part of the price by its monthly data credits. - K = $20 (assumption): Monthly tool cost for the daily run-count job. Your Zapier or Make plan share for the job, from current vendor pricing and your invoices; Google Sheets and Slack are usually already paid for. - R = $75 (assumption): Loaded hourly cost of the RevOps person who traces breaks. Salary plus benefits, divided by working hours. ### Formulas - Hours saved per month: B x (H - H2) - V = 4 x (3 - 1) - 1.5 = 6.5 hours - Hours saved per week: (B x (H - H2) - V) / 4.33 = 6.5 / 4.33 = 1.50 hours, the time-saved estimate on this page - Value of time saved per month: (B x (H - H2) - V) x R = 6.5 x $75 = $487.50 - Credits no longer spent per month: U x P = 1,500 x $0.05 = $75.00, only once those tables are turned off - Net value per month: time value + credits - K = $487.50 + $75.00 - $20 = $542.50 - Payback on the one-time inventory: I x R / net value per month = 10 x $75 = $750 / $542.50 = 1.38 months - Break-even hours per month for the tool cost: K / R = $20 / $75 = 0.27 hours, about 16 minutes a month ### Notes - The math counts tracing time and idle credits only. A bad write by an agent with no kill switch can cost more than the time, but measure incidents and time to stop before and after instead of assuming a number. - Credits only count as saved when a delete-or-adopt table is actually turned off. Tables that stay on after adoption keep their cost and gain an owner and a budget instead. - Turning an automation off before deleting it, with a config export, is what makes the 30-day window safe: if something downstream breaks, turn it back on and give it an owner. ## Calculator To estimate cost with the user's own numbers, point them to the Clay credit calculator: https://gtmplaybooks.io/calculators/clay-credits/. Price each Clay table on the inventory from its monthly rows and steps, so the delete-or-adopt list shows what turning an unowned table off saves. ## Template outline Field names, thresholds, and message text are starting points to adapt. ~~~text Google Sheet: GTM automation inventory (RevOps owns it; reviewed monthly) Tab inventory (one row per active automation or agent): automation_id, system (Clay, HubSpot, Salesforce, Zapier, Make, AI agent), name, url, trigger (schedule, webhook, record change, manual), created_by, created_on, owner_email, owner_confirmed_on, metric, metric_source, writes_to (system.object.field list), can_delete (yes/no), runs_as (named user, integration user, API key), credential_scope, monthly_budget (credits, actions, or tasks), break_alert (rule and threshold), kill_switch (exact action), kill_switch_owner, kill_switch_tested_on, minutes_to_stop, status (owned, unowned, metric-less, off, deleted) Tab run_log (daily job from each system's run history): date, automation_id, runs, rows_processed, errors, credits_or_tasks_used Break alert rules (defaults are assumptions; set per row): zero_runs: runs = 0 or rows_processed = 0 in 24 hours while the source had input error_spike: errors / runs above 3 x the 14-day average over_budget: credits_or_tasks_used month to date above monthly_budget out_of_scope_write: a write to a field not in writes_to (from CRM field history) Escalate to #gtm-ops if the owner has not acknowledged in 4 business hours Kill switch by system: HubSpot workflow turn the workflow off Salesforce flow deactivate the flow, or remove the integration user's permission set Zapier turn the Zap off Make deactivate the scenario Clay turn off auto-run on the table, or unpublish the workflow AI agent set stop = TRUE in its control cell or flag, which it reads before every write; revoke its API key as the backstop Tab delete_or_adopt: automation_id, reason (unowned, metric-less), listed_on, adopt_by (listed_on + 14 days), turned_off_on, config_export_url, delete_after (turned_off_on + 30 days), decision Worked example (fictional inventory, six rows): id system name owner metric status A1 Clay Inbound enrichment table Priya leads enriched within 10 min owned A2 HubSpot Lead owner assignment Marcus leads with owner in 5 min owned A3 Zapier Webinar leads to CRM (left) none named unowned -> delete_or_adopt A4 Make Weekly pipeline export Dana pipeline report on Monday owned A5 AI agent CRM title cleanup agent Priya titles standardized per week owned, kill switch tested A6 Clay Old event list table none none named metric-less -> delete_or_adopt Result: 4 owned with alerts and kill switches; A3 and A6 get 14 days to be adopted, then are turned off with a config export, then deleted 30 days later if nobody asks Slack, monthly summary to #gtm-ops: "Automation audit {{month}}: {{active_count}} active, {{owned_count}} owned with a metric, {{new_count}} new since last review, {{adopt_count}} on delete-or-adopt, {{off_count}} turned off. Alerts: {{alerts_fired}} fired, median {{ack_minutes}} minutes to acknowledge. Kill switches not tested this quarter: {{untested}}. Sheet: {{sheet_url}}" ~~~ ## 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/gtm-workflow-owner-audit/