How to automate proposal generation: assembly, not authorship

A proposal is a document that can be accepted. That single fact separates it from every other sales artefact and determines what should and should not be automated about producing one — because an error in a proposal is not an embarrassment, it is a commitment somebody may hold you to.

Most of a proposal is assembly: the same company background, the same method section, the same case studies, reformatted for the tenth time this quarter. That part should be automatic. The parts that make it a proposal — the scope, the price, the terms — should not be, and the boundary between them is what this comes down to.

What we'll cover

• A proposal is an offer
• What is genuinely reusable
• What must be decided by a person
• Building it with CodeWords
• Scope, and the words that cause disputes
• Version control and what was actually sent
• Approvals that do not slow everything down
• After it is sent
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

A proposal is an offer

It can be accepted, which in many jurisdictions and contexts creates obligations.

The price is a commitment for whatever validity period it states, and an omitted expiry means an open one.

The scope is what you agreed to deliver, and ambiguity in it is resolved against the person who wrote it more often than not.

Terms carry through, including anything attached or referenced, whether or not the recipient read them.

A mistake is expensive in a way that a mistake in a marketing email is not.

Which is the argument for automating the assembly and not the commitments — the boilerplate has no downside and the numbers do.

What is genuinely reusable

Company background and credentials, which change rarely.

Method and approach sections, tailored by category rather than written fresh.

Case studies and references, selected by relevance to this client's sector or problem.

Team biographies, kept current in one place rather than copied between documents.

Standard terms, attached as the approved current version rather than whatever was in the last proposal somebody copied.

Formatting and assembly, entirely, which is where most of the time actually goes.

What must be decided by a person

The price. Every time, including for standard packages, because the exception is exactly where an automated number causes damage.

The scope, which requires understanding what the client actually needs rather than what they asked for.

The timeline, which depends on your real capacity rather than on a template's assumption.

Anything non-standard in the terms, which should route to whoever owns that.

Whether to bid at all, which is a judgement automation should inform and not make.

The one paragraph that shows you listened, which is the part clients actually read and the part that cannot be assembled from components.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the CRM, the content library, the approval chain and the document destination can meet in one workflow.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what is assembled, what is left blank for a person, and what needs approval before sending.
3. Authorize the connections — the CRM, the content store, and wherever documents are produced and sent.
4. Describe the exceptions: a non-standard discount, a bespoke scope, a regulated client, a value above a threshold.
5. Generate proposals for three closed deals and compare against what was actually sent.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Scope, and the words that cause disputes

Say what is not included, explicitly, which is the section that prevents most disputes and the one most often omitted.

Define the deliverable, not the activity. "A report" and "analysis of your data" are different commitments.

State the assumptions the scope depends on — access, data quality, responsiveness — since those are the usual reasons a project goes wrong.

Quantify the rounds. "Revisions" without a number is unlimited revisions.

Name the dependencies on the client, and what happens if they are late.

Avoid the vague qualifier. "As needed", "reasonable" and "ongoing support" are the words that appear in every scope dispute.

Version control and what was actually sent

The problem that surfaces months later, and the reason to build for it now.

Store the sent document, not the data that produced it, since templates change and regeneration will not reproduce what the client holds.

Record the template version used, so a discovered error can be traced to everything it affected.

Track revisions to one client properly, since "the proposal" after three rounds is ambiguous and the client is holding a different version from the one in your folder.

Timestamp and record delivery, including who received it.

Keep the pricing inputs, so a question about how a number was reached has an answer.

One canonical copy. The most common failure here is two people sending slightly different versions of the same proposal to two people at the same client.

Approvals that do not slow everything down

Approve by exception, not by default — a proposal within standard terms and pricing should not queue behind anything.

Route by what is non-standard, so a discount goes to whoever owns pricing and a term change goes to legal, rather than everything going to everybody.

Set thresholds by value and by variance from standard, and review them rather than leaving them at whatever was chosen initially.

Give approvals a clock. An approval process without one becomes the reason proposals go out late, which costs more than the risk it manages.

