How to Handle Proposal Revisions Without Losing Your Mind

The first proposal version is rarely the one that gets accepted. Clients change the brief, push back on price, ask for alternatives, or want to compare options. The companies that handle revisions cleanly win the jobs. The companies that lose track of which version is current lose the jobs.

Here is a working system.

Why revisions go wrong

In a typical email-and-Word-document workflow, revisions go wrong in five ways:

• The wrong file is sent. The client receives v3 when v4 was meant to go out.
• The client comments on an old version. They had v2 open in a tab and never refreshed.
• The team disagrees about what the current version is. Sales sent one version, ops kept editing another.
• The accepted version is unclear. The client signed v3 by email but you have changes in v4. Did they accept the new ones?
• The history is lost. Three months in, you cannot recreate why a particular line item was added.

Each of these has the same root cause: there is no single source of truth for "the current version".

The system that works

Four rules:

1. The proposal lives at one URL

Not as five PDF attachments to five emails. The proposal lives at one link. When you edit it, the link still works. When the client opens it, they see the current version.

This kills most of the version confusion immediately.

2. Every send is a revision

Each time you send the proposal to the client (in a meaningful way, not after a typo fix), you create a revision. The revision is a snapshot of the proposal at that moment.

• Revision 1: original
• Revision 2: after the client asked for a cheaper option
• Revision 3: after the technical spec was updated

The link to the proposal always shows the latest, but the history is preserved. If the client asks "what was in the previous version?" you can show them.

3. The current version is obvious

Inside the proposal, the version number is visible. "Version 3, last updated 12 November 2026" near the top. The client never has to guess whether they are reading the latest.

4. Acceptance locks the version

The instant a client accepts, the version that was accepted is locked. Even if you accidentally edit something afterwards, the accepted snapshot is preserved. Nobody can claim "but the proposal we agreed to said X" and be wrong.

What clients actually want when they ask for revisions

Most revision requests fall into four categories:

• Price-shape changes. They want to see the same scope at a different price, or different scope at the same price.
• Optional extras moved between included and excluded. They want to see the proposal with the optional camera package in, then with it out.
• Time-shape changes. The event is now on a different date, the venue is now different.
• Risk-shape changes. They want more cover (a spare desk, an extra engineer on standby) or less cover (cheaper option, willing to accept the risk).

For each of these, having a structured proposal makes the revision faster than a flat document. You change one section, the totals update, you re-send the link.

How to talk about revisions with the client

Clear, short communication beats long emails:

• "I have updated the proposal with the changes we discussed. Same link as before. Let me know if you have questions."
• If the change is significant: "I have built two versions for you to compare: A is the original scope, B is the reduced scope we discussed. Both are at the link below."

If you need to flag a change that affects the price, do it explicitly: "Adding the breakout AV pushes the total up by £4,600 plus VAT. Happy to walk through that on a call."

Multiple options without confusing the client

Sometimes the client wants to see Option A vs Option B in the same proposal. Two ways to handle this:

• Side-by-side quote sections. Two separate quote tables in the same document, clearly labelled. Best for two clean variants.
• Separate proposals. One per option, sent as two links. Best when the options differ in more than price (different scope, different team, different timeline).

If you put more than two options in one document, the client will spend longer comparing than deciding. Keep it to two.

When to stop revising and ask for the decision

Three revisions is usually the limit before the conversation needs to become a phone call. If you are on version 5, the proposal has become a working document, not a sales document. Get on a call, agree the scope, then build a fresh proposal.

What pro-posal.io does for revisions

pro-posal.io keeps the proposal at one URL, increments a version number every time you send a meaningful update, preserves a full revision history, and snapshots the accepted version automatically. The client always sees the latest. You can always show them an older one. The history is never lost.

Try it free for 60 days, no card required: pro-posal.io.