Skip to main content
DoneThat

AI Adoption GuideSalesPropose

Auto-drafted proposal

AI generates SOWs and proposals from CRM opportunity data using approved templates, with tools like PandaDoc AI or Proposify.

Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew

By Don, DoneThat’s AI coach · updated

A filled template is still a draft

The job is speed: a proposal or statement of work assembled from the CRM opportunity and an approved template, sitting in review, not in the customer's inbox.

Legal and the AE still own send. The generator does not. A complete-looking file in PandaDoc or Proposify is a working draft. It is not a sent proposal. It is not a signed SOW. Treating the draft as executed is how a hallucinated scope line, an expired SKU, or last quarter's exhibit lands with a buyer who will hold you to it.

Use this on deal shapes that already have a template: a named package, a standard implementation, a renewal with a known product set. Work that has never been scoped still needs a person to write the work. Filling a template that does not fit will misdescribe the work with high confidence.

Wrong CRM data becomes a wrong customer document. That failure is worse than an empty field. Fix the opportunity, then generate.

Fill from opportunity fields and discovery notes, then stop on a missing SKU or price

Three inputs. If a required one is missing, stop and flag it. Do not let the model invent a product code or a number.

  1. Confirm the deal type and pick the named approved template. Last quarter's file, the wrong MSA edition, or a services SOW on a pure license deal is how most manual errors start. The model should not search every file in the content library.
  2. Confirm opportunity products, quantities, and prices are current in the CRM, typically Salesforce: account, close date, quote lines, price book entries, discount, billing terms. Generation should copy those values, not rewrite them.
  3. Attach discovery notes, often from Gong transcripts or the AE's recap: in-scope asks, out-of-scope asks, timeline, named stakeholders. MEDDIC auto-extraction should already have pushed metrics, champion, and decision criteria onto the opportunity. If those fields are empty, the draft will pad from the template's sample language.
  4. Generate into the document shell you already send from. Keep the draft there. Do not export it to email as ready.
  5. Resolve every red flag, or leave the file in draft. A human then reviews before send.

Red-flag before anyone edits for tone:

  • A product or SKU on the opportunity that is missing from the current price book, or is marked expired, retired, or do-not-sell
  • A line the notes describe that has no matching SKU or quote line
  • A price, discount, or term that is not on the opportunity or on the approved band from the pricing recommendation engine
  • Legal language the locked template does not already contain

Missing SKU or missing price is a hard stop, not a prompt to complete the table. Invented SKUs and invented prices are how you quote something you cannot fulfill, or quote it at a number finance never approved.

Proof and value are adjacent jobs. Approved proof points belong in the draft via case-study retrieval RAG. A quantified value section belongs to the ROI business case generator, using the customer's numbers. Do not let the model fill an ROI heading because the template had one.

Hallucinated scope is the other hard stop. If Gong notes say the buyer asked about single sign-on, and that work is not a line on the opportunity, the draft must leave a placeholder and a flag. Writing it into the SOW because the transcript mentioned it is how you commit delivery you did not quote.

Illustrative example: a standard implementation on a mid-market seat deal

This walkthrough uses made-up names. It is not a measured result.

Northline Analytics sells a standard software package plus a packaged implementation. Maya is the AE. The Salesforce opportunity is a mid-market seat count on the current catalog, plus the current implementation SKU. Gong's last discovery call has a clear ask for single sign-on against the buyer's identity provider, a go-live window, and a note that legal will need the DPA before signature.

Maya generates from the mid-market implementation template. The draft looks finished: cover, scope narrative, commercial table, implementation timeline, case-study block, signature block.

Three things are wrong on arrival.

The scope narrative includes single sign-on as a delivered item. The notes mentioned it. The opportunity does not. There is no matching SKU on the quote. The model wrote it into the SOW because the template has a technical-requirements section and the transcript supplied a sentence. That is hallucinated scope. It reads like a commitment. It is not on the commercial table.

The commercial table still shows an implementation SKU that finance retired when the current package replaced it. The opportunity carries the old code because nobody updated the product line after the catalog change. Generation pulled what the opportunity had. An expired SKU in a customer-facing table is a quote you cannot book.

The signature block is populated. The file is in the send view in the proposal tool. Maya has a meeting the same afternoon. Sending now, before legal has seen the DPA exhibit and before the AE has stripped the extra scope or replaced the SKU, is send-before-legal. Completing the signature block does not make the draft a signed SOW.

The useful pass is markup. Strip the extra scope, or add the current identity SKU once it exists on the opportunity with a price from the live book. Replace the retired implementation code. Leave the DPA for legal. Then a person decides the file can enter review, not the customer's inbox.

PandaDoc, Proposify, Salesforce, and Gong sit in different lanes

Proposal platforms such as PandaDoc and Proposify are a class for templates, content blocks, and the send-and-sign workflow. They are not a ranking. Use them as the shell the draft lives in. Do not treat a generated section as proof that the SKU is current, or that legal signed off.

Salesforce holds the opportunity and the quote lines. If the opportunity is wrong, fix the opportunity. Do not patch the PDF and leave the CRM stale.

Gong holds the call. Use it for what was said. Do not use a transcript as a price book.

A proposal tool that can call a language model is still not your CPQ, your price book, or your legal review. Keep those lanes.

Review, then send

A human reviews before send. That is not a courtesy pass for typos.

The AE checks that the template matches the deal type, that every commercial line matches the live opportunity and the current catalog, and that discovery asks with no quote line are flags rather than silent scope. Proof and ROI blocks should come from approved sources.

Proposal ops or deal desk checks expired or do-not-sell SKUs, discount outside the approved band, and billing terms the template should not have changed.

Legal checks exhibits, the DPA, non-standard language, and anything the model added that was not in the locked template. Faster drafting does not shorten legal's queue unless legal agrees it does.

Send is a human action. Until then the file stays a draft, even when the tool marks it complete. After the buyer redlines, contract redline AI is a later step against the playbook. It is not a reason to skip the first legal pass on the outbound document.

Trial this on standard deals you already sent. Generate from the opportunity as it looked at draft time, not from the cleaned record after close. Look at the edits that were catalog, scope, or legal, not the edits that were tone. If those edits are still the whole document, the template does not fit that deal shape. Stay on shapes it fits.

Success looks like reps opening a populated file instead of last quarter's proposal with the wrong logo, and like legal seeing a short exception list instead of a surprise send. Failure looks like a buyer signing a draft that promised work you cannot deliver.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first