Demand inbox

​

Overview

The demand inbox is your storefront’s front-of-house ledger: one place that answers what demand came in, how did my agent respond, and did we win? Each row is one buyer brief your Merchandising Agent answered, joined to the proposal it produced and the commercial result that followed. It is the human-readable scoreboard on top of your intelligence runs. Every number is computed only from what actually happened. A metric with no inputs yet reads as unavailable — never a fabricated 0. A historical brief captured before canonical artifact persistence reads as artifact unavailable rather than being reconstructed.

​

The metrics strip

​

The ledger row

Each row carries the brief, the buyer, when it came in and went out, who led the response (agent or human), the buyer’s feedback, the commercial result (won, lost, or pending), and your letter grade.

• Result derives from that brief run’s own attributed commercial outcome: a forwarded or delivered buy is closed_won, a rejected buy is closed_lost, and anything still in flight (or not yet attributed) is pending. A booking attributed to a later renegotiation pass is not rolled up here (see the scope note above). There is no separate result to keep in sync — it always reflects the run’s real state.
• Grade, feedback, and led-by are seller-authored annotations you record against a row. Grade and feedback default to empty; led-by defaults to the agent, since every composed response is agent-led until a human takes it over.

​

Where a brief came from

Not every brief arrives as a live AdCP call from a buyer agent. Each row carries its provenance so you always know what you’re looking at: An uploaded brief never masquerades as live buyer demand: no buyer is recorded unless you confirmed the buyer from the document, no buyer is contacted, and nothing is booked. It counts on the scoreboard by the same rules as any other brief — an uploaded brief has no commercial outcome until you record one, so it stays pending and never inflates your win rate.

​

Uploading a brief into chat

When a brief reaches your sales lead by email or attachment instead of by API, you don’t need a form. Drop the document into the Murph composer. Murph reads it, shows you the demand brief it recognized (unconfirmed), and — if the upload includes a media kit — tells you in chat what the kit claims that your storefront can and can’t back. Nothing is written or run until you confirm. When you confirm, the brief runs through the same product-discovery and composition path a buyer’s agent would trigger, and the exchange appears here as an uploaded row that drills into the proposal pass like any other. To change an uploaded exchange, upload or paste a corrected brief and confirm it — that produces a new exchange. The original keeps its honest record and stays annotatable (grade, feedback, result).

​

The proposal pass

Open a ledger row to see the full story of that exchange — the proposal pass. It answers what exactly did my agent propose, from what brief, and how did the exchange evolve? The pass shows:

• The brief, as a business document. It leads with the advertiser, who it came through, and the buyer’s ask in their own words, then the few facts a commercial decision turns on: budget, flight, markets, channels, how they want to transact, and how long you have to respond. Requirements follow as plain sentences — placements, exclusivity, currencies, policies, the metrics they expect back, performance standards and verification vendors — then where it has to run: regions, metros, an approved property list by name, keywords, and the advertiser catalog. A field the buyer did not send is simply absent; you are never shown a row that says nothing.
• Condensed brief facts appear only while the complete brief is loading, if its read fails, or for historical rows with no artifact link. They are an honest fallback, never a reconstructed substitute for the request.
• A composed pitch, when your storefront has one for this pass. The pass opens on a written argument — the thesis, what the buyer’s brief asked for, the plan told as roles instead of rows, how you’ll know it worked, the value case, the honest counter, and what’s next — before the product table, which moves under a Plan appendix heading beneath it. A pass with no composed pitch renders exactly as it always has: the plan, and nothing invented around it. See The pitch.
• The plan, as the products you sent. The plan’s name, its scale, and its argument for the brief come first, then one line per product with its price and its share of the plan. Expand a product to see why it is in the plan, how it is priced (including every option offered and where the plan’s selection sat against market guidance), where it runs, who it reaches, and what it reports.
• What fed each decision. Expand a product row to see which of your own ingredients your agent consulted when it built that line: the inventory it selected, the audience it layered on, and the rate-card entries it priced against. Tap one to open the thing that owns it — the source it came from, or your Playbook — change it there, and the pass refreshes. Underneath the table, a second group names what fed the whole response rather than one product: the Playbook version it composed under, and the terms resolved for that buyer. See Where “fed by” comes from.
• Per-product money appears when the buyer committed a single exact budget — each product’s share of that amount, in the plan view and in the pass history. Against an open range or a lone ceiling/floor you see shares only: a proposal commits to a split, and money arrives when the buy is created.
• Technical details, one disclosure at the foot of each. Artifact id, schema, digest, source, capture size, run linkage, redactions, truncation evidence, and the exact structured request or response — copyable, and identical to what an agent reads. Both the human view and the exact artifact come from the same immutable capture; there is no separately maintained presentation model.
• Pass history for every recorded response, with the buyer-facing price and plan allocation per product. Selecting a pass opens its full plan above.
• A refine-pass timeline and the commercial outcome for the exchange.

