Proposal automation
How to use AI to write proposals from your own past work.
Your first attempt produced something generic. Here is the part that was missing.
Short answer
An AI proposal writer is a system that drafts a client proposal from your meeting notes, using your own past projects, pricing history and templates as the pattern. The output is a first draft your team edits, not a finished document.
It works when it has your real material to work from. It produces generic filler when it does not, which is why most first attempts disappoint. The work is in the context, not the prompt.
Why your first attempt was generic
Almost everyone tries this the same way. You open a chat window, paste in some notes, and ask for a proposal. What comes back is structurally correct and completely hollow. It reads like a template because that is effectively what it is: the model had nothing of yours to work from, so it produced the average of every proposal ever written.
The conclusion people draw is that AI cannot write proposals. The correct conclusion is that a proposal is mostly recall, and you gave it nothing to recall.
Think about what you actually do when you write one. You remember a similar job from two years ago. You go and find what you charged. You reuse language that worked. You pull images from a project that looked like this one. You apply pricing rules nobody has ever written down. Then you format it. Only one of those steps is writing, and it is not the slow one.
What a real proposal system does
Five stages. The generic attempt skips the first three, which is exactly why it fails.
1. It starts from the actual conversation
Input is the meeting: a transcript, call notes, or the intake form the client filled in. Not a blank prompt. Everything downstream is derived from what was really said, including the constraints people mention in passing and forget to write down.
2. It finds comparable work you have already done
This is the step that makes the difference. The system searches your own history for jobs that resemble this one: similar size, similar scope, similar client type. Those comparable projects become the evidence base for both the content and the numbers.
A proposal grounded in four jobs you actually delivered is a different object from one invented out of nothing.
3. It builds the numbers before it builds the document
Price it, then write it. Always that order.
This sounds obvious and is routinely done backwards. If the document is produced first, the numbers get retrofitted to the design, and you end up with a beautiful proposal describing something you cannot deliver at that price. Worse, once a draft looks finished, nobody wants to change it.
Putting a deliberate stop after the budget, where a human reviews the numbers before any document exists, is the single most useful piece of structure in the whole pipeline.
4. It assembles the document in your format
Your template, your sections, your tone, your images. Not a tidy generic layout. If your proposals go out as a branded deck, the output is that deck, populated. The point is that your team opens something that already looks like their work.
5. A human finishes it
The output is a first draft. Somebody who knows the client reads it, fixes what is wrong, adds the judgment the system cannot have, and sends it. That step is not a limitation to be engineered away. It is where the proposal becomes yours.
What you need before this works
Here is the part most articles on this topic leave out, because it is less fun than the demo.
- Past proposals you can actually find. Not scattered across four people's laptops. If finding last year's version takes twenty minutes, the system has the same problem you do.
- Pricing that exists somewhere outside one person's head. A rate sheet, a cost spreadsheet, historical quotes. Something with numbers in it. This is the most common blocker, and it is usually solvable in an afternoon.
- A template worth populating. If every proposal is structured differently, decide on the structure first. That decision is yours, not the system's.
- Clarity on what varies. Which parts genuinely change per client, and which parts you rewrite every time out of habit. The second category is pure recoverable time.
- Images or examples, if your proposals are visual, and some way to tell them apart. A folder of twelve thousand untagged photos is a real obstacle, and tagging them is its own project. Be honest about that up front rather than discovering it halfway in.
If several of those are missing, the first phase of the work is not AI at all. It is getting your own material into a state where any system, human or otherwise, could use it. That phase is genuinely valuable on its own, which is a reasonable consolation.
What it gets wrong
Anyone who tells you this runs unattended is selling something. The recurring failure modes:
- Confident wrong pricing. It will produce a number that looks plausible and is not. This is why the budget review step is mandatory rather than optional, and why estimates should carry their assumptions visibly instead of arriving as a single figure.
- Stale comparables. A price from three years ago is not a price today. The system needs to know how old its evidence is, and so does the person reviewing it.
- Confusing what was quoted with what was delivered. Proposed, sold, and actually-cost are three different numbers. If your records do not distinguish them, your estimates will drift toward whichever one happens to be recorded.
- Wrong-but-reasonable images. Visual matching is the least reliable part. Expect to swap images. Also check nothing carries another client's branding, which is an easy and genuinely embarrassing mistake.
- Reading as competent and slightly soulless. The draft will be fine. Fine does not win work. Your closing paragraph, the thing only you know about this client, still has to be written by you.
What it actually saves
Not the writing. The searching, the copying, the first-pass estimating, and the formatting.
In my own business, the judgment calls still take exactly as long as they always did, and they should. What disappeared was the forty minutes of assembling a document and the hour of hunting for what a comparable job cost. The first draft arrives already shaped, and the work becomes editing rather than starting.
The honest framing is that this does not make proposals write themselves. It removes the part of proposal work that was never the skill.
There is a second-order effect worth naming: when the first draft is cheap, you stop avoiding it. Proposals that would have been delayed until the weekend go out on the day of the call. For most small businesses, speed to a first draft is worth more than the hours saved.
When not to build this
- You send fewer than a couple of proposals a month. The setup will not pay back. Use a good template and a chat window.
- Every job is genuinely unprecedented. If there are no comparables, the system has nothing to learn from and you are back to generic.
- Your pricing is the product. If pricing is a negotiation rather than a calculation, automate the document and leave the numbers alone.
Otherwise, if proposals are eating your evenings and the information exists somewhere in your business, this is usually the highest-value first build. It is the one I would start with, and it is the one I started with myself.
Questions
Asked and answered.
Can AI write a proposal from a meeting transcript?
Yes, and a transcript is the best possible starting point because it contains the constraints people mention in passing and never write down. But a transcript alone produces a generic document. The transcript tells the system what this job is; your past proposals and pricing history tell it how your company responds to a job like this. You need both.
Why does AI write such generic proposals?
Because a proposal is mostly recall, and a blank chat window has nothing of yours to recall. Without your past work, your pricing and your templates, the model produces the average of every proposal ever written, which is structurally correct and completely hollow. The fix is context, not better prompting. Give it four comparable jobs you actually delivered and the output changes character entirely.
Will it get the pricing right?
Not reliably enough to send unreviewed, and you should not design it to. A good system estimates from your real cost data and comparable jobs, shows the assumptions behind each number, flags what needs a real vendor quote, and then stops for a human to approve the budget before any document is produced. Confident wrong pricing is the main failure mode, so the review step is structural rather than optional.
How long does it take to build a proposal system?
Weeks rather than months for one workflow, assuming your past proposals and pricing are findable. If they are scattered or your pricing lives only in someone's head, the first phase is organizing that material, and that phase is often the larger one. It is also worth doing regardless, since the same groundwork makes every later system possible.
Do I need a custom system, or will ChatGPT do?
If you send a few proposals a month, a good template plus a chat window with a couple of past examples pasted in will get you most of the way. A custom system earns its cost when the volume is high enough that assembly is a real weekly cost, when the pricing logic is complicated enough to be worth encoding, or when the proposal has to be produced in a specific branded format every time.
What about images and visual proposals?
Image matching is the least reliable part of the pipeline, so plan to swap some. The bigger issue is usually that the image library is not tagged, which makes retrieval guesswork. Tagging is its own project and worth scoping separately rather than discovering midway. One rule that matters commercially: check that nothing carries a previous client's branding before it goes out.
Proposals
eating your evenings?
Thirty minutes, free. Tell me how yours get made and I will tell you how much of this you could do with the tools you already pay for, and what would actually need building.