Playbook Pricing Page

Playbook: Pricing Page

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 needs to separate self-serve companies from sales-led ones, or needs a real price point to anchor an offer against.

Do not use when: you want technology installed on the site (playbook-tech-on-website).

One-line output: pricing_public = true with plans = [{"name":"Basic","price":"$10","period":"month"}, ...] and lowest_paid_price = "$10".

1. Trigger and scope

Does this business publish real prices on its own website, and if so what are the tiers?

It is used for filtering first and copy second. The most common job is splitting a list into product-led companies (public price list, card checkout, low ACV) and sales-led companies (every tier says Contact Sales) — because those two groups need completely different offers and completely different copy.

Bones only by default. No pricing line unless the campaign asks.

The deliverable is the structured record: pricing_public, pricing_model, plans, lowest_paid_price, has_free_tier, enterprise_quote_only, feature_diff_axis.

The one-clause string pricing_line is an opt-in extra, it is the weakest part of the output, and it should be stripped at the output boundary unless explicitly requested. A price in a stranger's inbox is a claim you have to be right about, and most campaigns using this playbook only ever wanted the filter.

It does not cover: what a prospect actually pays after negotiation, private rate cards, marketplace listings, or ecommerce SKU prices.

If every tier says Contact Sales, the correct answer is pricing_public: false — a real and useful signal, not a failure.

2. Output contract

Inputs required per row

Output fields

⚠️ quote_only and unknown are not the same thing

• quote_only — the page exists and every tier says contact sales. A confident finding you can filter on.
• unknown — you could not read the page at all. A failed fetch, not a finding. The row must not be filtered out on your say-so.

Collapsing these two is how a campaign silently deletes real prospects because of a network error.

Coverage expectation

8/10 rows produced a usable filtering record. The existence check alone was 10/10. That is the number to plan on, because the filtering record is the whole default deliverable.

The optional copy string was usable on 9/10 in the clean regrade but 6/10 once corrected on an earlier run — so treat it as a 70-to-90% field: spintax-optional, never mandatory. That spread is part of why it is off by default.

Downstream gate

Whether a pricing value removes a row is decided per campaign brief. This playbook produces the bones; the brief says what to do with them. Ask once, up front:

• Filter (pricing_public: false rows leave this campaign) — correct when the offer only makes sense for self-serve companies, or only for sales-led ones.
• Route (send those rows to a different campaign or offer) — correct when both halves of the list are sellable, which is the common case.

⚠️ Either way, pricing_model: "unknown" never removes a row. Only act on confidence: "high" findings.

If the brief is silent, route rather than delete, and say so in the handoff. Deleting rows is a client-facing, money-adjacent decision, and it is cheap to reverse a routing choice and expensive to reverse a deletion.

3. Source chain (cost-tagged)

If HEAD is refused, fall back to GET with Range: bytes=0-4095 — and accept any 2xx, because a compliant origin answers 206 Partial Content, not 200. A script that accepts only 200 silently records those domains as having no pricing page.

When "pricing analysis" is bigger than this chain

This playbook answers a narrow, mechanical question at 8/10 for a fraction of a cent, so do not route the per-row extraction to an agent of any kind.

But operators say "pricing analysis" for a second, genuinely different job: work out how this company actually charges and what that implies for our pitch — packaging logic, where the value metric sits, how it compares to a competitor, whether "contact sales" hides a floor. That is a research question, and for it a strong reasoning subagent per account generally beats a vendor browsing agent or a database lookup, when volume is modest and quality matters.

So: this chain for the structured record on every row; a subagent per account for the analysis on a modest set; a vendor agent only when you are buying scale. Either way the output contract and the claim gates still bind — a subagent's reading of a pricing page is a claim like any other and needs the URL and the quoted text.

Rejected alternatives

• A metered AI browse per row. It works, but it is credits per row for a job that a free HEAD plus a free GET plus a fraction of a cent of model does at 90%.
• Entity-search APIs. You already know the entity and the URL. Nothing to search for.
• A scraping marketplace actor. Expensive, and none beats a plain GET on a public marketing page.
• Search caches and third-party pricing aggregators. Stale by construction, and a stale price in an email is worse than no price.

4. Verification

VERDICT: PASS 8/10 (80% usable) | claims 8/8 (100% correct) | multi-candidate HEAD → plain GET + price-dense window → model JSON extractor | ~$0.50/1k domains.

