Playbook Hiring Surge

Playbook: Hiring Surge

All rules here are best practice, not law. Override any of them when the campaign calls for it; note the best practice once and move on.

Use when: the angle is "you are scaling this team right now".

Do not use when: you want the job ad itself (playbook-job-posting-language), the person who just started (playbook-new-in-role), or money rather than people (playbook-fundraising).

One-line output: hiring_surge_line = "your sales team has 8 people who started new roles in the last six months"

The three things you cannot get wrong

1. It is role starts, not hires. Measured 28.3% internal moves. The filter counts people whose current role started in the window — promotions, re-titles and lateral moves included. Ship started new roles; never hired, added, brought on.
2. Never buy a LinkedIn URL with enrichment credits to feed this. The company-enrichment action that returns one costs ~8 credits per company and was, by three orders of magnitude, the largest cost line here. Use a free LinkedIn URL off your intake payload where you have one, and the bare normalized domain everywhere else. Both are free.
3. The gate is a ratio PLUS absolute floors: role_starts >= 2 && dept_total >= 4. This cuts the qualifying segment from 14.6% to 5.2%, so plan roughly 96,000 source rows per 5,000-lead campaign. Do not loosen it to hit volume; source more rows.

1. Trigger and scope

A hiring surge is a department-level fact, not a company-level one. "This company grew from 200 to 260 people" is almost useless in copy, because the reader cannot tell whether it means anything to them. "Your sales team has 8 people who started new roles in the last six months" is specific, checkable, and implies a budget owner. This playbook produces the second kind.

The whole signal comes from one Clay table action, Find Employee Headcount by Criteria, which is free on every Clay plan. It counts how many people currently at a company match a filter set, and it accepts a recency filter (current_role_max_months_since_start_date), so running it twice per department gives you the department total and the department's last-6-months intake in one pass. No other vendor does department-sliced recency counts at zero marginal cost. That is why this playbook has exactly one source and no expensive fallback.

Four things it does not do

• It does not tell you who. Counts only. Names are a different, non-free action.
• It does not date the starts. The copy can only ever say "in the last six months", never "in March".
• It does not pick your departments. Sales and marketing are the two shown here; the same pattern extends to engineering, RevOps, customer success or finance.
• It does not prove anyone was HIRED. Read this one before you write copy.

The promotion confound, measured

The filter counts people whose current role started in the last 6 months. That set includes external hires, internal promotions, title changes and lateral moves. LinkedIn also generates a new role start date when someone merely edits or re-titles an existing position.

• Supported by the data: your sales team has 8 people who started new roles in the last six months
• Not supported, do not ship: you added 8 people to the sales team in the last six months

The second sentence is a factual claim about the reader's own team that they can disprove instantly if three of those eight were promotions, and cold copy does not survive that.

The over-count rate is measured: 28.3%. Of 276 people whose current role started inside a six-month window across 18 companies, 78 were already working at that company before the window opened. Sliced by title: sales-titled 24.4%, marketing-titled 34.6%. And that is a lower bound — the detector only sees a prior role that started 7+ months ago, so a February joiner promoted in July counts as a joiner. Real examples from the audit: a Business Development Representative who became a Mid-Market Account Executive; a Manager of Customer Success who became a Senior Manager; a Project Manager II who became a Project Manager III.

On one company in the audit, 5 of the 7 recent sales starters were internal moves — "you hired 3 people for sales" would have been wrong about most of the evidence behind it.

Treat every count as an upper bound on hires. Roughly 1 reply in 4 has a right to say "nobody joined my team, I was promoted", and the locked prompt is written so that reply contradicts nothing you sent. If a client insists on "you hired", show them the 28.3% first. That is an operator sign-off, not a default.

Re-measuring the confound on a new ICP is free (about 40 searches). Per company, run two people searches: one for current_role_max_months_since_start_date: 6 (the population the gate counts), one for everyone already there before the window (include_past_experiences: true with a role_range_end_month of YYYY-MM). Intersect on the LinkedIn profile URL: anyone in both started a new role at a company they already worked at.

2. Output contract

Inputs required per row