Show the approver the delta, not the whole document, since reviewing forty pages to find one changed number is how approvals get rubber-stamped.

Record the approval with the version it applied to, since approving a document that then changed is worth nothing.

After it is sent

Proposal automation usually ends at the send, which leaves out the half that determines whether any of it converts.

Know whether it was opened, and by whom, which is the most useful signal available and is worth more than any section of the document.

Watch for it being forwarded, since a new reader inside the client is frequently the decision-maker arriving.

Follow up on a schedule you set at send time, rather than on somebody remembering.

Chase before the expiry, not after, since an expired price forces an awkward conversation about whether it still stands.

Record the outcome and the reason, particularly for losses, which is the most valuable and least captured information in the whole sales process.

Feed the reasons back into the library. A section that appears in every loss, or an objection that recurs, is telling you what to change — and it will not surface anywhere else.

Making it survive

Validate the numbers. Totals, tax, dates and validity periods should be checked rather than assumed correct.

Fail rather than publish a document with an unfilled placeholder, which is the most visible possible error.

Check the client's name and details appear correctly everywhere, since a proposal addressed to the wrong company is unrecoverable.

Handle template updates by versioning rather than editing in place.

Report the outcome: proposals generated, approvals required and granted, and anything held.

Limits worth knowing about

Document formats behave differently. A proposal that renders correctly in one application may not in another, and clients open them in whatever they use.

Electronic signature is a separate capability with its own requirements depending on jurisdiction and document type.

Formal tenders have strict format requirements that a general template will not satisfy.

Regulated sectors constrain what may be claimed, which is a content restriction rather than a process one.

Generated prose reads as generated in the sections clients actually read, which is the argument for automating assembly rather than authorship.

What to build first

The content library: approved, current, versioned components — credentials, method, case studies, biographies, standard terms — that assemble into a document with the commitments left blank. It removes the reformatting, which is where the time goes, and it stops the practice of copying last month's proposal, which is how a superseded price or an obsolete term reaches a client.

Two habits make the difference. Store the document that was actually sent rather than the data that generated it, since templates change and a regenerated copy is not what the client is holding. And keep the scope's exclusions section mandatory, because what is not included is the section that prevents disputes and the first one people drop when they are in a hurry.

Frequently asked questions

What should never be automated in a proposal?

The price, the scope, the timeline, anything non-standard in the terms, and the decision to bid. A proposal is an offer that can be accepted, so an error in it is a commitment rather than an embarrassment.

What is safe to automate?

Assembly: credentials, method sections, case studies selected by relevance, team biographies, the current approved terms, and all the formatting — which is where most of the time actually goes.

Which part of a scope prevents the most disputes?

The exclusions. Saying explicitly what is not included is the section most often omitted and the one that resolves most disagreements before they start.

What wording causes scope disputes?

"As needed", "reasonable", "ongoing support", and "revisions" without a number — which means unlimited revisions. Define deliverables rather than activities, and state the assumptions the scope depends on.

Why store the sent document rather than regenerate it?

Because templates change, so a regenerated copy will not match what the client is holding. Store the document, the template version, and the pricing inputs behind the numbers.

How do I keep approvals from delaying proposals?

Approve by exception rather than by default, route by what is non-standard rather than sending everything to everybody, put a clock on it, and show the approver the delta rather than the whole document.

What is the most common version control failure?

Two people sending slightly different versions of the same proposal to two people at the same client. One canonical copy per client, with revisions tracked, prevents it.

Should proposals include an expiry?

Yes. A price without a stated validity period is an open commitment, and an expiry is both standard practice and a natural reason to follow up.

What should happen after a proposal is sent?

Track whether it was opened and by whom, watch for forwarding — a new reader inside the client is often the decision-maker arriving — and schedule the follow-up at send time rather than relying on memory. Chase before the price expires, not after.

What is the most valuable thing to record?

The loss reason. It is the least captured information in most sales processes, and an objection that recurs across losses is telling you what to change in the proposal library.

Related reading

• Automating PDF generation from data
• Automating sales pipeline updates
• Automating lead scoring