How to Automate Consulting Proposals with AI Without Losing Quality

I spent my consulting years on the wrong side of a lot of proposal deadlines. Not the thinking part, which was the good part. The part where it is late, the deck is on version seven, and someone is still digging through a shared drive for a CV that is current enough to send to a client.

So when people ask me whether AI can write a consulting proposal, I think they are asking the wrong question. AI is not the bottleneck in a bid. Finding trustworthy evidence, agreeing on what you are actually promising, and getting it through partner review. That is the bottleneck. Automation only helps if it attacks that.

Here is the workflow we would build if we were running a bid desk today.

Why most proposal automation disappoints

A proposal looks like a document problem. It is not. It is a decision system that happens to arrive as a PowerPoint file.

Before anyone touches a slide, the team has to decide whether to bid at all, what the client actually needs, which of your experience is genuinely relevant, who leads, what you are willing to promise, how it is priced, and which formal requirements are not negotiable. The slides are just the visible end of that reasoning.

Weak automation skips all of it. You start with an empty prompt and a big folder, and you get exactly what you would expect: generic text, credentials that quietly overclaim, a mandatory question nobody noticed, and slides that look finished long before the thinking is.

The fix is not a better prompt. It is separating four kinds of work and being honest about which ones a machine should own.

Notice that the last row is not automated at all. That is deliberate.

The workflow

1. Start with a clean RFP record

Store the original request, the attachments, the clarification emails, the submission channel, the deadline, the client entity, the language, the confidentiality level, and the version. Somewhere in your firm there is a file called Final_v7.pdf. It is not version control.

If you bid for public contracts, the formal requirements can decide admissibility before anyone reads your argument. The rules differ by procedure, but the operational lesson is the same everywhere: capture the mandatory conditions separately from the persuasive content. They are different objects with different failure modes.

2. Build a compliance matrix before anything else

Pull every question, required statement, attachment, format rule, page limit, declaration, signature, and deadline into one table.

This matrix is the control layer between the RFP and the deck. Let AI populate the first draft, since it is good at this and the work is tedious. Then have a human confirm completeness before any creative work starts. A missed mandatory question found on day two costs nothing. Found on submission day, it costs the bid.

3. Agree the bid thesis in one paragraph

Before a single slide exists, write the central argument down:

The client needs to deliver X despite Y. We recommend Z because our team combines A, B, and C. The first measurable outcome will be D within E, subject to the assumptions listed.

This is the step teams skip, and it is the step that decides whether the proposal is any good. It forces you to be specific. It also gives the automation a stable decision context. Without a thesis, any system, human or machine, drifts toward a catalogue of everything you can do instead of an answer to what the client asked.

4. Let the model retrieve, never invent

A proposal knowledge base has to be structured, not just searchable. Full text search over a shared drive is how you end up citing a project reference from 2018 that the client never approved for reuse.

Each CV record needs the person, role, office, availability, languages, capability tags, the approved biography, the experience statements they are allowed to claim, the photo and layout variant, an owner, an approval status, a last review date, and any consent or geography constraints.

Each project reference needs the approved client name or anonymized label, industry, capability, problem, approach, outcome, team, geography, the evidence owner, the permission level, the approved metrics and wording, the completion date, and a review date.

That is a lot of metadata. It is also the only thing standing between you and a confidently fabricated client logo. The model retrieves records. It does not manufacture substitutes. Every claim keeps a stable record ID all the way into the deck.

5. Review the storyline as text

A sequence that works for most proposals:

1. Our understanding of the situation and the decision in front of you.
2. What success should look like.
3. The recommended approach and workplan.
4. Why this approach fits your constraints.
5. Team and governance.
6. Relevant experience and proof.
7. Deliverables, timeline, assumptions, and commercials.
8. Compliance appendix.

When the RFP prescribes a response structure, that wins. Compliance outranks your house style, always.

And review this as plain text first. Challenging ten page titles takes twenty minutes. Challenging ten fully formatted slides takes an afternoon and someone gets defensive about the layout they just built.

6. Give the drafting step real constraints

The difference between a useful generation instruction and a useless one is specificity about sources, not eloquence about the topic:

Draft slides 4 to 9 for requirement IDs RFP 2.1 to RFP 2.4. Use only project records PR104 and PR221 and methodology version M12. Preserve the approved client wording where quoted. Each slide needs an action title, evidence, and a source footer. Mark missing evidence as [OPEN]. Do not create pricing, staffing availability, client names, or outcome metrics.

Scope, permitted sources, protected content, output rules, and an explicit list of things it may not invent. Five elements. They make the output reviewable instead of merely plausible.

7. Generate into your actual PowerPoint template

Master, layouts, typography, colors, icons, legal pages, appendix conventions. Native text, shapes, tables, and charts that stay editable.

This is not a formatting preference. The first draft is never the deliverable. Partners rewrite action titles. The team changes. Assumptions move. Pricing gets updated two hours before submission, and it always does. If the output is flattened or lives in a web viewer, every one of those normal, expected edits becomes rework in a tool nobody wants to fight at 11pm.

8. Run three reviews, not one

These are three different jobs, and one tired reviewer will silently collapse them into a visual proofread.

Compliance review. Is every requirement answered, in the specified place and format? Declarations, attachments, signatures, page limits, filenames and deadline, all correct?

Evidence review. Is each credential accurate, current, permitted, and relevant? Is team availability confirmed? Are the outcomes, client names, and qualifications real? Can the reviewer trace every material claim back to a record?

Persuasion review. Does the proposal actually make a choice? Does it show understanding, or does it recite the RFP back to the client? Is the approach feasible? Are the differentiators supported? Would an executive understand why this team is the lower risk option?

Assign them to different people if you can.

9. Freeze, then learn

Lock the submitted version, record who approved it, and archive the compliance matrix together with the evidence set. Keep updating the source library as facts change, but never overwrite the exact records that went into a submitted proposal. You will want them later.

After the decision, capture structured feedback: shortlisted or not, strengths, weaknesses, price position, missing evidence, client objections, and which content needed heavy rework. That feedback should improve your workflow and your source library. It should not become uncontrolled training material built on client documents.

Who owns what

Good automation makes these responsibilities more visible, not less. If your process ends up with a new unnamed owner called "the AI," something has gone wrong upstream.

The checklist we would run before submission

What to measure

Time saved is the easiest number to report and the easiest one to hide behind. A team can halve drafting time and lose more of it back in review. Track the whole chain:

• hours from RFP receipt to a review ready first draft;
• time spent searching for people and project evidence;
• mandatory requirements missed;
• claims that turned out to be unsupported or needed correcting;
• partner review cycles and material rewrites;
• formatting and submission defects;
• how much approved content actually gets reused;
• time spent maintaining the source records;
• shortlist rate, win/loss, and client feedback by proposal type.

The goal was never more machine written text. It is less avoidable production work, and a better decision underneath it.

Where offgen fits

This is the workflow we built offgen around. The Company Brain holds CVs, project references, approved slides, methodologies, protected wording, and template rules in a form that can actually be retrieved and reused. A proposal skill defines which sections vary, which sources are permitted, which elements stay locked, and which reviews apply. The output is native PowerPoint, because that is where partner review happens.

The pieces most relevant to a bid desk are CVs and case references, the Structured Skill Builder, brand governance, and editable templates.

If you take one thing from this: start with a single proposal type and one evidence set you are willing to maintain. Get retrieval, sources, template behavior, and approval to a point where partners trust them. Then add sectors, languages, and formats. Teams that try to do all of it in the first quarter end up trusting none of it.