The action prefers a LinkedIn company URL — it is the identifier the underlying people dataset is keyed on. A bare domain forces a resolution step that can silently land on a different company, so the name-collision guard in §7 is mandatory on those rows.

The identifier waterfall, in order:

1. Free LinkedIn URL from your intake payload. Measured populated on 16.35% of rows.
2. Bare company domain on the other 83.6%. Free. Accept the collision risk, apply the guard.
3. If a client genuinely needs LinkedIn URLs resolved at scale, resolve them outside Clay with a domain-to-LinkedIn enrichment endpoint and webhook them in. Never buy them with Clay credits.

Stated plainly: on the 83.6% bare-domain rows the identifier is weaker and some counts will land on the wrong company. That is the right trade at 8 credits a row, but nobody has measured how much the bare-domain path degrades the 0.28% cell error rate — every measurement below was taken on rows identified by a purchased URL. Measure it if you run a large batch.

Output fields

hiring_surge_hires counts role starts, not hires. Nothing downstream may relabel it — including a copywriter editing the sequence by hand.

Abstain value: "" for the line and the department, 0 for the count. The counts themselves never abstain: a company with no sales team returns 0, which is a real answer.

Coverage expectation

Measured on 3,964 distinct companies:

Note how optimistic the 98-row sample was. Plan list size on 5.2%, not 17%. Filling a 5,000-lead campaign takes roughly 96,000 source rows.

The floors delete 64% of the gated segment, and that is the price of the precision they buy: on 20 held-out companies the gate with floors scores 17/20 (85%) against 10/20 (50%) without them. The rows they delete are the ones that would tell a two-person law firm its marketing team is scaling.

Copy-fit rules

• Slots into: Noticed {{hiring_surge_line}}.
• Second person only. The clause must never contain the company name. That removes the dependency on name cleaning and a whole class of capitalization bugs — a v1 prompt that allowed the company name and required a lowercase first letter produced "silktide added 8 people".
• Starts lowercase, no trailing period, no em dashes, under 90 characters, 5th-grade reading level.
• The time phrase is always "in the last six months" or "over the past six months". Never a month name, never a date, because the source does not carry one.

Downstream gate

If hiring_surge_line is empty: exclude the row from this campaign. This is one of the few playbooks where empty means exclusion rather than a spintax drop, because the entire campaign premise is the surge. Route excluded rows to a fallback campaign.

3. Source chain (cost-tagged)

Cost summary, per 1,000 source rows: four FREE columns plus about $0.0135 of model spend at the 14.6% gate rate, or $0.0048 at the floors' 5.2%. That is the entire cost. There are no enrichment credits in this chain. What remains is Clay table run time, which is why the free pre-filters are still worth running on a large intake.

On step 0, with the measurement

§1 argues company-level growth is nearly useless as a signal, and step 0 filters on exactly that. It was measured by taking companies whose gate outcome was already known and asking which sit inside the growth pool:

Converted to what matters against a 14.6% base rate: 17.6% inside the pool clear the gate against 13.7% outside. A 1.28x relative lift bought with about 76% of your TAM. Use it only when the TAM is at least 4x oversized. A min:200 variant showed 9.0% vs 12.0%, pointing the wrong way — do not use it.

The method is reusable and worth stealing. You do not need to run the expensive step on 400 new companies to answer "does this pre-filter predict my gate". Take companies whose outcome you already have, send their domains to the filter in batches of 200 to 500, and read the total count with and without it. Four calls instead of four hundred.

Rejected alternatives

• Per-company department counting via a people-search API. Measured: combining a company filter with a job-title filter returned NO_RESULTS on all three test companies while the unfiltered company query returned 53, 351 and 45 people. The title filter does not compose with the company filter the way you would expect, so a department count means paging the whole roster and regexing titles yourself. Fine for verification, far too slow for production.
• A company_headcount_by_department filter. The name is accepted but every inner shape tried returned INVALID_FILTERS. Shape unknown; worth a support ticket, since it would give a free department-level TAM pre-filter.
• Per-company LinkedIn scraping. It is per-company scraping where the Clay action gives a department count for free.
• Richer "employee trends" enrichments. ~10 credits per row for trend data you do not need for one clause. Only for a client who explicitly buys on headcount trend charts.