Does Claude decide the price?

No. Claude drafts the proposal and calculates the quote strictly from your own pricing.md rules, and it flags anything that needs a discount beyond your approved bands or a number it can't ground. The price and any discount clear whoever owns pricing — deal-desk or your manager — before it reaches the buyer. Claude prices from your rules; it never invents the number.

How does it make a proposal feel tailored instead of templated?

It builds from your discovery capture, so the proposal opens with this buyer's problem and outcome in their own words and ties the value to the proof points that matter to them. Mirroring their language from discovery is what makes it read as built for them — because it is — rather than a generic template with the logo swapped.

Is a Claude-drafted proposal safe to send as-is?

Treat it as a strong draft, not a final document. A proposal is near-contractual, so verify every price against pricing.md and every claim against value-prop.md, run the red-team step, and route anything legal, regulated, or non-standard past the right reviewer. You own what's promised — read the scope and terms as if you'll be held to them, because you will.

How do I keep the pricing and customer data safe?

Keep the discovery notes, your pricing.md or rate card, and the draft proposal in a workspace your company has approved, and never paste a customer's private context or your commercial terms into a tool you don't control. Both the buyer's data and your pricing are sensitive — handle them inside your approved environment.

The tailored proposal and pricing draft

when to reach for this

The proposal is where momentum goes to die. Discovery went great, then the quote takes three days, reuses a generic template, prices on guesswork, and reads like it's about you, not them. This system turns the discovery you already did into a tailored proposal fast: their problem in their words, the value tied to real proof, a scope and price grounded in your actual pricing, and the likely objections handled before they're raised — so you send something sharp while the deal is still warm. Claude drafts it; deal-desk and a human still own the number.

gather this first

The discovery capture for this deal (from The discovery-call system) or your notes — the problem, the scope they need, budget signals, and the decision process.
Your value-prop.md and proof points, and battlecards.md if you have it — the value claims and objection answers the proposal leans on.
Your real pricing inputs as a file — pricing.md or the rate card / packaging rules — and any approved discount bands. Claude prices from your rules; it does not invent a number.

the workflow

Frame the proposal around their problem, in their words

In Claude Desktop, open the folder with the discovery capture and your value docs and ask in the chat — no terminal needed. Before any scope or price, lock the framing: this proposal is about their problem and outcome, not your feature list. A proposal that opens with you is one that gets skimmed.

you ask

Read the discovery capture and value-prop.md. Draft the opening of a proposal: restate this buyer's problem and desired outcome in their own words, then the value we'll deliver tied to the specific proof points that matter to them. No pricing or scope yet — just the framing that makes the rest feel inevitable.

what you get back An opening that mirrors the buyer back — "You're losing two weeks per client to manual onboarding; here's the outcome and the proof we cut that to days" — so the proposal reads as built for them, because it was.

Echoing their own words from discovery is what makes a proposal land — it proves you listened and frames the price against their cost of doing nothing.
Build the scope and price from your real rules

Now the scope and the number — grounded strictly in your pricing inputs, not Claude's guess. The hard rule: it prices from pricing.md and flags anything it can't ground or that needs approval.

you ask

Using pricing.md and the scope from discovery, draft the scope of work and the pricing for this deal: what's included, the packaging/tier that fits, the price calculated from our rules, and any assumptions the scope depends on. If any line requires a discount beyond our approved bands or a number you can't ground in pricing.md, flag it for deal-desk rather than guessing.

what you get back A clean scope and a priced quote derived from your actual rules — with assumptions stated and anything out-of-band flagged for approval, not silently invented — so the number is defensible and the gaps are visible before it goes out.
Pre-handle the objections this proposal will trigger

Every proposal raises predictable pushback — price, scope, timing. Get ahead of it: address the likely objections inside the proposal and arm yourself for the negotiation.

you ask

Given this scope and price and our battlecards.md, name the 3 objections this proposal will most likely trigger (price vs. budget, scope gaps, 'why now'). For each, draft how to pre-empt it in the proposal text, and a separate note for me on how to hold the line in negotiation — grounded in the value story, no caving by reflex.

