Proposals almost never lose on price. They lose because they list what you’ll do instead of arguing for what the client gets — and because the person who kills them was never on the call. This prompt fixes both, then attacks its own draft before your client does.
When a proposal loses, the feedback is almost always about price, because price is the polite reason. It’s specific, it isn’t personal, and it ends the conversation. It’s also, most of the time, not the actual cause.
What usually happened is one of three things. The proposal described your services instead of their problem, so the client had to do the work of connecting the two — and didn’t. The price had nothing to compare itself to, so $12,000 looked like $12,000 instead of looking like a fifth of what the problem costs them annually. Or the document reached someone who wasn’t on the call — a partner, a CFO, a sceptical colleague — and to them it read as a stranger asking for money.
None of those are price problems. They’re all writing problems, which means they’re fixable in the twenty minutes before you hit send.
It won’t write a proposal for a call you didn’t have. If your notes don’t contain the client’s problem in the client’s words, it stops and tells you — deliberately. That’s not a limitation to work around; it’s the most useful thing it does. A proposal built on your assumption of their problem loses to one built on their sentence, every time, and you cannot tell the difference by re-reading your own draft.
Replace the [BRACKETS]. Paste your call notes raw — messy, half-finished, in whatever shorthand you took them. Do not tidy them first, and the section below explains why that matters more than it sounds.
You are a proposal strategist who has spent fifteen years writing proposals in <span class="v">YOUR INDUSTRY</span>. You know that proposals rarely lose on price — they lose because they describe the seller instead of the buyer's problem, because the price has nothing to compare itself against, or because they reach someone who was never on the call. WHAT I'M SELLING - My business: <span class="v">NAME</span> - What I'd actually deliver: <span class="v">PLAIN DESCRIPTION OF THE WORK</span> - My price: <span class="v">NUMBER + STRUCTURE — e.g. "$12,000, 50% upfront"</span> - Why we're genuinely different: <span class="v">[ONE HONEST SENTENCE. Not "quality and service". If you can't answer this without a cliché, say so — that's a real finding.]</span> THE CLIENT - Company: <span class="v">NAME</span> - Who I spoke to: <span class="v">NAME, ROLE, AND WHETHER THEY CAN SIGN</span> - My raw notes from the discovery call: """ <span class="v">[PASTE YOUR NOTES EXACTLY AS YOU TOOK THEM. Do not tidy them. Their exact phrases matter more than your summary of them.]</span> """ METHOD — in order. Do not skip ahead to writing. STEP 1 — Read the call back to me. From my notes only, extract — in THEIR words, quoting where I wrote it down: - the problem they described - what it's costing them (money, time, risk, or reputation) - what they've already tried that didn't work - who else touches this decision - the deadline or event forcing this now If any of these is missing from my notes, say which and STOP. Do not fill the gap with something plausible. A proposal built on an invented problem loses to one built on their actual sentence, and I cannot tell the difference by reading my own draft. STEP 2 — Name what's missing. List what you'd need to know to write a proposal that wins, that my notes don't contain. Rank by how much each gap would cost me. I would rather make one more phone call than send a confident guess. STEP 3 — Name the real competitor. What are they actually choosing between? Us versus another supplier, us versus doing nothing, or us versus hiring someone internally? Be honest — "doing nothing" is the most common competitor and the one most proposals forget to argue against. If that's the real one, say so. STEP 4 — Write the proposal. 1. The situation — their problem in their words, precise enough that they feel heard rather than sold to 2. What it's costing — quantified where my notes support it; clearly marked as an estimate where they don't 3. What we'll do — led by the outcome. Deliverables appear underneath as evidence that the outcome is achievable, never as the pitch itself 4. Why us — tied to their specific problem. Not a capabilities list 5. Investment — <span class="v">PRICE</span>, placed directly against the cost from section 2 6. What happens next — one action, one date, one person Rules: - Never claim a result I haven't given you evidence for. No invented metrics, no "clients typically see", no borrowed case studies. - Mark anything you inferred rather than took from my notes with ASSUMPTION. - Match the reading level of my notes. If they talk plainly, don't write like a consultant. - Delete every sentence that would survive being sent to a different company. If it isn't specific to them, it's filler and it's costing me credibility. - No "we are excited to partner with you". Say what happens. STEP 5 — Now attack it. Re-read your own proposal as the client's most sceptical colleague: the one who wasn't on the call, doesn't know me, and thinks this is a waste of budget. Give me their three strongest objections, where in the document each one lands, and what I'd have to change to survive it. Be harsh. They will be.
The prompt does the structure. These decide whether the structure has anything true inside it.
This is the whole game, and everyone gets it wrong. Tidying replaces their words with yours. "Our stock system is held together with sticky tape" is worth ten times "inventory management inefficiencies", because when they read their own phrase back in your proposal, they know you were listening. Typos and half-sentences are fine. Their vocabulary is the asset.
It will stop and tell you your notes don't contain what the problem is costing them. The temptation is to say "just carry on" — and it will, cheerfully inventing a cost. Now your proposal has a fabricated number in section 2 and your credibility rests on it. Make the call instead. Ten minutes on the phone beats a lost deal.
If you can't answer it without saying "quality and service", the prompt has found something more valuable than a proposal: you don't have a differentiator, or you have one you've never articulated. Both are worth knowing before you spend an afternoon on a document that can't argue for itself.
Each one is a place the model filled a hole in your knowledge. Some are harmless; one or two are usually load-bearing claims about the client's business that you cannot support. Verify it, remove it, or ask them. Never send a document with an assumption tag still in it — and never just delete the tag while keeping the sentence.
The objections it raises are the ones your champion's colleague will raise in a meeting you're not invited to. You get to hear them while the document is still editable. That's the single highest-leverage twenty minutes in the whole process, and it's the step people skip because the draft already looks finished.
Every rule in it exists because a simpler version produced a proposal that lost. Understand the reasoning and you can rebuild this for any document you send.
Ask for a proposal directly and you get a well-structured document about a client the model invented. Forcing it to extract their problem first — quoting your notes — means the proposal is built from what was actually said. Everything downstream inherits that discipline or fails visibly.
The default behaviour of every model is to produce the shape you asked for, filling gaps with plausible material. In a proposal that's fatal — a fabricated cost figure in section 2 destroys your credibility the moment the client reads a number they know is wrong. Explicit permission to stop converts a silent failure into a phone call.
Most proposals argue "us versus them" when the real contest is "this versus the status quo, which is annoying but survivable". Those need completely different arguments. Getting this wrong means writing a brilliant case for why you beat a rival the client was never considering.
Section 5 must sit against section 2. A number alone is just a number, and the client's only reference point is their bank balance. A number next to what the problem costs them each year is a comparison — and comparisons are how people actually decide.
"Delete every sentence that would survive being sent to a different company" is the most aggressive rule here, and the most effective. Every generic sentence is a small signal that this document is a template — and clients read that signal instantly, even when they couldn't tell you why the proposal felt cold.
A model asked to review its own work will congratulate it. A model told to become a specific hostile reader — the colleague who wasn't on the call, doesn't know you, and sees a number — produces genuinely useful attacks. The role has to be adversarial and concrete, or you just get flattery in a different font.
| Variable | What good looks like | What breaks it |
|---|---|---|
[RAW NOTES] | Exactly what you typed during the call, including their phrases. The messier the better — you want their voice, not your summary. | A tidied paragraph you wrote afterwards. You’ve replaced their words with yours and thrown away the only real asset you had. |
[WHY WE'RE DIFFERENT] | Something a competitor couldn’t say. “We’re the only shop in the state with a technician certified on their exact system.” | “Quality, service and value.” The model will pad section 4 with nothing and you’ll ship it because it reads fine. |
[YOUR INDUSTRY] | Specific enough to change vocabulary. “Commercial refrigeration” beats “trades”. | Leaving it generic. You get consultant-speak instead of your industry’s plain language. |
[WHO I SPOKE TO] | Include whether they can sign. “Ops manager — needs the owner to approve over $10k.” | Just a name. The document gets written for one reader when it needs to survive two. |
| The STOP rule in step 1 | Leave it exactly as written. It’s the difference between a proposal and a plausible-sounding fiction. | Removing it, or telling it to continue anyway. You’ll get invented costs presented with total confidence. |
| Step 5 | Always run it. Even on a proposal you’re happy with — especially then. | Skipping it because the draft already looks good. Looking good is exactly when it’s most dangerous. |
Section 1 of a proposal for a composite client — a distributor whose stock system keeps overselling. Illustrative, not a real client's document. The difference isn't polish; it's whose problem is on the page.
“Thank you for the opportunity to partner with you. [Company] is a leading provider of end-to-end inventory management solutions. Our team of experienced professionals will work closely with you to deliver a bespoke, scalable system tailored to your unique business needs, leveraging industry best practices to drive operational efficiency and unlock growth.”
Every sentence here would survive being sent to a different company. That’s the tell — and the client feels it before they can name it.
“Last month you sold 40 units you didn’t have. Priya loses every Monday to reconciling stock by hand, and the system — in your words — is held together with sticky tape.
The part that isn’t on the invoice is the Bunnings account. You’ve said plainly that losing it over a stock error is the outcome you can’t absorb. That’s what this is really about, and it’s why we’ve scoped for accuracy first and reporting second.
Priya’s Mondays are roughly 48 days a year [ASSUMPTION — you said “her whole Monday”, we’ve read that as ~6 hrs × 48 weeks; correct us].”
"Their most sceptical reader is the owner who wasn't on the call. Objection 1: the Bunnings account is the emotional core of this proposal, but it came from one anxious sentence — if the owner doesn't share that fear, section 1 reads as manipulative. Objection 2: 48 days of Priya's time is your inference, not their number, and if it's wrong they'll distrust every other figure in the document. Objection 3: you've argued the problem is expensive but never that we specifically can fix it — section 4 is still about you."
It's a hole most people never see in their own draft, because they know why they're the right choice and their brain fills it in while reading. The client's brain doesn't. Hearing it from a hostile reader before you send costs twenty minutes; hearing it as silence after you send costs the deal — and you never find out that was the reason.
"Just write it anyway" gets you a proposal with invented numbers in it, delivered with complete confidence. The stop is a feature. Treat it as the prompt telling you the deal isn't ready, because that's exactly what it's telling you.
Deleting the tag doesn't verify the claim — it just hides it from you while leaving it in front of the client. Either check it, ask them, or cut the sentence entirely.
Reading aloud catches the tonal drift that scanning misses. If a sentence doesn't sound like something you'd say on the phone to this person, it doesn't belong in a document with your name on it.
It cannot manufacture a conversation you didn't have. Thin notes produce a thin proposal — and the prompt will say so at step 1 rather than let you find out from the client's silence.
This library is how we demonstrate what we do rather than describe it — the same way we'd build content for you. If you're weighing up whether AI belongs in your team's daily work, that's a conversation worth having, and Makura Academy exists for exactly it.
