Playbook New In Role

Playbook: New in Role

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 campaign angle depends on the buyer being new in the seat, because a new leader is rebuilding their stack, has budget to reallocate, and has not yet formed a vendor preference.

Do not use when: you want people who moved to a new company regardless of title, or you want the company-level hiring story. Use playbook-hiring-surge for headcount growth and playbook-fundraising for the "they just raised, so they are buying" angle.

One-line output: new_in_role_line = "you stepped into the COO seat at Northwind in April"

1. Trigger and scope

This playbook answers one question: which people in my target market took their current job title in the last N months, and what one sentence can I open an email with?

It is a filter-at-source signal, not an enrichment. You do not buy a list and then ask a vendor "is this person new?". You ask the people database to only return people whose current role started recently, and the answer comes back with the start date already attached. That is why it costs essentially nothing and why the false-positive rate on tenure is near zero.

Two things it explicitly does not do. It does not tell you whether the move was a step up, only that the person changed titles — a President who becomes COO trips the same signal, and the locked prompt is written so the copy stays true either way. It does not find the person's email; run your email waterfall first so you never spend enrichment on rows that will fail the email gate.

Pick your recency window

Default: 90 days, expressed as person_time_in_current_role: {min:0, max:3} (the filter is month-level, so 3 months is the month-level expression of 90 days).

Know the volume cost before you build the lane, because it is steep. Measured on one base (US, VP of Operations, headcount 50 to 1000):

Tightening from 6 months to 90 days cost about 90% of the rows on that base. A single title at 90 days is a handful of people, not a campaign.

Widen when the list is too thin, in this order:

1. Widen the title family. A measured five-title operations family returned 1,925 rows at 6 months versus 22 for one title on a comparable base. Titles multiply volume far harder than the window does. This is almost always the right fix.
2. Drop the headcount floor or widen the geography.
3. Widen the window to 6 months, and only then. Above 9 months the "just started" premise stops being credible and the copy starts lying, so 9 months is the ceiling regardless of how thin the list is.

Record the widening and the reason in the campaign brief.

Cheap pass or robust pass

Decide before you build. These are not the same product.

Worth internalizing, because it generalizes past this playbook: the expensive LinkedIn-live source has a coarser tenure filter than the free database. You buy freshness and coverage, and you pay for it in precision plus a mandatory cleanup pass. Never run the robust pass silently because the cheap pass came back thin. Say what it will cost, get a yes, then run it.

2. Output contract

Inputs required per row

Rows are produced by this playbook, not fed into it. If you already have a list and want to know which of those people are new in role, restrict the same call with company: { websites: { include: [ ...up to 500 domains... ] } }.

Output fields

role_change_type, role_start_month, months_in_role and prior_title are computed deterministically from the source's job_history array. The model never decides them. Only new_in_role_line is written by the model.

Abstain value: "" (empty string). Never "N/A", never "null", never a guess.

Coverage expectation

Read these as three separate numbers. They are not the same thing, and campaign sizing depends on telling them apart. Measured on 10 rows:

The single error was not a missing value and not a tenure error. The database asserted a title the company's own site contradicts, and the model faithfully turned that wrong fact into polished copy. No downstream verifier over your own output can catch this, because the output is a correct rewrite of a wrong input. See §6 for the optional cross-check.

The "zero false positives" result below refers only to tenure. It is not a statement about title accuracy.

Because the signal is a source-side filter, coverage on the rows it returns is high by construction. The number that varies is volume, not hit rate.

Copy-fit rules

• Slots into: Saw {{new_in_role_line}}. as the first sentence of email 1.
• Starts lowercase. No trailing punctuation — the frame supplies the period.
• Maximum 90 characters, 5th-grade reading level, no em dashes.
• Company name must be the short spoken form. "ATG", not "ATG (Auction Technology Group)".

Downstream gate

If new_in_role_line is empty: drop the personalized clause via spintax and keep the row — the row still matches the ICP. Do not leave a blank gap in the email. If the campaign's entire premise is the job change (a "congrats on the new seat" campaign), exclude the row instead and say so in the brief.

The empty case is the cheap case. The expensive case is the ~10% wrong-title case above, which arrives as a non-empty, well-formed line and therefore passes every structural QC.

There are two controls and they address different failures. Do not confuse them:

1. Title gate (free, mandatory) — controls loose-contains noise only. person_job_title is a loose contains match that can hit a past role, so the pull returns people whose current title is unrelated to the search (measured: a Chief Operating Officer query returned an "Adult Basic Education Instructor"). The gate drops those. It cannot catch a wrong source title — the one observed factual error had a job_history current title that did contain the target keyword, so the gate passed it and the wrong line shipped. Running the gate does not reduce the ~10% factual-error rate at all.
2. Leadership-page cross-check (cheap, optional) — the only control for a wrong source title. Cross-check the title against the company's own leadership page (see playbook-google-site-search). Turn this on for any client sensitive to being wrong about a prospect's title. If you skip it, budget for roughly 1 in 10 prospects receiving a confident but wrong statement about their own job.

3. Source chain (cost-tagged)

Step 1's body:

{ "page": 1,
  "filters": {
    "person_location_search": { "include": ["United States #US"] },
    "person_job_title": { "include": ["Chief Operating Officer"] },
    "company_headcount_custom": { "min": 50, "max": 2000 },
    "person_time_in_current_role": { "min": 0, "max": 3 }
  } }

max:6 is what was graded; max:3 is the default. The hit rate does not move with the window, only the volume does.

Rejected alternatives, and why

• ⛔ A CLI "find people" substitution. It returns only the latest experience, no job history, so role_change_type, prior_title and prior_company cannot be derived at all and the promotion-versus-new-hire branch disappears. Worth generalizing: "needs no browser" is not automatically the better path. When a substitution changes what comes back, that is a contract change, not a convenience.
• ⛔ Generic LinkedIn search APIs with no tenure filter. Common ones expose title, company, industry, location and school filters and no tenure, months-in-role, or start-date filter, so they cannot express this signal at any price. No subscription tier fixes that.
• Per-person "enrich" endpoints that would make a clean tenure check are frequently gated off standard plans. Check before designing around one.
• Scraping LinkedIn for tenure. Career history is already a structured field on the people database, so scraping is pure cost.
• person_time_in_current_company as the primary. It answers "how long at the company", which misses every internal promotion — and internal promotions were 8 of the 10 rows in the live test. Use it only as a secondary filter to separate new hires from promotions.