What this automation does
A rep clicks Generate proposal on a deal and gets a draft in your branded template, with the parts that should be custom actually customized.
- Gather context. The workflow reads the deal, company, contacts, line items and recent meeting notes or call summaries from the CRM.
- Build a brief. The model turns those inputs into a one-page brief: client goals, stated problems, constraints, decision criteria and anything the client explicitly asked to see.
- Retrieve approved content. Using the brief, the workflow searches your content library for the best-matching service descriptions, methodology sections, case studies and team bios.
- Draft custom sections. The model writes the executive summary, the understanding of needs, and the tailored approach, using retrieved content as its base and citing which library chunks it used.
- Insert fixed content. Pricing tables come from CRM line items, terms come from the current legal version, and boilerplate pages are inserted unchanged.
- Review and send. The assembled draft lands in PandaDoc, Google Docs or Word with highlighted AI-written sections. After review, the rep sends it for e-signature from the usual tool.
When it is worth building
It pays off when reps or partners spend several hours per proposal and most of that time is hunting for the last good version, copying sections and rewriting the client name. If your proposals are a one-page quote with a fixed scope, you need quote generation, not this.
It also needs a content base. If you have fewer than a dozen past proposals and no approved case studies, write those first. The AI will reuse whatever it is given, including weak material.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Deal context | HubSpot or Salesforce deal, line items and notes | Single source for client, scope and price |
| Content library | Approved sections in Google Drive or Notion, chunked and tagged | Reps and marketing can keep it current without touching code |
| Search | pgvector in Postgres or Pinecone, with tag filters | Finds relevant sections by meaning, filtered by service and industry |
| Drafting | Claude Opus 5.5 for long-form sections, or OpenAI’s GPT models | Long-context writing that adapts source material without drifting off-brand |
| Pricing and terms | Code that reads CRM line items and the current terms file | Numbers and legal language must be exact and versioned |
| Assembly | PandaDoc, Google Docs or Word templates via API | Keeps branding and layout outside the model |
| Orchestration | n8n or a small service, triggered from a CRM button | One click from the deal record |
How to build it
- Audit your best proposals. Pick ten to twenty that won. Break them into reusable sections and mark which parts are always custom.
- Build the library. Store each approved section as its own document with tags for service, industry, deal size and last-reviewed date. Retire anything older than your review window.
- Index for retrieval. Chunk by section, embed, and store with tags. Filter by tags before semantic search so a healthcare case study never lands in a manufacturing proposal.
- Design the template. Mark which blocks are AI-drafted, which are retrieved verbatim, and which are fixed. Put pricing and terms in fixed blocks fed by code.
- Write the drafting prompts. One prompt per custom section, each with length limits, tone rules, the brief, and retrieved chunks. Require the model to refuse claims not supported by the brief or library.
- Add pre-flight checks. Search the draft for other client names, outdated product names, and placeholder text. Confirm the totals match CRM line items.
- Launch with a review rule. Every proposal is reviewed by the rep. Track which sections get rewritten most and improve those library entries first.
What breaks in production
- Leftover client names. Retrieved sections still say the last client’s name. A pre-flight scan against your customer list catches this; it is the most embarrassing failure and the easiest to prevent.
- Overpromising scope. The model writes “unlimited revisions” because a 2023 proposal said so. Tag deprecated commitments and exclude them from retrieval.
- Stale case studies. Results or client permissions have changed. Enforce a last-reviewed date and drop expired chunks.
- Thin discovery notes. When the deal has no notes, the custom sections become generic. Block generation and ask the rep for three bullet points instead.
- Template API limits. Document tools limit how content is inserted, especially for tables and images. Prototype assembly early, before investing in prompt polish.
- Pricing mismatch. A rep edits line items after generation. Regenerate the pricing block, or lock edits to the CRM and re-sync.
Timeline and cost
A first version with one template, one CRM and a library of a few dozen sections typically takes three to six weeks, much of it spent organizing content. Lumeor builds proposal generation in the range of $12,000 to $28,000, within our RAG knowledge assistant pricing. Larger content libraries, several proposal types, or multiple output formats push toward the top. Running costs are model usage per draft and vector storage, both modest at typical proposal volumes.
How to measure success
- Hours from discovery call to proposal sent
- Rep time spent per proposal, from time tracking or self-report
- Share of AI-drafted text kept without major rewrites
- Pre-flight errors caught per month (names, totals, placeholders)
- Proposal win rate, tracked over at least a quarter before drawing conclusions