Build a Proposal Generator from a Case-Study Library

Workflow area: Sales · Tier: Advanced · Hands-on time: ~45 minutes

The reason proposals take days is not the writing — it is the hunting. Which case study fits a mid-market logistics prospect? Where is the paragraph about implementation timelines that legal already approved? A structured library turns that hunt into a lookup, and a well-framed prompt turns the lookup into a draft.

When to use — and when not to

• Use it when you send three or more proposals a monthbelow that, the setup cost outweighs the payoff; just keep a folder of your two best past proposals.
• Use it when proposals share a skeletonproblem, approach, proof, pricing, timeline. If every deal is genuinely bespoke consulting, build the library anyway but expect to write more fresh material per proposal.
• Skip it for RFP questionnairesthose are answer-by-answer responses against a compliance grid; pb-41 covers that workflow with NotebookLM.
• Skip the AI assembly for pricingthe model can insert a pricing structure, but never let it generate or adjust actual numbers. Prices come from your rate card and your judgment, always.

The recipe

1. 1.

   Build the case-study library in Notion first. Create a database with one entry per case study and these properties: Client industry, Company size, Problem, Solution summary, Results (with numbers), Quote, Approved for external use? (yes/no). Fill it from your last ten wins. If a result has no verifiable number, write "qualitative" — do not let a later prompt invent one. Add a second, smaller database of reusable blocks: company boilerplate, methodology description, implementation timeline, team bios.

2. 2.

   Extract library entries from old proposals with AI. Paste one old proposal at a time into Claude with:

   Copy

   Extract a case-study record from this proposal for my reusable library.
   
   Return exactly these fields:
   - Client industry:
   - Company size (employees or revenue band):
   - Problem (2 sentences, client's words where possible):
   - Solution summary (3 sentences):
   - Results: only numbers and outcomes stated verbatim in the text.
     If none are stated, write "none stated — needs verification".
   - Candidate pull-quote (verbatim from the text, or "none"):
   
   Rules: use only what is in the document. Do not estimate, round,
   or improve any number. Do not infer results that are not written.
   

   Paste each record into Notion, then verify the numbers against the source before marking it approved.

3. 3.

   Write the assembly prompt template. This is the generator. Save it in your prompt library (pb-05) and reuse it per deal:

   Copy

   Draft the "Relevant Experience" and "Proposed Approach" sections of a
   proposal.
   
   Prospect: [INDUSTRY, SIZE, e.g. "mid-market logistics firm, ~800
   employees"]
   Their stated problem: [FROM DISCOVERY CALL, 2-3 sentences]
   What we are proposing: [YOUR SOLUTION IN ONE PARAGRAPH]
   
   Case studies to draw from (use ONLY these):
   [PASTE 2-3 APPROVED LIBRARY ENTRIES]
   
   Reusable blocks:
   [PASTE METHODOLOGY + TIMELINE BLOCKS]
   
   Rules: Every claim about past results must come verbatim from the
   case studies provided — no new numbers, no "up to X%", no composite
   clients. Mirror the prospect's own problem language in the opening.
   Mark anything you could not source as [NEEDS INPUT]. British/Indian
   business English, no hype adjectives.
   

4. 4.

   Check the output against the library, line by line. Good output opens with the prospect's problem in their own words, cites two case studies with the exact numbers you provided, and leaves [NEEDS INPUT] markers where it lacked material. A sample of what the proof paragraph should look like:

   Copy

   For a logistics operator of similar scale (780 employees, Pune),
   we reduced invoice processing time from 9 days to 2 days within
   one quarter — the operations head called it "the first automation
   project that finished early." [Source: case study #7]
   

   If any number differs from the library entry by even a rounding step, the draft fails. Models "improve" 42% into "over 40%" or "nearly half" — both change the claim.

5. 5.

   Assemble the full proposal in Google Docs. Paste generated sections into your proposal template, add pricing yourself, and run one consistency pass: same client name throughout, same solution name, dates that agree. Then a colleague reads only the case-study claims against the Notion library — a five-minute check that catches the errors that lose deals.

Make it yours

• Tag by objection, not just industry. Add a Counters objection property ("too expensive", "we tried this before", "integration risk") — then pull case studies by the objection you heard on the discovery call, which targets better than industry match.
• Tiered library for team use. If the whole sales team shares the library, add an Owner and Last verified date per entry, and expire anything unverified for twelve months. Stale numbers in proposals are worse than no numbers.
• Claude Projects version. Put the approved library and reusable blocks into a Claude Project's knowledge, and the assembly prompt as project instructions — then each new proposal is just the prospect brief. Only do this with content already approved for external use.

Quality check

• Every result number matches its library entry exactlyno rounding, no "up to", no composites of two clients.
• Client names are approved for external useanonymous entries stay anonymous in the output.
• The opening mirrors the prospect's problem statementnot your product pitch.
• All [NEEDS INPUT] markers are resolved by a humannone survive to the sent version.
• Pricing was typed by youthe model never touched a number in the commercial section.