/playbook-new-in-role

name: playbook-new-in-role
description: Produces a copy-ready clause about someone who recently started or changed into their current job title. Triggers on "who just started", "new in role", "recently promoted", "new VP of X", "job change signal", "people who just took the seat". Outputs new_in_role_line, a lowercase clause that completes "Saw <line>."

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):

| Window | Rows | |---|---| | unfiltered | 1,662 | | 0 to 6 months | 22 | | 0 to 3 months | 2 |

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.

| | **Cheap pass (default)** | **Robust pass (opt in)** | |---|---|---| | Source | Prospeo `/search-person` | a LinkedIn Sales Navigator scraper on Apify | | Cost | effectively $0 for the data, $0.053 per 1,000 rows for the model | metered: roughly **$3.20 per 1,000 profiles** discovered plus **$4 per 1,000** hydrated to full profiles | | Tenure precision | **month-level.** `{min:0, max:6}` is an exact month range | **coarse.** A "changed jobs in the last 90 days" boolean, and a bucket that bottoms out at "less than 1 year". You cannot ask for 0 to 6 months | | Freshness | database snapshot, can lead a public announcement by about a month | LinkedIn-live, but **LinkedIn keeps stale results**, so a cleanup pass is mandatory | | Use it when | almost always | the client is high value, the vertical is one the database is thin on, or the campaign's whole premise is the job change |

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

| Field | Type | Source | Required? | |---|---|---|---| | target job titles | string[] | campaign brief / ICP | yes, this is the search input | | headcount range | {min,max} int | ICP | yes | | geography | string[] | ICP, as location strings like `"United States #US"` | yes | | recency window (months) | int | operator, default 3, ceiling 9 | yes | | `company_domain` (bare, lowercase, no `www`) | string | returned by the search | produced, not supplied |

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

| Field | Type | Example | Max length | Null allowed? | |---|---|---|---|---| | `new_in_role_line` | string | `you stepped into the COO seat at Northwind in April` | 90 chars | yes, empty string | | `role_change_type` | enum | `promotion` or `new_hire` | 9 | no | | `role_start_month` | string | `April 2026` | 20 | no | | `months_in_role` | int | `4` | n/a | no | | `prior_title` | string | `Chief Business Officer` | 120 | yes, empty string |

`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 t