This is a claim-bearing playbook: 70% usable AND 90% claim correctness. unknown is a failed fetch, not a finding, and a correct "this company does not publish pricing" is a correct outcome that leaves the denominator entirely.

Scope note: when the record is used only to route or filter, it is internal work and the plain 70% bar applies. The moment a campaign turns the copy line on, or quotes a price, the 90% bar binds.

⚠️ The earlier 9/10 is withdrawn, and you should know why

The first run was contaminated: three of the four few-shot examples in the prompt were verbatim the scraped text and the exact expected output of three of the ten graded rows — and the prompt had been rewritten after seeing first-pass failures on those same rows.

30% of the test had its answers in the prompt.

The 8/10 above is a clean regrade: invented example companies, and 10 domains that appear nowhere in the prompt. The clean number is lower, which is what you should expect whenever a contaminated number gets re-measured.

Rule for anyone editing a prompt in this library: a few-shot example may never be text from a domain that appears in the test set, and if you tune the prompt against failures on specific rows, you must regrade on different rows.

5. Clay implementation

• clay-table.md — the column build.
• clay-workflow.md — the CLI-buildable version.

The pricing cache

This is one of very few playbooks that earns a cache, because whether a company publishes self-serve pricing is a property of the domain rather than of the campaign, so one client's answer is reusable by the next. A row costs a multi-candidate HEAD sweep, a full page GET against the prospect's own server, and a long model grade (~3,850 prompt tokens).

Three conditions on any reused record, none optional:

1. Store last_checked and the resolved pricing_url with the record. A cached record with no date is not reusable, it is a rumour.
2. Re-fetch before a price goes into copy. The filter fields age reasonably; a dollar figure does not.
3. This covers records you extracted from live pages. It is not permission to read pricing from a search cache or an aggregator.

Two things that sink cache designs:

• Ship the write-back in the same pass. A cache with no writer can never hit.
• Pick a window short enough to stay honest. A stale "no public pricing" verdict on a company that has since launched self-serve is a confident wrong answer in a live email — worse than the fetch it saved. Do not reuse a long email-cache window without arguing for it.

6. Locked prompt

The prompt still produces pricing_line, and that is deliberate. The default run drops the field at the output boundary, rather than editing the prompt to stop asking for it. Editing the static prefix would invalidate the clean regrade this verdict rests on, cool the prompt cache, and force a full re-test to save a handful of output tokens. Keep the prompt byte-identical; drop the field in code.

Params: max_completion_tokens=6000, reasoning_effort="low", JSON response format, no temperature, flex tier for batch.

You are a B2B pricing-page analyst. You will be given the visible text of one company's pricing page, scraped from their website.

Your job is to decide whether this company publishes real, self-serve pricing, and to extract the plan structure. This is used to FILTER a prospect list, so a wrong "yes" is worse than an honest "no".

Return JSON only, with exactly these keys:
{"pricing_public": true|false, "pricing_model": "per_seat"|"usage"|"flat"|"credits"|"quote_only"|"unknown", "plans": [{"name": "...", "price": "...", "period": "month"|"year"|"one_time"|"unknown"}], "lowest_paid_price": "...", "has_free_tier": true|false, "enterprise_quote_only": true|false, "feature_diff_axis": "...", "pricing_line": "...", "confidence": "high"|"low"}

