Playbook Case Study Page

Playbook: Case-Study Page Name-Drop

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 wants a first line that proves you looked at the prospect's site, and the prospect publishes customer stories — B2B software, agencies, consultancies, MSPs, staffing, manufacturers with named clients.

Do not use when: you want a tech detail (playbook-tech-on-website), their pricing model (playbook-pricing-page), or an ad they are running (playbook-ad-library).

One-line output: case_study_line = "your work with Intercom on outbound pipeline", rendering as Saw your work with Intercom on outbound pipeline.

1. Trigger and scope

Does this company publicly brag about a named customer, and if so which one, in words you can put in an email today?

The path list is ten, not four. /customers, /case-studies, /customer-stories, /success-stories, /case-study, /clients, /our-work, /portfolio, /testimonials, /stories.

This matters: in the live test one hit came from /testimonials, the ninth path. Any implementation that probes only the first four loses that row to a paid fallback.

It does not judge whether the customer is impressive, does not read individual case-study PDFs, and does not look for customers not published on the prospect's own site. If the client list is private, the correct output is an abstain.

Two things make this signal safe:

1. The model never writes the sentence. It only picks the customer and quotes the page. A script assembles the clause.
2. Every claim must appear verbatim in the page text you fetched, so a hallucinated logo cannot reach an inbox.

2. Output contract

Inputs required per row

Output fields

Only ship_ready = true rows get pushed. verified = true with ship_ready = false means the line is real but held for review.

Coverage expectation

6/7 rows usable (86%). Broken down: 5 produced a real line (4 ship-ready, 1 held at low confidence), 1 correctly abstained, 1 wrongly abstained on a carousel-layout page.

⚠️ Plan on the ship-ready number, not the usable number: 4/7 (57%) shipped without an operator touching them.

Expect lower coverage on SMB and trade segments, where most companies publish testimonials with no company named. Treat 50 to 60% as the planning number for a mixed B2B list, and 80%+ only for software and agency segments.

Copy-fit rules

• Slots into Saw {{case_study_line}}.
• The value always begins with the lowercase words your work with , then the customer's name in the customer's own capitalization, then optionally on plus a 2 to 5 word topic.
• No trailing period, no leading capital, no em dashes.
• The prospect's own company name never appears inside the value. The reader knows who they are.
• The value is assembled by a script, not written by the model, so these rules hold by construction rather than by asking a model nicely.

Downstream gate

If empty: drop the clause with spintax and keep the row. Never render Saw . — put the clause in its own optional sentence so the paragraph still reads when blank.

⚠️ confidence = low does NOT auto-ship

Low-confidence rows are held, and strict-quote mode is the default. The coverage cost is accepted on purpose.

A low row is a bare logo with no story attached — which is exactly the shape an investor logo, a press logo, a partner logo, and a CMS placeholder logo all take. The verbatim gates in §6 cannot tell those apart from a customer logo.

So every low row ships ship_ready = false and waits for an operator eyeball. To ship them, read a 20-row sample, confirm they are customers, then enable it deliberately. A low row never carries a topic clause even when it does ship.

3. Source chain (cost-tagged)

Steps 1 to 4 are the tested path and the only ones with a verdict.

Before you escalate, check the list size

Case-study finding is a research task, and for research a strong reasoning subagent generally beats a vendor browsing agent or a database when volume is modest and quality matters. In practice:

• Steps 1 to 4 stay first regardless of size. Ten free HEAD requests found the page on 6 of 7 rows. Nothing outranks free and measured, and a subagent is a worse tool than a HEAD request for a question a HEAD request answers.
• The leftover rows are where it bites. On a modest tail — the handful that fell through on a list of a few hundred — hand those rows to subagents, one per company. A subagent follows the trail when the obvious path 404s, reads the actual page, and abstains honestly; a one-shot vendor agent pads.
• Steps 5 to 7 are the SCALE answer, for when the tail is thousands of rows running unattended.
• Verification does not relax. A subagent's customer name faces the same verbatim gates. If the name is not in the fetched page text, it does not ship. "The agent said so" is not evidence.

Rejected alternatives

• A metered web agent as the finder. It costs credits per row to do what ten free HEAD requests already do at 6/7. Keep it for the leftover rows only.
• LinkedIn scrapers. Customer stories live on the company website, not on LinkedIn.
• Third-party review sites. Their customer lists are not the prospect's own claim, so the opener stops being "I read your site" and becomes "I read a directory" — exactly the tell you are avoiding.
• Asking the model to write the finished sentence. Measured: it lowercased proper nouns, copied a percentage out of the few-shot example onto a different company, and produced ungrammatical clauses.

4. Verification

VERDICT: PASS 6/7 (86% usable, 4/7 ship-ready) | claims 5/5 (100% correct) | ten-path HEAD sweep → model picker at minimal reasoning → deterministic line assembly | p50 2.4s/row | ~$0.18/1k.

Claim-bearing playbook: 70% usable AND 90% claim correctness. The single failure was a wrong abstain on a carousel layout — a coverage miss, which costs volume and nothing else. Naming an investor or a press logo as a customer is the failure the 90% exists to stop, and it is why strict quoting and the low-confidence hold are both defaults rather than options.

Page discovery alone scored 7/7 (6 found, 1 correct negative).

What this verdict does NOT cover

• The Clay recipe. Never run end to end.
• The homepage anchor scan. 0 of 6 discoveries.
• Chain steps 5 to 7. Never executed.
• The non-customer logo class. No row in the sample had an investor wall, a press strip, an integrations grid, or a CMS placeholder as its most prominent entity. The placeholder and context gates were unit-tested against a real page dump and a synthetic investor wall — a code check, not a live campaign result.
• ⚠️ "Verification" that re-runs the same check is not verification. A second pass that re-fetches the same URL with the same UA and runs the same substring check is a reproduction, not a second source. It can only confirm the string is on the page — which the code gate already guarantees — so it structurally cannot detect the partner, press, or placeholder-logo error class.

Read the 6/7 as "6/7 rows produced a line whose name is verifiably printed on the prospect's own page", not as "6/7 rows named a confirmed customer."

5. Clay implementation

• clay-table.md — the column build, including the domain-normalization trap that produces a 100% miss rate with no obvious cause.
• clay-workflow.md — the CLI-buildable version.