what you get back Objection-handling woven into the proposal (a value-framed answer to the price before they ask) plus a short negotiation note for you — so the predictable pushback is handled on paper, not improvised on a call.
Assemble, sanity-check, and prep the send

Pull it into one clean proposal, then have Claude red-team it and review the assembled file as a diff before it's saved. The final read catches the math error or the overclaim before the buyer does.

you ask

Assemble everything into one proposal.md: problem and outcome, value with proof, scope, pricing, terms, and next steps. Then red-team it: check every number and claim against pricing.md and value-prop.md, flag anything unprovable or out-of-band, and tell me the weakest part a skeptical buyer would attack. Show me the assembled file before you save it.

what you get back A polished proposal.md shown as a visual diff to accept, plus a red-team list — "the ROI figure on page 2 isn't in value-prop.md; the timeline assumes scope they didn't confirm" — so what you send is sharp and what's shaky is fixed first.

When Claude writes the file, Desktop shows it as an accept/reject diff — review the whole proposal in one place and confirm the price before anything is saved.

make it your own

Quote-only, fast turn: for a simple deal, skip the full proposal and run just the scope-and-price step against pricing.md for a clean quote and assumptions in minutes.
Arabic proposal, adapted not translated: for an Arabic-speaking buyer, build the proposal from an Arabic value narrative and localized proof — don't machine-translate the English. The framing, references, and formality that close in this region aren't the English ones rephrased; and have a fluent reviewer check it.
Feeds the follow-up: pair the sent proposal with The post-call follow-up system so the recap restates the scope and price and locks the next step.
Standardize it (Power Track): once your packaging is stable, save the scope-and-price step as a /quote command grounded in pricing.md so every rep prices the same way (see the Features tab).

watch out for

Claude never sets the price — your rules and deal-desk do. It drafts from pricing.md and flags what needs approval; it must not invent a number, apply a discount beyond approved bands, or commit a term. Every price and discount clears whoever owns pricing before it reaches the buyer.
Verify every figure against your sources. A proposal is a near-contractual document — a confident wrong price, an overclaimed ROI, or a scope line you can't deliver becomes a problem you're bound to. Check each number against pricing.md and each claim against value-prop.md before it sends.
A proposal carries the buyer's private context and your commercial terms. Keep the discovery notes, pricing.md, and the draft in your approved workspace, and never paste a customer's details or your rate card into a tool you don't control.
Claude drafts the proposal; a human owns what's promised. Read the scope, terms, and price as if you'll be held to them — because you will — and route anything legal, regulated, or non-standard past the right reviewer before it goes out.

you'll end up with A tailored, proof-backed `proposal.md` — the buyer's problem in their words, value tied to evidence, a scope and price grounded in your real rules, and objections pre-handled — drafted in minutes and ready for deal-desk sign-off, not an afternoon of template-wrangling.

Questions people ask

Does Claude decide the price?: No. Claude drafts the proposal and calculates the quote strictly from your own `pricing.md` rules, and it flags anything that needs a discount beyond your approved bands or a number it can't ground. The price and any discount clear whoever owns pricing — deal-desk or your manager — before it reaches the buyer. Claude prices from your rules; it never invents the number.
How does it make a proposal feel tailored instead of templated?: It builds from your discovery capture, so the proposal opens with this buyer's problem and outcome in their own words and ties the value to the proof points that matter to them. Mirroring their language from discovery is what makes it read as built for them — because it is — rather than a generic template with the logo swapped.
Is a Claude-drafted proposal safe to send as-is?: Treat it as a strong draft, not a final document. A proposal is near-contractual, so verify every price against `pricing.md` and every claim against `value-prop.md`, run the red-team step, and route anything legal, regulated, or non-standard past the right reviewer. You own what's promised — read the scope and terms as if you'll be held to them, because you will.
How do I keep the pricing and customer data safe?: Keep the discovery notes, your `pricing.md` or rate card, and the draft proposal in a workspace your company has approved, and never paste a customer's private context or your commercial terms into a tool you don't control. Both the buyer's data and your pricing are sensitive — handle them inside your approved environment.