Spot the fake coverage in your Clay tables before reps dial it

Build me an internal quality-control desk for the rows we enrich in Clay. Our tables look full, but a lot of that coverage is junk: a company switchboard number sitting in the mobile column, an info@ address standing in for a named contact. Those cells pass every simple check for whether a field is populated, so our reporting says we have 90 percent coverage while reps burn dials on main lines and we keep paying credits for it. The job of this app is to make real coverage visibly different from apparent coverage, and then make fixing the bad rows cheap.

On first open, let me set up an audit workspace: paste in the Clay table IDs I want to audit (up to five, since one query can span five tables) and the ID of the Clay enrichment routine I want to use for targeted re-runs. Table IDs and routine IDs are not discoverable through the API, so I copy them out of the Clay workspace UI. Save that configuration in the app so I do not re-enter it every time, let me name each workspace, and let me edit or add workspaces later.

The app opens on a coverage summary. Pull records with Clay Query Tables, following the cursor until the pages run out, and build the summary from the field metadata that comes back alongside the records rather than hardcoding column names, so the app still works when we add a column. For every field show three numbers side by side: percent populated, percent that pass validation for what that field is supposed to hold, and percent flagged as suspicious. Render each field as a stacked bar so the gap between populated and genuinely valid is the first thing I see, and under each bar a breakdown of which suspicious patterns account for that gap, with counts.

Bake in these validation rules. Phones: normalize numbers, then compare each contact phone against the company main line on the same row and against the other phones in the table for that same company. A number that matches a company main line, or that repeats across many contacts at one company, does not count as real mobile coverage; flag it as main line in mobile field. Emails: treat role-based local parts (info, sales, support, admin, hello, contact, team, billing, office) as their own category, flagged separately from missing emails, because a role-based address is a different problem from a blank one and must never be silently counted as coverage. Also flag free-mail domains on a business contact and addresses whose domain does not match the company domain on the row. Names and titles: flag placeholder values, single-character or all-caps names, and titles that are just the company name rather than a role. Everywhere in the app, treat null-ish strings like N/A, unknown, null, none, and a bare dash as empty rather than populated.

Clicking any bar, or any line in a suspicious-pattern breakdown, drills straight into exactly those rows. Show a row list with the contact identity columns, the offending field highlighted along with the reason it was flagged, and the company main line shown beside the phone so I can see the collision for myself. Let me sort, search, and filter inside the drill-down, and select rows with checkboxes including a select-all that respects the current filter.

From that selection, let me re-run the configured Clay enrichment routine on just those rows with Run a Routine. Chunk the selection into batches of at most 100 items per run, since that is the inline limit, then poll Get Routine Run Results until each run reaches a terminal status, showing live progress with counts for queued, running, complete, and failed. As each run finishes, merge the returned values back into the row list so I can see straight away whether the re-run produced a genuine mobile number or came back with the same main line, and re-score those rows against the validation rules. Keep a history of re-runs (when, by whom, how many rows, what came back) so we can tell which routines are worth the credits. Before I confirm a run, show me the row count I am about to spend credits on.

I review rows one at a time or in bulk and mark each one approved or rejected. Rejection reasons come from a fixed picklist so the team's reasons stay comparable over time; use exactly these values: main line in mobile field, role-based email, wrong person, company mismatch, invalid format, out of date, duplicate row, other. Require a short note when other is chosen. Store every decision in the app with the row identifier, the reviewer, the reason, and a timestamp, and keep those decisions when the underlying table data is refreshed so we never re-review the same row twice. Show each row's current status in the drill-down and let me filter by unreviewed, approved, or rejected.

When a batch is clean, export only the approved rows to Google Sheets. On first use, create the destination workbook with Create Spreadsheet, writing a header row and one tab per audit workspace, then store the spreadsheet ID in the app and use Append Values for every export after that so everything accumulates in one place. Never export rejected or unreviewed rows. Track which rows have already been exported and leave them out of the next export so downstream outreach does not get duplicates, and after each export show me the count exported and a link to the sheet.

Across the top of the summary, show one headline pair for the whole audit: apparent coverage against real coverage, plus how many rows are approved, rejected, and still unreviewed. That headline is the number I want to be able to quote in a pipeline meeting.