/playbook-lookalikes

name: playbook-lookalikes
description: Turns one customer case study into the tightest list of companies that would read that case study and see themselves. Decomposes WHY the case-study company resonates into concrete attributes, translates those attributes into database filters, intersects them with a lookalike anchor, then widens with a model judge. Triggers on "find more companies like our best customer", "who would our case study land with", "lookalikes of X", "build a list around this case study", "companies like our happiest client", "expand this list, it is too small". Outputs a filter set plus one merge field naming which case study to cite.

Playbook: Case-Study Lookalikes (filter mining, not raw lookalike)

> 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:** a client has a case study, a flagship logo, or one obviously happy customer, and you want the list of companies for whom that story is the strongest thing you could say.

**Do not use when:** you are building a whole market from an ICP sentence with no standout customer to anchor on; or you want to name a customer off the **prospect's own** case-study page ("saw your work with Intercom") — that is the opposite direction and belongs to `playbook-case-study-page`.

See also `disco-like` in this repo for plain seed-domain lookalike discovery. **This playbook is the higher-precision version**: it mines *why* the story resonates before it searches.

**One-line output:** `case_study_ref = "attentive"` with `lookalike_case_study_line = "a marketing platform about your size"`.

⚠️ Merge-field collision warning

`playbook-case-study-page` pushes a lead-level field literally named `case_study_line`, whose value completes a **different** sentence (`Saw your work with Intercom.`). This playbook's descriptor is therefore named **`lookalike_case_study_line`**. **Never rename it back.** If both playbooks run on the same campaign, a shared field name silently overwrites and renders **"We did this for your work with Intercom."**

1. Trigger and scope

A case study only works on someone who **recognises themselves in it**. "We took an SMS marketing platform from 3 meetings a month to 22" lands hard on another marketing software company with a similar go-to-market, and lands on nobody else. So build the list **backwards from the story**, not forwards from the client's broadest ICP.

**The naive move is to paste the case-study company into a lookalike engine and ship what comes back. That was measured at 40% usable**: the vector matched on "is about marketing" and returned agencies, a marketing trade publication, and a Power BI blog alongside real software vendors.

**What this playbook does instead:** write down the 2 to 5 attributes that are the real reason the story resonates — in the worked example: B2B software vendor, product is marketing technology, US, 50 to 2,000 people — express each as a database filter, **intersect those filters with the lookalike anchor**, and read the result.

**That intersection measured 100% usable.** It is also small, which is the point: **the intersection is how you learn the filters and train the judge. It is not the final list.**

2. Output contract

Inputs

| Field | Type | Required? | |---|---|---| | `case_study_domain` | string, bare, lowercase | yes | | `case_study_text` | 200 to 2,000 words | yes — this is what the decomposer reads | | `client_offer_summary` | 3 to 6 lines | yes | | `geography`, `headcount_band` | strings | yes, always legal pre-filters | | `domain`, `company_description` | strings | yes, for the labelling half | | `exclusion_list` | CSV of domains | no, but **always ask** |

Output fields

| Field | Type | Example | Null? | |---|---|---|---| | `case_study_ref` | slug | `attentive` | no inside the segment | | `lookalike_case_study_line` | generic descriptor, ≤70 chars | `a marketing platform about your size` | yes | | `case_study_match_reason` | ≤140 chars, **QA only, never sent** | `sells customer engagement software to consumer brands` | yes | | `attribute_card` | JSON, **one per case study, not per row** | see §6 | no |

**Abstain value:** `""`. The gate is `qualified: false` paired with an empty `case_study_ref` — the two always agree.

The descriptor is generic on purpose

`lookalike_case_study_line` is deliberately a **generic descriptor, not the case-study company's brand name.** Naming a third party's brand in cold copy is a client-facing decision, and the descriptor form costs almost nothing: **"we did this for a marketing platform about your size" carries the same recognition as the brand name, and it never creates a permissions problem.**

Flip it to brand-naming only when the client explicitly okays it for a publicly published case study.

Coverage expectation

**10/10 usable (100%)** on the intersection path.

⚠️ **Read that number correctly. Coverage is near-total *by construction*, because the segment is defined by the filters, so every row in it matches the case study.**

**The metric that actually varies is segment size.** The tested intersection returned **21 companies**. The number to watch in production is not hit rate — it is whether the widening steps get you to campaign volume **without precision falling back to the 70% that unanchored keyword filtering produced.**

3. Source chain (cost-tagged)

Steps 1 and 2 fingerprint the case study. **Step 3 is the precision core.** Steps 4 and 5 are where volume comes from.

| # | Source | Cost | What it does | Stop rule | |---|---|---|---|---| | 1 | An internal company database, the case-study company's own record | FREE | read its description and offerings | always run. `found: 0` just means the decomposer works from the case-study text alone | | 2 | A company-search API on the case-study domain itself | FREE | **this is how the database tags it, which is the taxonomy your filters m