Every number on the pass is traceable to a persisted brief/proposal artifact or outcome record; an input that wasn’t captured reads as unavailable rather than being reconstructed. A capture can also be truncated: the proposal was recorded but part of it exceeded the storage cap. The pass says which — product rows still render when the response survived and only the per-product snapshots were dropped, and a pass whose response itself wasn’t stored is labeled as a truncated capture, never described as predating capture.

​

Where “fed by” comes from

“Fed by” answers the question a proposal has to survive: why these products, at these prices? It is a record of what your agent actually consulted while composing, written at the moment it composed. It is not a summary the agent writes about itself afterwards, and it is not reconstructed from the finished proposal. Two things follow from that, and they are the reason you can trust it. It is scoped as honestly as the decision was. Some ingredients are chosen per product — the inventory a line is built from, the audience layered on it, the rate-card entries priced against that exact combination. Those appear on the product row. Others are resolved once for the whole response — the Playbook version in force, and the terms that applied to that buyer. Those appear under the table, labelled as feeding the whole pass. Nothing is promoted from one group to the other to make a row look better-explained than it is. It is history, and history is not rewritten. A chip names the ingredient as it stood when the proposal was composed, including its name at the time. Renaming a rate-card entry later, editing your Playbook, or deleting a source never changes what an earlier pass says fed it. If you tap a chip for something you have since deleted, you are told plainly that it no longer exists — you are never sent to a stand-in for it. That check is exact: removing one product or audience from a source you otherwise kept is enough, and a same-named entry on a different source is never treated as the one that fed the decision. And it only ever says “deleted” when it actually checked and found nothing: if the check itself cannot complete, the chip simply becomes un-tappable rather than telling you something was removed when it may not have been. What each chip names: A few honest limits:

• A pass that predates this shows no chips. Responses composed before your agent started recording what it consulted have nothing to show, and the row simply does not expand. Nothing is inferred for them.
• A response you adjusted yourself shows the inventory and audience it composed from, and no rate-card chips. An adjustment re-resolves your inventory but is priced from the adjustment you declared, so there are no rate-card entries to name.
• Your marketing material is not yet an ingredient. Your media kit and buyer-facing story do not currently feed composition, so they never appear as a chip. When they do, they will appear here like everything else.
• Some chips name something you cannot open. Inventory reached through another seller’s storefront belongs to them, not to a source of yours, so its chip names what fed the decision without a place to go. Buyer terms are the same: they are shown for context and managed on the buyer. A chip whose owner we momentarily could not look up behaves the same way. None of the three is described as deleted, because none of them was.
• Buyer terms appear only when they actually applied. Terms that matched the buyer but were held back — because the request carried no account, or because the row set neither a discount nor a note — did not shape the response, so they are not listed as having fed it.

​

Adjusting a proposal

