Cut Your Proposal Turnaround From Hours To Minutes
The Weekly Build
Here's a pattern I see constantly with SME owners: proposal writing.
Say you run a small consultancy or agency. A lead comes in, and you need a proposal out fast, before they cool off and ring a competitor. That's the whole game.
Here's the before. Someone senior blocks out two hours, opens the last proposal that sort of fits, strips out the old client's name, forgets one instance of it, and sends a document that still says "Hi Sarah" to a client called Dave.
Pricing gets copied from memory, or from a spreadsheet nobody's updated since March. Scope gets written from scratch every time, because nobody trusts the template enough to lean on it fully.
By the time it goes out, the lead is two days cold. The moment that made them ring you has passed.
Multiply that by ten proposals a month and you've lost most of a working week to a task that barely changes shape from one client to the next.
So separate the parts that change from the parts that don't.
Build once. Your standard scope language, your pricing logic, your terms, all set up the once. Then feed Claude the call notes or transcript and have it draft the client-specific sections against that skeleton. Names, scope, price, timeline, done. Give it a five minute human pass to sense-check the numbers and tone, then send it.
Proposal writing was never really a writing problem. It was a template problem wearing writing as a disguise, and once you see that, the fix stops feeling like a big lift.
Sell the outcome and this is easy to picture. A proposal turnaround that used to eat an afternoon becomes something you finish before the coffee goes cold.
Now the failure mode, because there's always one. Someone builds this, tests it twice, loves it, and six weeks later a junior team member is manually rewriting half the output because nobody explained why the skeleton exists or what not to touch.
If the person using it needs a training manual, the interface is wrong. Three minutes of Loom showing the actual workflow beats a page of instructions nobody reads. That's a rule I hold to across every automation North Roots builds, not just this one.
Configure per client. That's the whole discipline.
This prompt takes your call notes and standard scope skeleton and drafts the client-specific sections of a proposal in one pass.
You are helping me draft a client proposal. I will give you two things: my standard proposal skeleton and the notes or transcript from a client call. Your job is to produce the client-specific sections only, written to slot straight into the skeleton.
MY STANDARD SKELETON (scope language, pricing logic, terms):
[PASTE YOUR SKELETON HERE]
CALL NOTES OR TRANSCRIPT:
[PASTE CALL NOTES OR TRANSCRIPT HERE]
Using these, draft:
1. A client greeting using their actual name and company, taken only from the notes
2. A scope section that reflects what was actually discussed, written in the same tone and structure as the skeleton's scope language
3. Pricing, using the skeleton's pricing logic applied to what this client actually needs. Do not invent figures that aren't supported by the skeleton or the notes
4. A timeline based on any dates, deadlines or urgency mentioned in the notes
Rules:
- Do not touch or rewrite the terms section. Leave it exactly as in the skeleton
- If the notes don't mention something you need (budget, deadline, decision maker), flag it as [MISSING: describe what's needed] rather than guessing
- Keep sentences short. This is a business document, not marketing copy
- Output in four labelled sections matching the four points above, ready to paste under my skeleton's letterhead and terms
If anything in the notes contradicts the skeleton's standard scope, flag it clearly at the top before the four sections, so I catch it before this goes out.This Week's Challenge
Open your last three proposals. Find the sentences that appear in all three, word for word. That's your skeleton.
Paste it into Claude with one real call transcript and ask it to draft the client-specific sections only. Names, scope, price, timeline.
You should have a working template by lunch, and your next proposal should take a fraction of the time the last one did.
SPONSORED Most Claude skills don't fail because the instructions are bad. They fail because the description is too vague to trigger reliably, a frontmatter field is missing, or the output format was never specified so Claude invents one. Skill-validator drops into a Claude project, reads your SKILL.md and returns a 0 to 10 score with the specific fix for every issue it finds. Scored one of mine a 4 and it was right about why. Free, permanently. Skill-validator
Forward this to one person who should be using AI better than they are. Reply with what you built, tried or broke this week. I read every one.
Gareth, founder of The Anthropic Stack (theanthropicstack.com)
No. Claude doesn't work for exploration anymore, only for bounded tasks and workflows. Speeding up a process that is broken makes no sense.