The Customer Accepted Your Quote. Which Version?
When a customer says yes to a quote you have revised three times, the real question is which version they agreed to. Without version control built into your quoting process, the wrong document can drive the job, the ordering, and the invoicing - with the difference coming off your margin.
A customer emails to say they are happy to proceed. That should be the easy part of the sale. But if you have sent three versions of the same quote over the past two weeks - adjusting the price after a supplier increase, removing a line item the customer decided they did not need, and then adding it back at a lower spec - you now have a problem. Which version did they just accept? The one in your sent folder from last Tuesday? The one you called them about on Friday? The one you emailed again yesterday with "updated" in the subject line? If you cannot answer that in under thirty seconds, your quote process has a version control problem, and it will eventually cost you.
Why Quotes End Up With Multiple Versions
Most businesses do not plan for quote versioning. They plan to send a quote and get a yes. The revisions come later, and they come often.
A customer asks for a lower price. You adjust the margin and resend. Then they ask whether the extended lead time can be shortened - which means a different supplier, which means different pricing again. Meanwhile, your own costs have shifted: a supplier notified you of a price increase the day after the original quote went out. The quote you are now working from is three iterations removed from what you first sent.
This is not exceptional. It is routine for most project-based or custom-order businesses. Research on the sales quote revision process confirms that quote revisions are triggered by customer feedback on scope, changes in market conditions affecting costs, and errors found in the original quote. All three can happen on a single job.
The problem is not that revisions happen. The problem is that most businesses manage them by resending a document rather than by maintaining a record. The original quote, the intermediate versions, and the accepted version exist as separate email threads, with no clear hierarchy and no visible status. When the customer says yes, the person who takes that confirmation may not know which version is current - and neither may the person who starts building or ordering against it.
When the Wrong Version Gets Acted On
Acting on the wrong quote version is more expensive than it sounds. If your team starts a job based on version one - which included a line item the customer later removed - you will either deliver something they did not agree to pay for, or you will have to go back and renegotiate. Neither outcome is comfortable.
More commonly, the damage is in the pricing. Version one was built on last month's supplier costs. Version three - the one the customer actually accepted - reflected a 6% materials increase. If the job gets started on version one pricing, that 6% comes off your margin. On a £40,000 contract, that is £2,400 you absorb without noticing.
The legal picture is also harder than it looks. A 2026 review of UK business disputes notes that payment and pricing disputes are on the rise, particularly in construction and supply chains, and advises businesses to build in clear pricing mechanisms rather than relying on courts to interpret intentions after the fact. A quote with no version tracking, no explicit acceptance record, and a trail of "updated" PDFs scattered across email threads is not a clear pricing mechanism. It is an ambiguous one - and ambiguity, when money is in dispute, defaults to whoever argues better.
What Version Control in Quotes Actually Requires
Controlling quote versions is not a complicated discipline, but it requires a process rather than a convention.
The minimum viable approach has three elements. First, each revision of a quote needs a visible revision marker - not just a new date in the filename, but a clear indicator that this supersedes the previous version. Second, when a customer accepts a quote, that acceptance needs to be recorded against a specific version, not just against a quote number. Third, any earlier versions need to be locked or marked superseded so they cannot accidentally be the source for the job that follows.
None of this is difficult to enforce once it is built into the workflow. The difficulty is that most businesses do not build it into the workflow at all. The quoting process lives in a combination of email, spreadsheets, and shared drives, with no mechanism for recording version status. The result is that the information exists - buried in a thread somewhere - but it is not visible at the point when it needs to be.
A quote version that has been superseded but not marked as such is a liability sitting in your sent folder. At any point, someone can pull it, reference it, or - if the customer digs it out - claim it as the agreed price.
Verbal acceptance is not enough
If a customer confirms by phone that they are happy to proceed, follow up immediately with a written confirmation referencing the specific quote version number. A phone call does not create a clear record of which version was accepted.
How Zigaflow Handles Quote Versioning
Zigaflow's quotes feature tracks each quote as a versioned record rather than a standalone document. When a quote is revised, a new version is created while the previous one is retained for reference. The status of each version is visible - draft, sent, superseded, accepted - so at any point, anyone in the business can see which version is the current live document and what happened to the ones before it.
When a customer accepts a quote, that acceptance is logged against the specific version they agreed to. The accepted version becomes the reference for the job, the purchase orders, and the invoices that follow. There is no ambiguity about which document governs the work.
Use quote acceptance as the job trigger
When a quote is accepted in Zigaflow, that event can trigger the creation of the job record automatically. The job inherits the accepted quote version, so the team working the job is always starting from the right document.
This matters most on jobs that involve multiple revisions or long sales cycles, where the gap between the first quote and the accepted version can be weeks. It also matters when more than one person in the business is involved in quoting - a version log visible to everyone prevents the situation where one person acts on a quote that another person has already revised.
The version history is also useful when disputes arise. If a customer later questions a price or a scope item, the accepted version is retrievable with a timestamp. The conversation starts from a shared record rather than from competing recollections. For a closer look at how quote-to-cash processes break down in practice, the glossary entry covers the full lifecycle from acceptance to payment.
When a customer emails to say they want to proceed, the right response is a clean handover to whoever does the work - built on a single, unambiguous, accepted version of the quote. That is what a managed quoting process delivers. Without it, every accepted quote is a question you have not answered yet.
Sources
- What is a Quote Revision?DealHub AI · accessed 2026-08-10
- Business disputes in 2026: what business owners need to knowThrings Solicitors · accessed 2026-08-10
Related pages
Ready to run your business
on one platform?
Book a free demo and see how Zigaflow fits your team.