Open a proposal pass and, if the exchange qualifies, you can Adjust it: declare a posture, a price adjustment, and a product-count cap, and re-compose the proposal through your storefront’s real merchandising engine — without leaving the page. This is the same declaration grammar the Merchandising Simulator already taught you in a zero-risk room; Adjust reuses it rather than asking you to learn a second way to describe a change. Adjust is available only on live, retained, adjustable demand. When it isn’t, the button is disabled and names exactly why: A stale page or a direct API call gets the same named reason — never a bare “not found.”

​

Draft, then Send

Composing an adjustment produces a draft revision. A draft is silent by construction: it holds no proposal artifact and no delivery state, so nothing is visible to the buyer until you send it. Declining the sheet leaves no record at all; discarding a draft leaves only its own terminal audit entry — neither counts against anything you’d notice. When you’re ready, Send routes the revision through the same approval setting you already use for media buys — the campaign-approval capability and its manual/auto dial, relaxed for a buyer you’ve explicitly trusted with per-buyer auto-approve. There is no separate approval system to configure.

• If your storefront auto-approves (or the buyer is trusted), the send clears immediately.
• Otherwise it queues for a colleague to approve or reject — and whoever drafted the revision cannot clear their own send. You can always reject or withdraw your own submission (that creates no buyer-visible evidence), but sending it requires a second person. A rejected revision returns to draft, and resubmitting it clears the earlier decision entirely — a revision awaiting a decision never shows a decision that hasn’t actually been made against it.
• A cleared send becomes a real pass on the exchange, labeled seller-adjusted and attributed to the person who sent it — it renders through the same pass card as everything your agent proposed, never a second layout.

Every exchange has a lifetime limit on how many adjustments it can produce — counted over every revision you’ve ever composed on it, including ones you discarded. Compose-and-discard doesn’t reset the count.

​

What “sent” actually means to the buyer

Be direct with yourself here: sending a revision does not notify the buyer’s agent. We investigated whether a follow-up proposal could reach the buyer through the existing exchange, and today it can’t — there is no delivery lane for a subsequent proposal, and no honest staging/preview lane either. A sent revision is recorded truthfully: it appears in your pass history as sent, not delivered, and the page says so outright. If you need the buyer to actually see the new terms, you still have to reach them the way you would today — a message, a call, or a fresh brief exchange.

​

What Adjust doesn’t do

A draft never issues a rate hold and never converts into the buyer’s stated currencies — that’s what an actual buyer-facing response does, and a discardable draft must not create that kind of durable, buyer-facing state. The draft does record the settlement currency and the buyer’s stated currencies as of when you composed it, purely for your own reference.

​

What counts as one exchange

An exchange is grouped from persisted linkage only: one composition pass and the proposal artifacts recorded against it. Byte-identical or refine briefs are not grouped by their content hash (a hash collides across unrelated pursuits and diverges across refines), and there is no persisted cross-run lineage yet — so a renegotiation is its own ledger row and its own exchange today. Each exchange therefore reads as a single composition pass, disclosed honestly on the pass itself. The exchange-level result follows an explicit rule: won if any pass in the exchange is won; otherwise lost if the most recent decided pass is lost; otherwise pending. With one pass per exchange today this is simply that pass’s outcome.

​

Money

Each row shows the buyer’s stated budget range exactly as it arrived on the brief (buyers state it in filters.budget_range; when a buyer doesn’t, the column reads absence rather than a guess). A won row also shows the won value — the delivered spend when reporting exists, otherwise the booked media-buy budget — always in the money’s own currency, never converted. The Booked YTD tile totals this year’s won money per currency; multiple currencies are disclosed rather than summed together. On the proposal pass, the exchange carries a per-currency won value when it won (one entry per currency, never summed across currencies). A lost exchange still surfaces the buyer’s stated budget as lost demand — the size of the opportunity you didn’t close — so a loss is legible, not blank.

​

Filters

Filter the ledger by buyer from the widget header to focus on one relationship. Sector filtering is not available yet — sector is not captured per brief today.

​

Related