The story-first proposal

​

Overview

A proposal pass with a composed pitch doesn’t have to read as a table of products and prices. When one composes, the pass opens on a story told in six parts, in this order:

1. What we heard: the buyer’s brief, played back in their own words.
2. Why us: the argument for why your storefront fits this brief, grouping two parts right beneath it: The value, the case for the price, and The limits, what your catalogue genuinely doesn’t cover.
3. The plan: the products, each led by the reason it’s in the plan rather than its name and price alone — and, under each product, what you’re buying: the property each placement runs on, how much delivery capacity you’ve actually made available for its window, and — where you’ve taught your agent who the audience is — the audience facts themselves, with their source.
4. Proof: a case study from your own product marketing that matches this brief, when one does, plus How we’ll know it worked, how success on this plan will be measured.
5. Terms: the flight, the budget, and the guarantee mix, stated directly.
6. The ask: what happens next if the buyer books it, refines it, or tests it.

The product table is still there underneath. Nothing about the plan is restructured, and every fact still carries the same “fed by” receipts it always has. The story is a different reading order for the same pass, not a second copy of it: the demand inbox ledger row and the full pass both render this exact arc from the exact same pitch, never two versions that can drift.

​

Where each part comes from

Shaped by names the endorsed pair the agent followed and gives its reason, or says that none fit. A reusable Library slide appears as a block with its source named; it is not rewritten as pitch text.

​

The plan, specifically: what you’re buying

A product row in the plan states its mechanics — guaranteed or non-guaranteed, a rate — but mechanics alone don’t say what the buyer is actually purchasing. A product can also be backed by more than one avail (a homepage takeover made of several daily slots, say), so what you’re buying lists a placement line PER AVAIL — never merged into one row that would misattribute delivery to the wrong property or blend disjoint windows into a fabricated range. Each placement states three things, resolved by your storefront’s own data rather than composed by the pitch:

• The property. Which property in your Property Roster this avail actually runs on, and the specific placement within it, when one is named. An avail whose Property Roster selector matches more than one live property (for example, a tag-based selection) lists every one of them, up to 8 — never just the first — since all of them carry that avail’s delivery. A selector matching more than 8 shows the first 8 plus “+N more properties” rather than an unbounded list. When the property can’t be resolved yet, the row says so directly and offers a way to name it — never a guessed property.
• The available delivery. This states what your feed currently reports as available for this avail’s own window — impressionsCapacity minus whatever is already held or booked — never a guarantee: no hold exists on an avail until a buyer’s booking actually places one, so the same capacity stays open to any buyer until then. When the product’s entire backing is this one avail, the row says “full slot available”; every other case states the net available impression count directly (“up to N impressions available”). A genuinely sold-out avail says so plainly with its actual window (“sold out · Jan 1 – Jan 31”, or “no impressions currently available” for a partial listing) rather than the “available” wording a zero would otherwise fall into. Where the price is a flat rate, the effective CPM that rate works out to is shown alongside it — except when any of the product’s backing avails is missing OR listed but unresolved, since dividing the full price by a known-partial delivery total would overstate it; that line is omitted rather than shown misleadingly cheap.
• The window. The exact dates this avail’s own delivery covers — never unioned with another avail’s window.

Below the placement lines, the audience lists facts about who the audience is, drawn from your product marketing claims that match the product, each with its source (capped at 5 facts per product, 24 per response — a large response can run a later product out of budget, which reads as no facts for that product rather than a false “your agent hasn’t been taught anything”). Either cap — a product matching more than 5 facts, or the response running out of its 24-fact budget — shows a “showing the first N audience facts” note rather than letting a shortened list read as complete. A claim you scoped to a channel and/or a creative format only matches a product that actually carries that channel and format; when a product’s channel or format can’t be determined at all, only your UNSCOPED claims still match it. When you haven’t taught your agent an audience fact for this product yet, the row says so plainly and offers a way to add one — never a generic audience description. A storefront with a very large claim corpus is read up to its own scan bound; if a matching claim exists beyond that bound, this row renders silently (the same way a response-level budget cap does) rather than showing a confident “you haven’t taught anything” that the corpus may not actually support. Today, placement and delivery resolve for inventory fed through a static avails feed. A product sold through another connection (an ad server sync, or an embedded sales agent) states its property and delivery honestly as not yet resolved, rather than guessing — support for those connections is coming. If one of a product’s backing avails has since been archived or deleted, the row says plainly that some placements could not be resolved rather than letting the avails that did resolve stand in as the whole product — a missing avail never upgrades the remainder to “full slot available”. The same honest “some placements could not be resolved” line covers a product backed by more than 12 avails (only the first 12, in the product’s own declared order, are shown) and a product with MIXED backing — some avails plus another connection (an ad server sync, or an embedded sales agent) — where the avails-feed portion resolves normally but the other connection’s share of the product is not yet resolvable, so it is disclosed the same way rather than letting the resolved avails read as the product’s complete backing.

​

Proof, specifically

Proof is the one part that doesn’t come from the pitch itself: it’s your own case-study story, matched independently, by the same rule that page describes: the brief has to point at it by naming the advertiser, matching the industry vertical, or matching a channel. A brief that doesn’t point at any story draws none in. When a story matches, Proof shows the challenge, the method, and the results verbatim: each measured outcome together with who measured it, exactly as your case study records it. Nothing is paraphrased and nothing is added: what you confirmed on your product marketing page is what shows up here.

​

Honest absence, every time

Every part of the story is independently omittable, and absence is never filled in:

• No matching case study? Proof says so plainly — “No case study matched this brief yet” — with a way to add one, rather than showing a made-up example or a generic one that doesn’t fit.
• A thin Why-us? If your storefront’s Playbook and product marketing gave the pitch little to argue from beyond the headline thesis, the section reads thinner and offers a way to teach your agent more — never padded with invented reasoning.
• No pitch at all? The whole story arc is skipped. The pass renders exactly as it did before pitches existed — the plan, and nothing invented around it. See When there’s no pitch at all.

​

Try a brief

You don’t have to wait for a real buyer request to see your storefront’s story-first proposal. On your product marketing (Teach) page, Try a brief lets you paste brief text and see what your agent would compose for it:

1. Paste a brief — real or hypothetical — into the box and run it.
2. Your agent composes a real proposal and pitch for it, through the same path a live buyer request takes, tagged as a practice run.
3. It opens immediately as the story-first proposal, so you can read it end to end right there.

A practice run is never billed and never sent to a buyer — nothing about it is a real pursuit. Because it’s tagged as practice rather than real demand, it does not appear afterward in your demand inbox list, which shows only live buyer activity. There is no separate history view for practice runs yet, so this is the one chance to read it — reopen Try a brief and run it again if you want another look.

​

Related