> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.
# The story-first proposal
> When your agent composes a pitch, the proposal pass reads as a case for this buyer — what they asked for, why you, the plan, proof from your own case studies, the terms, and the ask — and you can try it yourself with a practice brief.
## Overview
A [proposal pass with a composed pitch](/v2/storefront/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.
4. **Proof**: a case study from your own [product marketing](/v2/storefront/product-marketing/overview)
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](/v2/storefront/demand-inbox#where-fed-by-comes-from) it
always has. The story is a different reading order for the same pass, not a
second copy of it: the [demand inbox](/v2/storefront/demand-inbox) ledger row
and the full pass both render this exact arc from the exact same pitch, never
two versions that can drift.
This is the same [composed pitch](/v2/storefront/pitch) described on its own
page: the seven-part argument, what it can cite, and why it reads plainer
when your storefront gives it less to argue from. This page is about how
that pitch, plus one matched case study, reads together as one story on the
pass.
## Where each part comes from
| Part | Comes from |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| What we heard | The buyer's brief, mirrored back — see [the pitch's "What we heard"](/v2/storefront/pitch#the-seven-parts). |
| Why us | The pitch's thesis, value case, and limits — argued only from your inventory, Playbook pricing, and Playbook instructions. |
| The plan | Your products, each led by the pitch's fit argument for that product (its role in the plan) instead of its catalog description. |
| Proof | A case study confirmed on your [product marketing page](/v2/storefront/product-marketing/overview#case-study-stories), matched to this brief by advertiser, industry vertical, or channel, plus how success on this plan will be measured. |
| Terms | The plan's own numbers — the buyer's committed budget, the flight window, and how many of the plan's products are guaranteed. |
| The ask | The pitch's invitation — what you're proposing the buyer do next. |
## Proof, specifically
Proof is the one part that doesn't come from the pitch itself: it's your own
[case-study story](/v2/storefront/product-marketing/overview#case-study-stories),
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](/v2/storefront/pitch#when-theres-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](/v2/storefront/product-marketing/overview),
**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](/v2/storefront/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
The seven-part composed argument this story is built from.
Case studies, selling points, and where Try a brief lives.
The ledger and the proposal pass the story renders on.