How to organize quote and proposal revisions

Why quote revisions turn into chaos

Every event and rental business knows the scene. The client calls with 'a few small changes' for the third time, someone edits the quote document, and three weeks later there are five files with 'final' in the name. The truck gets packed against one of them, the invoice gets built from another, and the client swears they approved a third.

None of this comes from carelessness. It comes from three habits that feel fine on a quiet week and fall apart under volume:

• File-name versioning. Quote-v2-FINAL-revised(3).pdf is not a version system; it is a guess. A file name records nothing about what changed, when it changed, or who has seen it.
• Edits after acceptance. The client approves a number, then the document quietly changes to fix a typo or swap an item. The exact thing they agreed to no longer exists anywhere.
• No record of what the client saw. Your outbox knows what you sent, roughly. It does not know which attachment they opened, or which version they meant when they replied 'looks good.'

The cost lands downstream. Gear gets held against a stale version. The invoice disagrees with the accepted price. And when there is a dispute, you are reconstructing history from email timestamps instead of pointing at a record.

A versioning discipline you can run today

You do not need software to fix most of this. You need four rules you never break, even in busy season. Especially in busy season.

1. One number per client-visible change. Any change the client would care about gets a new version: v1, v2, v3. Internal fixes made before anything is sent do not.
2. Date plus version in every file name. 2026-03-14-jones-wedding-quote-v3.pdf sorts correctly in any folder and settles arguments on sight. The words final, FINAL2, and revised are banned.
3. Keep a change log. One line per version, kept in the document or a running note: what changed, who asked for it, the date. Sixty seconds of writing that replaces an hour of archaeology.
4. Freeze on send. The moment a version goes to the client, that file never changes again. Any edit, however small, becomes the next version and gets re-sent. This rule does most of the work.

Then track status in exactly two places: which version is current, and once the client commits, which version was accepted. There is never more than one of each.

A file name that answers questions

What any system of record must guarantee

At some point the discipline has to move from a folder you police into a system that enforces itself. Whether that system is software or a rigid process, hold it to the same four guarantees:

A shared folder plus the rules above can meet this bar for a while. It stops working when more than one person edits quotes, or when volume means the rules get skipped on exactly the week you can least afford it.

When the client keeps changing the order

Guest counts move. Layouts change after the venue walkthrough. The planner adds a second arch on Thursday. Change is the business; unmanaged change is the problem. Three policies keep it sane.

Set a change window

Decide in advance, and in writing, when free-form changes end. For example: changes are welcome until 14 days before the event; inside that window, requests go through a written change request and may carry a fee, because by then gear is being pulled and crew is scheduled. The specific number is yours to pick. Having a number is the point.

Re-send, do not re-describe

Every agreed change becomes a new version that goes back to the client for approval, even when the change was settled on the phone. 'Per our call, here is v4 with the extra 20 chairs; it replaces v3.' It takes two minutes, and it means no accepted version ever exists only in someone's memory.

Deposits before revision rounds

Endless revisions are usually a commitment problem wearing a paperwork costume. A client with a deposit down revises twice and decides; a client with nothing down can revise forever, because it costs them nothing. Requiring a deposit to hold the date before fine-tuning begins filters browsers from buyers, and it pays for the revision time either way.

When a revision should become a new scope

Version numbers handle changes to the same job. Some changes make it a different job, and pretending otherwise corrupts your records. Watch for these signals:

• The event date or venue changes, which reprices availability, crew, and logistics all at once.
• The deliverable itself changes: a photo booth becomes a photo booth plus a 360 setup, or a dry hire becomes full production.
• The total moves past a threshold you set in advance. Say a swing of more than 25 percent in either direction, as an example.
• The client already accepted, and now wants changes. Post-acceptance changes belong in a change order that references the accepted version, never in a quiet edit of it.

A change order keeps the accepted baseline intact and layers the difference on top: what was added, what it costs, and a fresh approval from the client. Your history stays honest, and so does the final invoice.

How OpsVue handles this

OpsVue's document engine is built around the freeze-on-send rule. Every time a quote, proposal, or estimate goes out, the send snapshots an immutable version: line items, totals, terms wording, even the template design are preserved exactly as the client received them. Later edits create the next version, there is always exactly one current version, and the full revision history lives on the work record.

Clients act on a document link instead of an attachment. From that link they can accept by typing their name and title, request changes with a message that lands back on the work record, or decline. Each sent version carries its own link, and views are recorded, so 'which quote did they approve' has a stored answer instead of a best guess.

Changes after acceptance become change orders on the same job, and once you connect your own Stripe account, the deposit that anchors your change policy can be paid straight from the quote link. Versions, client responses, files, emails, tasks, and money all hang off one work record — which is what 'system of record' means in practice.