A proposal is a decision document, not a writing exercise
A proposal has two jobs. It helps a prospective client decide whether your approach is a sensible response to their problem, and it gives both sides a reference point for what happens after approval. The first job rewards clarity and relevance. The second rewards boundaries.
That is why a beautiful AI draft can be dangerous. It can make an unfinished conversation look settled. A vague request becomes a confident “we will transform your growth.” A rough timeline becomes a date. A possible deliverable becomes a promise. A case study from a different client becomes implied proof. The words are polished while the commercial decisions remain unresolved.
I use AI at the points where structure is expensive: organizing notes, finding gaps, comparing options, rewriting for an executive reader, and preparing questions. I do not ask it to decide what the business can deliver or what the client should pay. Those decisions require the delivery team, financial model, leadership, and sometimes counsel.
The proposal anatomy I would build
Situation and objective. Start with what the client told you, not a generic description of your company. Name the problem, the affected audience, the business context, and the outcome the client wants. If a fact is inferred, label it as an assumption or ask the question.
Approach. Explain how you will work. A client should see the decisions, stages, inputs, and collaboration points, not just a list of activities. AI can turn notes into a clean sequence, but the subject-matter expert must decide whether the sequence is sound.
Deliverables. Name the artifact, format, owner, review point, and acceptance condition. “Strategy” is a theme, not a deliverable. “A 20-page positioning brief, one workshop, and a prioritized message matrix reviewed in a 60-minute session” is inspectable.
Assumptions and responsibilities. State what the proposal assumes about access, data, approvals, stakeholders, systems, and turnaround. State what the client must provide. This is where AI is especially useful because it can notice that a draft contains outputs but no inputs.
Exclusions and change control. Explain what is not included and what happens when the situation changes. Exclusions are not an act of distrust. They are how both sides prevent a scope conversation from becoming a disagreement after kickoff.
The scope table I want before pricing
| Field | Question | AI’s role |
|---|---|---|
| Outcome | What changes for the client? | Separate stated outcome from assumed outcome. |
| Deliverable | What will exist at the end? | Turn vague nouns into inspectable artifacts. |
| Dependency | What must happen first? | Find missing access, data, approvals, or owners. |
| Acceptance | How will both sides know it is complete? | Suggest questions; owner approves the standard. |
| Boundary | What is not included? | Flag implied work and scope-creep language. |
From discovery call to a usable brief
Do not paste raw discovery notes into a blank prompt and ask for a proposal. First separate the notes into client statements, observed facts, questions, possible interpretations, and internal comments. The model should not have to guess which sentence can be shown to the client.
I then ask for a discovery brief with six headings: the client’s situation, goals, constraints, stakeholders, decision criteria, and unresolved questions. I compare it with my own notes. If the assistant invented a goal or quietly turned a wish into a commitment, I correct the brief before drafting anything persuasive.
This step also protects the client relationship. A proposal that reflects the client’s actual words is more useful than a generic “we understand your needs” paragraph. It gives the client something to correct. Correction before pricing is cheaper than correction after kickoff.
Three options are useful only when they are genuinely different
AI is good at generating lean, standard, and expanded options, but the human team must decide what each option means. A weak options table changes adjectives while keeping the same work. A useful table changes the level of service, client involvement, risk, learning, or speed.
The lean option might answer the most urgent question with a narrow deliverable. The standard option might include implementation support and a review cycle. The expanded option might add research, testing, training, or ongoing optimization. Each should state the client responsibility, the dependency, the boundary, and the condition under which it makes sense.
I ask AI to identify where the options are not comparable. A lower price may exclude research. A faster timeline may require the client to provide content in two days. An expanded package may add activity without improving the decision. The assistant can surface these differences; the commercial owner decides how to present them.
Pricing stays outside the model’s imagination
Pricing is where proposal AI must stop guessing. A model does not know your cost base, utilization, subcontractor rate, delivery capacity, target margin, sales strategy, payment risk, or the value of a particular relationship. It may produce a number that sounds normal and is financially wrong.
I use an approved pricing model or a spreadsheet owned by the business. AI can help present numbers I provide, check that the same price appears consistently, explain a package difference in plain language, or generate questions about payment and change control. It does not set the price.
The same rule applies to results. The FTC says advertising claims must be truthful, non-deceptive, and supported by evidence. A proposal is not magically exempt because it is one-to-one communication. If you mention growth, savings, speed, conversion, or return, state what the evidence actually supports and what depends on the client’s execution.
Proof should make the client more confident, not more confused
Case studies work when the reader can understand the starting situation, the work performed, the timeframe, and the result. AI can organize an approved case study into a short proof block, but it should not merge results from several clients or remove a limitation to make the story cleaner.
I label proof precisely. “Client increased qualified leads by 28% over six months after implementing the agreed program” is different from “we generate 28% more leads.” The first describes a documented result in a defined context. The second implies a general guarantee.
If a statistic, testimonial, logo, or client name requires permission, that permission belongs in the proposal workflow. Do not allow a model to fill a proof section with plausible numbers. A blank proof section is safer than fabricated credibility.
Procurement and security questions belong in the first draft
Professional buyers may ask about data handling, subcontractors, insurance, security controls, intellectual property, support, termination, renewal, and acceptance. AI can read a proposal as a procurement reviewer and create a question list. That helps the seller involve the right owner before the client discovers the gap.
Do not let the assistant answer questions about security, compliance, or contractual rights from general knowledge. Give it approved company language and ask it to point out questions that need a security, finance, or legal response. The difference between “we are secure” and a specific, current control description matters.
Client notes can contain confidential information. Use an approved business workspace, a document system with the right permissions, or a redacted test set. OpenAI’s business documentation, for example, describes separate business data commitments; other vendors have their own terms and controls. Read the terms for the exact account and plan you are using.
The pre-send review I would never automate away
Before a proposal leaves the business, a responsible reviewer checks the client name, business facts, scope, deliverables, assumptions, exclusions, owners, dates, price, payment terms, proof, legal language, security claims, attachments, and approval status. That list is not bureaucracy. It is the last chance to catch a sentence that creates work or risk.
I also read the proposal as the client will: What do I receive? What must I do? What happens if I am late? What does success mean? What is not included? Who makes the decision? If those answers are hard to find, the proposal is not ready regardless of how polished it sounds.
Five prompts I would keep in the proposal workflow
1. Turn discovery notes into a proposal map
Use only the discovery notes below. Create a proposal map with client situation, stated goals, measurable outcomes, constraints, stakeholders, proposed approach, deliverables, client responsibilities, assumptions, dependencies, exclusions, decision criteria, and unanswered questions. Separate CONFIRMED FACTS from INFERENCES. Do not invent price, timing, results, or commitments.
2. Create three scope options
Using the approved service menu and discovery notes, create lean, standard, and expanded scope options. For each option list deliverables, client responsibilities, assumptions, dependencies, out-of-scope items, acceptance criteria, risks, and questions needed before pricing. Do not make the expanded option sound automatically better and do not invent hours or fees.
3. Find scope risk before sending
Audit this proposal for vague verbs, hidden deliverables, missing client responsibilities, unsupported outcomes, unclear owners, dependencies, dates presented as promises, pricing ambiguity, renewal assumptions, and change-request risk. Quote the section, explain the risk, and suggest a clarification question. Do not rewrite yet.
4. Make an executive summary honest
Draft a concise executive summary from these confirmed facts. State the client problem, the proposed response, the business outcome we are targeting, what success depends on, and the next decision. Do not claim guaranteed results, add a case-study statistic, or imply that approval has already happened.
5. Prepare a procurement question list
Read this proposal as a US procurement reviewer. List questions about scope, deliverables, acceptance, security, data handling, subcontractors, insurance, payment terms, renewal, termination, ownership, support, and change control. Distinguish questions answered in the proposal from questions that need a commercial or legal owner.
A 30-day proposal pilot
Week one: choose one repeated proposal type and collect three completed examples. Remove confidential details, identify the approved service menu, and write the pricing and approval boundaries. Measure baseline turnaround time, revision cycles, and scope changes after kickoff.
Week two: use AI only for discovery cleanup, question extraction, and proposal structure. Have a delivery person review the output. Record every invented fact, missing assumption, and useful question.
Week three: add options, proof blocks, and a pre-send audit. Compare whether the client asks fewer clarification questions and whether the proposal is easier for the delivery team to estimate.
Week four: decide what becomes a reusable template. Keep the prompt, source package, reviewer, prohibited data, storage location, and success metric together. A workflow is ready to scale only when someone else can run it and understand why the final proposal is trustworthy.
My final recommendation
AI belongs between discovery and review. It can make the middle of the proposal process faster and more thoughtful: structure the conversation, identify the unanswered question, compare scope options, explain the work, and test the draft from a procurement perspective.
It should not sit between your business judgment and the client’s decision. Keep price, margin, capacity, proof, guarantees, legal terms, and the final promise with the people accountable for delivery. The best proposal is not the one that says yes to everything. It is the one that makes a good-fit decision easier for both sides.