If you have ever stared at a blank document for 20 minutes trying to figure out where a proposal even starts, this post is for you. The bottleneck in proposal writing is not prose — it is structure. Once the outline exists, the writing is just filling boxes. Claude can generate that outline from a single paragraph of project background in under 15 seconds, and this tutorial shows exactly how to do it.
1. Why this matters now
Proposal writing is one of those tasks that looks like a writing problem but is actually a thinking problem. Most people sit down, try to write section one, realize they do not know what section two is yet, and either spiral into outline paralysis or produce a document that reads like a journal entry — chronological, personal, and structurally incoherent.
The real pain is not that people cannot write. It is that they spend the first 90 minutes of any proposal session just deciding what the sections should be. By the time structure is settled, the energy is gone.
What changed recently is that Claude, and similar reasoning models, are surprisingly good at inferring a logical consulting-style structure from minimal context. They have seen thousands of proposal patterns and can match your project type to the right skeleton almost instantly. The trick is knowing exactly what input to give and how to chain the prompts once the skeleton is up.
2. The core idea
Give Claude three facts about your project, and it will build the outline. You fill in the numbers.
The three facts are always the same, regardless of project type:
| Question | Example answer |
|---|---|
| What is the problem? | Our client's support team handles 800 tickets/day manually |
| Who is the audience? | Mid-market SaaS company, 12-person ops team |
| Why now? | They are hiring two more agents but unit cost is already unsustainable |
That is your entire brief. You do not need to know what the proposal will say yet. You just need those three sentences.
Claude will map them to a standard consulting flow — something like Problem Definition → Current State Analysis → Proposed Solution → Expected Outcomes → Execution Plan. That five-section structure covers roughly 80% of B2B proposals, whether you are pitching automation work, a new software system, or a process change initiative.
The analogy that clicked for me: it is like handing a project brief to a junior consultant on day one. If the brief is clear, they will come back in ten minutes with a reasonable deck structure. If the brief is vague, they will come back in two hours asking clarifying questions. Garbage in, garbage out — but a single focused paragraph is more than enough to be useful.
3. How to implement it
Step 1 — Draft your three-sentence background
Write this out in plain language before you touch Claude. Do not overthink it. One sentence per question, three sentences total.
Problem: Our client's support team handles 800 tickets/day manually with 24h avg response time.
Audience: Mid-market SaaS, 12-person ops team, VP of Operations is the decision maker.
Why now: Headcount budget is frozen; they need to scale throughput without new hires.
Step 2 — Generate the outline with section drafts
Paste your three-sentence background into this prompt:
claude "Build a proposal outline from the background below.
Include 5 sections in consulting structure.
For each section, write a 2-sentence draft placeholder.
Mark any missing data as [METRIC] or [CLIENT_NAME].
Background:
Problem: Our client's support team handles 800 tickets/day manually with 24h avg response time.
Audience: Mid-market SaaS, 12-person ops team, VP of Operations is the decision maker.
Why now: Headcount budget is frozen; they need to scale throughput without new hires."
Expected output (approximately 15 seconds):
1. Problem Definition
Current support operations process [METRIC] tickets daily with an average response
time of [METRIC] hours, creating measurable customer satisfaction risk. The team
has reached a structural ceiling that additional headcount alone cannot solve.
2. Current State Analysis
[CLIENT_NAME]'s support workflow relies on manual triage, routing, and response
drafting across [TOOL_NAME]. Each ticket touches an average of [METRIC] team
members before resolution.
3. Proposed Solution
An n8n-based automation layer will handle first-contact triage, sentiment
classification, and templated response generation for Tier-1 tickets. Human
agents retain full review and send authority.
4. Expected Outcomes
Target: reduce avg response time from [METRIC]h to under 2h within 60 days.
Estimated throughput increase: [METRIC]% without additional headcount.
5. Execution Plan
Phase 1 (weeks 1-2): workflow audit and integration mapping.
Phase 2 (weeks 3-5): build, test, and staged rollout with daily checkpoints.
Step 3 — Expand individual sections
Once the skeleton looks right, continue in the same conversation window:
claude "Expand section 2 'Current State Analysis' to 250 words.
Keep all [METRIC] and [CLIENT_NAME] placeholders intact.
Tone: professional consulting report, not marketing copy."
Verify the output still contains every placeholder unfilled — that is your signal that Claude did not hallucinate specifics. Do a quick search before you hand the draft to anyone:
grep -o '\[.*\]' proposal_draft.txt
If the grep returns nothing, Claude filled in numbers you did not give it. That is a red flag; review manually.
Step 4 — Fill placeholders with real data
Once every section has a 200–300 word draft, do one pass replacing every [METRIC] and [CLIENT_NAME] with real values from your discovery notes or client intake form. That final pass is typically 20–30 minutes, not 3 hours.
4. What to watch in production
Hallucinated metrics are the biggest risk. Claude will sometimes insert plausible-sounding numbers if the context implies them. The grep check in Step 3 catches most of this, but read every paragraph that contains a percentage or timeframe before sending.
Section order matters for different audiences. A technical buyer wants the solution architecture early. A CFO wants the ROI case in section two, not section five. After the initial skeleton generates, do not hesitate to reorder:
claude "Reorder the outline so Expected Outcomes comes before Proposed Solution.
Update any cross-references between sections."
Local models produce different skeleton styles. If you are running Ollama on a Mac Mini cluster or similar, smaller models tend to produce flatter outlines — fewer sub-sections, less differentiation between sections. For proposal work specifically, a model with at least 13B parameters handles structural reasoning well; below that, the output starts collapsing into a generic three-section format.
Context window continuity matters. All the expansion prompts in Step 3 depend on Claude remembering the outline from Step 2. Do not start a new conversation between skeleton generation and section expansion — the model loses the structural context and will produce generic drafts that do not match the skeleton.
Section length calibration by proposal type:
| Proposal type | Section count | Recommended length per section |
|---|---|---|
| Internal pitch (1-pager) | 3 | 100–150 words |
| Vendor proposal | 5 | 200–300 words |
| Government / RFP response | 7–10 | 400–600 words |
For RFP work, break the background paragraph into two separate prompts — one for the problem space, one for the compliance and evaluation criteria — and generate the skeleton in two passes before merging.
Closing
The structural bottleneck in proposal writing is a solved problem the moment you have three clear sentences about your project. Background in, skeleton out, drafts filled — the whole flow from blank page to reviewable first draft now fits in under an hour.
Next step worth trying: wire this into an n8n workflow that accepts a project intake form, fires the Claude prompt automatically, and drops the skeleton into a Google Doc. The manual version described here is already faster; the automated version removes the manual step entirely.
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: Code Intro
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기