An AI presentation workflow for client proposals that still need your judgment

Define the decision the presentation must support

A proposal presentation has a job: help a particular audience make a particular decision. It is easy to lose that purpose when a tool can generate a polished deck from a short prompt. Before creating slides, write the requested decision in plain language. Is the client approving a discovery project, selecting a supplier or authorizing a full implementation? A deck that mixes those decisions may feel comprehensive while making the next step less clear.

This workflow uses Gamma as one possible production tool, not as a substitute for subject knowledge. Gamma’s official product overview describes generating presentations from ideas or existing material and exporting them to presentation and document formats. The process below is our suggested evaluation method. We have not measured time savings, tested every export format or verified that any AI-generated proposal improves win rates.

Build a source pack before writing a prompt

Gather the material you are allowed to use: the client’s stated problem, confirmed requirements, your notes, your service scope and any approved supporting evidence. Separate facts from assumptions. A fact may be that the client uses three disconnected reporting systems. An assumption may be that consolidating them will reduce preparation time. If an assumption appears in the presentation, label it and explain how it would be tested.

Create a small claim register with the claim, source, date and owner. This does not have to be a complicated database. Its purpose is to prevent a confident sentence from becoming detached from its evidence as the deck is edited. Remove sensitive details that are unnecessary for the task, and review the relevant workspace settings and client permissions before uploading confidential material to any external service. Do not rely on a general marketing statement to settle your particular data requirements.

Write the argument as an outline

Start with a sequence such as problem, consequence, proposed approach, deliverables, assumptions, schedule, commercial terms and decision. Each section should earn its place by helping the audience evaluate the proposal. If a slide exists only because a template expects it, remove it. A short deck with an explicit scope is more useful than a long deck that leaves important conditions implicit.

For a hypothetical reporting project, the outline might describe the current manual handoff, a limited discovery phase, the outputs of that phase and the decision that follows. It should not jump straight from inconvenience to a promised percentage improvement. Ask the client-facing owner to review the outline before design begins. Correcting a weak argument is easier when it is still a page of text rather than a set of layouts that everyone has started to admire.

Give the tool boundaries as well as instructions

A useful generation brief contains the audience, decision, approved outline, tone and source material. It should also say what must not be invented: customer quotes, performance figures, implementation dates and financial commitments. Ask the tool to retain uncertainty rather than filling gaps with plausible details. Where the evidence is missing, a visible placeholder for your review is safer than an unsupported sentence that looks complete.

Use a sample instruction such as: create a concise proposal from the supplied outline; preserve the scope and assumptions; mark unsupported claims for review; do not add customer names or results. This is an example prompt, not a guarantee of compliance by a model. Check the result line by line against the source pack. Prompt quality can reduce revision work, but it does not transfer responsibility for the final proposal to the software.

Review meaning before appearance

The first review should ignore colors and focus on what the deck now claims. Has a possible benefit become a promise? Has a discovery task become a guaranteed deliverable? Did an approximate schedule acquire an exact date? Did the tool compress a qualification into a footnote that a reader could miss? These changes can materially alter the proposal even when the language sounds smoother.

Use two passes. In the first, compare claims and numbers against the register. In the second, read the presentation as a skeptical buyer who has not attended prior meetings. That reader should understand what is included, what depends on the client and what happens if assumptions change. Keep revisions tied to a named owner so that a last-minute wording improvement does not silently change commercial intent. Design review belongs after the argument is stable enough to evaluate.

Make the final format part of the trial

A presentation tool can look excellent in its own editor while producing a different experience after export. Test the exact delivery format your client uses. If the client expects an editable deck, open it in their presentation software and inspect line breaks, charts, fonts and object placement. If the deliverable is a PDF, check reading order, links and whether essential information remains legible at an ordinary viewing size.

Also test a typical revision. Replace a long heading, change one chart label and add a qualification to a pricing slide. If those small changes break the layout, the export may be costly to maintain. Keep an editable master and a clearly named approved version. Record which file was sent. A smooth generation step offers limited value if the final review and delivery process repeatedly creates confusion.

Estimate savings across the complete workflow

Measure from approved source material to an approved deliverable, not from pressing generate to seeing a first draft. Include prompting, fact checking, revision, export repair and client-specific adaptation. Compare this with the same task in your existing workflow. Use similarly complex proposals; a short internal update is not a fair baseline for a high-stakes commercial presentation.

For an illustrative calculation, suppose a manual workflow takes four hours and the assisted workflow takes three hours including review. The observed difference is one hour for that task. It does not show that every future deck will save the same amount. Record the type of work that became faster and the work that remained. This helps you decide where the tool belongs: early layout, first drafts, recurring updates or complete production under close review.

A proposal release checklist

Before sending, confirm the audience and requested decision on the opening and closing slides. Trace every quantitative claim to an approved source. Check that assumptions remain visible, deliverables match the commercial document and the schedule reflects dependencies. Inspect the exported file rather than assuming it matches the editor. Open every essential link and check that any shared version has the intended access settings.

Have one person who did not produce the deck explain the offer back to you. If they cannot distinguish the initial commitment from optional later work, revise the argument. If they think an illustrative number is a forecast, relabel or remove it. This review is especially useful because familiar authors often fill gaps from memory that a new reader cannot fill.

Keep a short retrospective after delivery: what was reused safely, what the AI tool changed incorrectly, what required manual layout work and what should enter the next source pack. Over time, a maintained proposal outline and a trustworthy evidence library may create more value than a more elaborate prompt. Buy the presentation tool when it improves this complete workflow, and keep the judgment-heavy parts assigned to people who understand the client and the work.