Lev Gamaley · VP of Revenue Operations, Xtrm · Loomis, California
I build revenue systems. At Xtrm, a global payments platform, reducing headcount and improving throughput with custom automations, agentic builds and repeatable GTM motions.
01 Hood
A partner-recruitment audience for Anthropic's Claude Partner Network, built in Clay from two public directories. Three free gates ran before any paid enrichment, every point in the score traces to the thesis, and each of the 173 disqualified rows carries its reason.
02 Door
One formula column routes 87 accounts into three live tables, each with its own first touch. An Apps Script endpoint enforces two touches, a seven-day cooldown and daily caps where a mis-set filter cannot reach them, and a human approves every send.
DRY_RUN until ten drafts are read03 Seat
Xtrm has no SDR team. The outbound system I built on Alta runs six ICP campaigns with reply handling and CRM write-back. Thirty-seven Storylane demos replaced live walkthroughs for sales, support and the help center. Before this seat: two years as PM of the payments API, senior SE before that.
04 Dash
Row counts for the tables behind 01 and 02, read through Clay's public API and shown with their pull date. Below them, a corrections log: what I published, what was wrong, what changed.
loading snapshot
One lap. Twelve control boards on the road, one per thing that shipped; drive through the ring to collect it. W A S D or arrows, space for the handbrake, M mutes. On a phone, the buttons on the right. Scroll up to get out of the car.
Flying finish
The boards on the road are the things that shipped. The ones you drove through are checked; the rest are still on the road. Each opens its build log.
Built with Claude. Renders and clips generated with Higgsfield. Data from Clay. The car is a render of the finished build.
A partner-recruitment audience for Anthropic's Claude Partner Network, built in Clay from two public partner directories. The build order is what a partner team can reuse: three free gates before any paid enrichment, a score whose every point traces to a thesis claim, and a disqualified table with a reason on each of its 173 rows. 908 qualified accounts, zero enrichment credits, and an audit trail from raw directory row to final band.
fit_score_0_7, each point tied to a thesis claimfit_score_0_7.anthropic-icp-FINAL, 908 rows, 23 columns, 173 disqualified rows logged with a reason each.Anthropic sells through Snowflake and Databricks as much as it sells direct, and the consulting and systems-integration firms that deploy on those platforms are the recruitable layer. Not the Big Four. The 15 to 150 person shops that already have a Snowflake or Databricks bench and no model vendor they are married to. The thesis predicted a partner incentive-infrastructure gap. Five days after I wrote it, Anthropic posted a partnerships req whose core deliverable is commercial mechanics: deal registration, marketplace structure, incentives.
Bands inside the 908: 43 A-priority, 315 B-qualified, 550 C-long-tail. 42 accounts appear in both directories.
Every point in fit_score_0_7 traces to a thesis claim: Snowflake tier (Elite or Premier 2, Select 1), multi-homing across both directories (2), Americas region confirmed (1), source name unaltered by the cleaner (1), and a Databricks AI specialization badge (1). Top row: Aimpoint Digital, 7 of 7.
The Databricks AI specialization badge is a large-SI credential. Filtered to C&SI Partner plus AI, 19 of 1,419 companies qualify, and 17 of the 19 are Accenture, Avanade, Capgemini, Cognizant, DXC, EPAM, EY, Infosys and firms of that size.
So the badge cannot be a gate. Used as a gate it selects almost exactly the firms the ICP excludes. It works as a tie-breaking bonus point, and only two firms in the whole set hold it while plausibly sitting in the 15 to 150 band: Aimpoint Digital and Koantek. Same pattern as PRM-platform detection on Xtrm's own partner-program audience: a bonus signal, never the Keep or Flag gate.
raw_source_value is kept on every row for audit.PASS (presumed US, verify HQ).Segmentation that changes what the rep says, and guardrails that hold when a filter is set wrong. Eight firmographic cuts were rejected on one test (does the first sentence change, does the proof point change, does the recipient change); the three segments that survived each carry their own first touch. One formula column routes 87 accounts into three live tables. The send caps live in an Apps Script endpoint on the server, not in Clay's run condition, and a human ticks two boxes before anything goes out. Mode stays DRY_RUN until the first ten drafts have been read.
model_vendors with a quote and URLcortex_verified_by_human, send_approvedemail#touch idempotency, DRY_RUNstopsegment formula. On the outbound side, blocked_() in the endpoint.DRY_RUN until the first ten drafts are read.A filter tells you a row is different. A segment tells you the rep is different. The only question I let myself ask about a candidate cut: does the first sentence of the email change, does the proof point change, does the recipient change. If two of the three stay the same, it is a filter, and it goes.
Every firmographic cut (tier, cert density, headcount band, region, multi-homing) left the conversation unchanged. What changes it is what stands between the firm and putting Claude in front of a client. Three answers, mutually exclusive.
// Clay formula column: segment. Reads one upstream Claygent column, model_vendors.
model_vendors contains "Cortex" -> S1 Cortex Native
else contains OpenAI | Azure OpenAI | Bedrock |
Vertex | Gemini | Databricks -> S2 Committed Elsewhere
else contains "none found" -> S3 Practice on Paper
else (names Anthropic Claude only) -> UNASSIGNED, route to partner teamThree destination tables, each fed by its own Send table data action whose run condition is this column. Cortex wins ties on purpose: a partner already on Cortex is the shortest distance to revenue, so the competing vendor becomes the objection the rep handles rather than the bucket the account sits in.
S3 produces six accounts that clear every disqualifier, not ten. No vendor evidence and no shipped work turn out to be the same thinness measured from two directions. I reported 26 accounts to work now and four to track, four short of thirty.
// Apps Script endpoint. Runs on the server, not in Clay's run condition. A mis-set filter cannot get past it.
MAX_TOUCHES: 2, COOLDOWN_DAYS: 7, DAILY_SEND_CAP: 10, TOTAL_SEND_CAP: 25, MODE: 'DRY_RUN'
const idem = email.toLowerCase() + '#' + touch; // Clay columns re-run. This stops a duplicate send.
if (prior && prior.result === 'SENT') return json_({ ok: true, result: 'ALREADY_SENT' });
function blocked_(p, touch, log, email) {
if (touch > CONFIG.MAX_TOUCHES) return 'touch out of range';
if (truthy_(p.stop)) return 'stop flag set';
if (truthy_(p.replied) && touch > 1) return 'already replied, exits sequence';
if (!String(p.send_guard).startsWith('CLEAR')) return 'copy gate: ' + p.send_guard;
if (days < CONFIG.COOLDOWN_DAYS) return 'cooldown, ' + left + ' days left';
if (sentToday >= CONFIG.DAILY_SEND_CAP) return 'daily cap reached';
if (sentTotal >= CONFIG.TOTAL_SEND_CAP) return 'total cap reached';
return null;
}Clay's HTTP API column POSTs each row here. The script takes a lock, checks a shared secret, runs these checks, drafts or sends through Gmail, and returns the result so Clay writes status back into the row. A 15-minute trigger walks replies and POSTs stop, bounce or pending back to a Clay webhook. The log sheet is append-only.
cortex_evidence_check, Claygent: CONFIRMED, LIKELY, NOT_FOUND or UNCERTAIN with a verbatim quote and URL. The prompt says a false CONFIRMED is much worse than a NOT_FOUND, because a human is going to state this back to the company.cortex_verified_by_human, a checkbox, ticked only after I clicked the URL myself. Nothing downstream runs without it.email_draft, a drafting model with no web access, run condition on the checkbox. Eight columns are inserted into the prompt. final_grade, the ARR estimate and the exclusivity flag are excluded by name.banned_phrase_check, a formula, not AI: deterministic and free. Blocks partner-program language, pricing, "on behalf of Anthropic", "book a demo", and any em or en dash.send_approved, a second checkbox per row. The endpoint refuses anything that arrives without CLEAR.The systems that carry Xtrm's outbound and product education today, and the seats that taught me to build them. An outbound system on Alta doing the work of an SDR team the company does not have, a 37-demo Storylane library that replaced live walkthroughs, and the partner audiences in Clay that feed both. Before RevOps: two years owning the payments API as its product manager, and enterprise integrations as a senior solutions engineer. When something is missing, I build it.
Xtrm has no SDR team. The outbound system I built on Alta does that work. Six live campaigns, one per ICP, each ICP defined by the partner-incentive payout motion it runs (channel rebates, reseller incentives, rev-share payouts) rather than by industry code. Each campaign carries its own multi-step, multi-channel sequence, its own reply handling, and writes back to the CRM.
Thirty-seven interactive demos in Storylane, November 2025 to August 2026, built and kept current by me. They cover company and personal account signup, wallet creation and funding by bank transfer and bank debit, individual and mass payments, first-time recipient flows in USD and GBP, transfers out to bank, prepaid virtual debit and digital gift cards, connected-manager onboarding, identity-level upgrades, reporting, and the SPIF and MDF partner incentive payment flows. Each demo is a share link that support, sales and the help center point to instead of a live walkthrough.
Two years as the product manager who owned Xtrm's payments API, including the financial-institution vendor partnerships underneath it. Before that, senior solutions engineer: enterprise API integrations, Postman documentation, Salesforce custom objects, a PRM migration. When something is missing, I build it.
Row counts read from the Clay tables behind 01 and 02 through Clay's public API, rendered from that response with the pull date and source shown. Each table is listed with its id. Below the charts, a dated corrections log: what I published, what was wrong, and what changed. Six entries; one is a retraction, one is still open.
scripts/clay_pull.py, key stays on the serverRows remaining after each gate. Source: anthropic-icp-FINAL plus the logged disqualified rows.
| Gate | Rows |
|---|
Where the segment formula routed the 87 accounts. Source: the three destination tables.
| Segment | Accounts |
|---|
POST https://api.clay.com/public/v0/tables/query
clay-api-key: <server side, never in this page>
{ "query": { "tables": [ { "id": "t_0tkgaa2wuHGApf5CBas" } ], "field_mode": "names" },
"limit": 100 } // paginate with the returned cursor; count rows; keep the field listFive tables, one request per page. The key stays on the machine that runs scripts/clay_pull.py. The page ships the response, dated, and says whether the numbers came from the build logs or from api.clay.com.
raw_source_value retained on every row.