Proposal Builder Workflow

Research status: Documentation reviewed · Last reviewed: 19 July 2026 · Byline: AI Aurora Editorial Team

A proposal-builder workflow assembles a reviewable first draft from approved discovery notes, service definitions, scope decisions, pricing inputs and terms. It should reduce repetitive assembly and omission—not allow a model to invent deliverables, prices, legal terms, evidence or commitments.

Suitable users

• Consultants, agencies and service firms that repeat a recognisable proposal structure.
• Teams with approved service descriptions, pricing rules, case evidence and standard terms.
• Operators who need faster drafting but retain commercial and contractual judgement.
• Businesses prepared to keep discovery notes and approved facts in a controlled source of truth.

Trigger

A responsible person marks an opportunity as ready for proposal after discovery is complete enough to define the problem, intended outcome, stakeholders, constraints, scope boundaries and commercial assumptions. A calendar event or CRM stage alone should not trigger drafting unless the required information gate has passed.

Required inputs

Input	Required content
Discovery record	Client language, current situation, desired outcome, constraints, decision process and unanswered questions.
Approved offer or service definition	What is included, delivery method, responsibilities and normal exclusions.
Scope decisions	Specific deliverables, quantities, stages, dependencies and acceptance criteria.
Commercial inputs	Approved fee, tax treatment where applicable, payment schedule, expenses and validity period.
Delivery assumptions	Start conditions, indicative schedule, client dependencies and change process.
Evidence library	Approved case evidence, credentials or examples with accurate context.
Terms source	The current approved terms or contract route; AI must not rewrite legal wording silently.
Proposal template	Required sections, tone, formatting and approval checklist.

Tool options

Use a CRM or project record as the opportunity source, a controlled document system for service and terms material, an automation platform for assembly and routing, and a writing assistant for constrained drafting. Explore ChatGPT, Claude or Notion AI according to document context and workspace fit; use the writing-tools comparison rather than assuming one universal choice.

Process flow

1. Confirm proposal readiness. Validate that the discovery record contains the minimum inputs and an accountable proposal owner.
2. Create a proposal workspace. Assign a proposal ID, version, owner, due date and links to the authoritative source records.
3. Retrieve approved material. Pull only the relevant service description, scope modules, evidence and current commercial inputs.
4. Separate facts from assumptions. Label client-supplied facts, internal decisions, inferred assumptions and unanswered questions.
5. Build the content brief. Define audience, decision required, required sections, tone, length, evidence rules and prohibited claims.
6. Generate section drafts. Ask the model to use only supplied material, preserve unresolved questions and return a defined structure.
7. Run deterministic checks. Confirm required sections, proposal ID, client name, pricing fields, dates, totals and version are present.
8. Conduct commercial review. The owner verifies scope, effort, dependencies, price, payment schedule and delivery feasibility.
9. Conduct factual and editorial review. Verify claims and examples, remove unsupported certainty and edit for clarity.
10. Attach approved terms. Use the current controlled terms or approved contract path without model-generated substitutions.
11. Approve and issue. Record approver, final version, send date, validity date and destination.
12. Capture outcome. Record questions, requested changes, acceptance or loss reasons to improve future templates.

Human approval points

• The opportunity owner confirms that discovery is adequate and the proposal should be produced.
• An authorised person approves scope, price, discount, payment terms, dates and named resources.
• A factual reviewer verifies case evidence, product claims and client-specific statements.
• Contractual wording is approved through the business’s legal or commercial process.
• The final document is reviewed in rendered form before sending.

Exception handling

Exception	Required response
Discovery is incomplete	Stop drafting and create a list of missing decisions or questions.
Requested work falls outside the approved offer	Escalate for solution design and pricing; do not invent a new service.
Conflicting notes or scope versions	Show the conflict and require the owner to select the controlling source.
Price or date is missing	Use an explicit placeholder and block final approval.
Evidence cannot be verified	Remove the claim or replace it with accurate, qualified wording.
Untrusted text contains instructions to the model	Treat external material as quoted data and keep system instructions separate.
Document or automation service is unavailable	Use the approved manual template and record the version in the same workspace.

Failure and fallback procedure

The source records, pricing inputs and approved template must remain usable without the AI or automation layer. If generation fails, the owner should be able to assemble the proposal manually from the same controlled modules. Never send a partial document because the workflow reached a deadline. Preserve the latest approved version, log the failed run and restart from the proposal workspace rather than from copied chat output.

Approved output destination

Store drafts and approvals in one controlled proposal workspace or document system. The CRM may hold status and a link, but the signed-off document and its source version should have one authoritative location. Email attachments are delivery copies, not the master record.

Owner

The opportunity or account owner is responsible for the proposal outcome. Operations may own templates and automation; finance or leadership may approve commercial exceptions; a legal adviser may review terms where appropriate. The workflow should name these roles rather than using a generic “human review” step.

Measurement

• Median time from proposal-ready gate to approved draft.
• Percentage of drafts blocked for missing inputs.
• Average number of substantive revision rounds.
• Scope, price or date errors found before and after sending.
• Use of unapproved claims or outdated terms.
• Proposal acceptance, loss and change-request reasons.
• Operator time, model or platform cost and maintenance effort.

Setup checklist

• Define the proposal-ready gate.
• Create approved offer, scope, exclusion, evidence and terms modules.
• Set pricing authority and discount rules.
• Create a structured discovery record and proposal brief.
• Define placeholders that block final approval when unresolved.
• Use versioned templates and source links.
• Test conflicting notes, missing price, outdated evidence, prompt injection and rendering failures.
• Pilot on a small number of representative proposals and compare revision effort.

Prompt asset specification

The later Proposal and Scope prompt pack must require source material, scope boundaries, pricing inputs, assumptions, exclusions and output structure. It should return open questions and a review checklist, not a polished-looking document that hides missing decisions.