Rules:
- pricing_public is true ONLY if at least one plan shows a real currency amount on the page. A page that says "Contact sales" or "Request a quote" for every plan is pricing_public false with pricing_model "quote_only".
- Never invent a number. If a price is not in the input text, leave it out. Do not estimate.
- plans lists at most 6 plans, in the order shown on the page. Free tiers count as a plan with price "$0".
- Attach each price to the plan name it sits directly under on the page. Never shift a price up or down to the neighbouring plan. If you cannot tell which plan a number belongs to, leave that plan's price as "" instead of guessing.
- When a plan lists several seat types (full seat, dev seat, collaborator seat), use the FULL seat price for that plan and ignore the cheaper seat types.
- Take a price only from the plan card it belongs to. Ignore numbers that appear in body copy, footnotes or FAQs, such as a minimum invoice spend, an annual contract minimum, or a savings claim. If a plan says "Contact us" or "Talk to sales", its price is "" even when a large number appears in a sentence nearby.
- When a page shows a struck-through list price next to a limited-time promotional price ("50% off for 3 months"), use the LIST price, not the promotional one. A promo expires and would date the email.
- If the ONLY price shown for a plan is an introductory or limited-time rate ("$13/mo for 12 months", "first year", "then, starts at"), report that price, set confidence to "low", and leave pricing_line empty. An intro rate quoted as if it were the list price is a wrong claim in the prospect's inbox.
- lowest_paid_price is the cheapest list price a customer can actually pay, excluding free tiers and excluding promotions. Empty string if none is shown.
- feature_diff_axis is the single thing that changes between tiers, in 6 words or fewer, for example "seats and automation limits" or "monthly lead credits".
- pricing_line must read grammatically inside this sentence: "Noticed <pricing_line>." Write ONLY the part that replaces <pricing_line>. Do not write the word "Noticed" yourself, do not repeat the sentence frame, start with a lowercase letter, and do not end with a period. Keep it at a 5th-grade reading level.
- pricing_line names something only this company would recognise, such as the plan name plus its price. "pricing starts at $0 for the free plan" is too generic to use, so prefer the cheapest PAID plan.
- Only state a billing period in pricing_line if the page states one. If the page prices per unit with no period, say the unit, not "per month".
- No em dashes anywhere in your output. Use a comma or split the sentence.
- If the input text is a cookie banner, a login wall, a navigation shell, or is otherwise too thin to judge, return pricing_public false, pricing_model "unknown", confidence "low", and "" for pricing_line. Do not guess from the company name.

Examples (these four pages are invented, from companies that do not exist, so that no
example can ever hand you the answer to a page you are actually being asked to read):
Input: Northwind Ledger Pricing Starter $0 Free for small teams 3 workspaces Standard $7 per user/month Team $23 per user/month Enterprise Talk to us
Output: {"pricing_public": true, "pricing_model": "per_seat", "plans": [{"name": "Starter", "price": "$0", "period": "month"}, {"name": "Standard", "price": "$7", "period": "month"}, {"name": "Team", "price": "$23", "period": "month"}, {"name": "Enterprise", "price": "", "period": "unknown"}], "lowest_paid_price": "$7", "has_free_tier": true, "enterprise_quote_only": true, "feature_diff_axis": "seats and workspace limits", "pricing_line": "your Standard plan runs $7 a user each month", "confidence": "high"}

Input: Halden Systems Pricing Every deployment is scoped with our team. Book a walkthrough Request a quote Talk to sales
Output: {"pricing_public": false, "pricing_model": "quote_only", "plans": [], "lowest_paid_price": "", "has_free_tier": false, "enterprise_quote_only": true, "feature_diff_axis": "", "pricing_line": "", "confidence": "high"}

Input: Crate Studio Plans Sketch Includes: unlimited boards Studio Monthly Annual Full seat $29 /mo Builder seat $14 /mo Viewer seat $4 /mo Atelier Billed annually Full seat $68 /mo Builder seat $31 /mo Enterprise Full seat $115 /mo
Output: {"pricing_public": true, "pricing_model": "per_seat", "plans": [{"name": "Sketch", "price": "$0", "period": "month"}, {"name": "Studio", "price": "$29", "period": "month"}, {"name": "Atelier", "price": "$68", "period": "month"}, {"name": "Enterprise", "price": "$115", "period": "month"}], "lowest_paid_price": "$29", "has_free_tier": true, "enterprise_quote_only": false, "feature_diff_axis": "seat type and board limits", "pricing_line": "your Studio plan is $29 a seat each month", "confidence": "high"}

Input: Ferrous Growth Run every campaign in one place 30% off for the first year* $62 $43.40 USD per workspace / month, when paying monthly $54 USD per workspace / month, when paying annually
Output: {"pricing_public": true, "pricing_model": "flat", "plans": [{"name": "Growth", "price": "$62", "period": "month"}], "lowest_paid_price": "$62", "has_free_tier": false, "enterprise_quote_only": false, "feature_diff_axis": "billing period", "pricing_line": "your Growth plan lists at $62 a workspace each month", "confidence": "high"}

PER-ROW DATA (appended last)
PAGE DATA
Domain: <domain>
Pricing URL: <pricing url>
Visible page text:
<text>