A client rings on a Tuesday and says the price you discussed was four lakh, not four and a half. You open the quotation file. It says four and a half. You have no idea whether he is misremembering, whether someone in your team sent an earlier number, or whether you cut a line item out three weeks ago and forgot. The file has one version, because every edit was saved over the last one.
That call is not a pricing problem. It is a version control problem. Quotation revisions are the part of the sales process almost nobody designs, and then everyone argues about.
The sent quote is a fact, not a draft
Once a number leaves your office, it exists in the client’s inbox whether or not it exists in your folder. You cannot unsend it. You can only supersede it.
This is the single rule that fixes most of the mess: a quote that has been sent is never edited again. If the price changes, the scope changes, or the validity lapses, you create a new version. The old one stays exactly as it was, timestamped, with whatever mistakes it contained.
Most teams break this rule for good reasons. The client asked for one small change. Sending a whole new document feels heavy. Editing the existing file feels tidy. So the file gets edited, saved, resent, and now two different PDFs with the same filename are sitting in two different inboxes. Six weeks later, nobody can prove which one was current.
Overwriting also destroys the only evidence you have of your own reasoning. You dropped the installation charge because the client agreed to site access on weekends. Three months on, the site access never happened, you want the charge back, and there is no record that the two were ever linked.
A version scheme for quotation revisions
You need three things attached to every quote: a version number, a date, and a status. Nothing more elaborate than that.
Version numbers should be boring. v1, v2, v3, v4. Not 2.1, not Rev B, not “final”, and certainly never “final_final”. Whole numbers only, incrementing every time a document goes out of the building.
Status should be one of a short fixed set:
- Draft, not yet sent, still editable
- Sent, locked, awaiting response
- Superseded, replaced by a later version
- Accepted, the version the client agreed to
- Expired, validity date passed with no response
- Lost, the enquiry went elsewhere or died
Only one version of a quote can be Accepted. Every version before it is Superseded. That single constraint prevents the most expensive argument in quoting, which is two people in your own team believing different numbers are live.
On a shared drive, this means the file naming carries the version and the folder never contains an edited copy of a sent PDF. On BizvoraOne, versions sit under the same quotation record, so v1 through v4 are one thread rather than four files with similar names.
What counts as a new version
Be strict here, because the grey zone is where the discipline collapses.
A new version is required when any of these change after sending: any rate, any quantity, any line item added or removed, the payment terms, the delivery timeline, the validity date, or the taxes applied. A new version is not required for a typo in the client’s address, a corrected spelling of a contact name, or a formatting fix, provided the numbers are untouched. Even then, reissue rather than edit if the corrected document is going out again.
If you are unsure, make a new version. Version numbers are free. Disputes are not.
The change note is the part that matters
A version number tells you that something changed. It does not tell you what, or why. That second part is what you will need in ninety days when the client asks a question nobody in the room remembers the answer to.
Every revision should carry two short lines:
- What changed, in plain terms. “Removed 40 hours of on-site training. Added AMC for year one. Net effect: reduced by 62,000.”
- Why it changed, naming the trigger. “Client confirmed in-house trainer on 14th. Requested AMC in same call.”
Thirty words. Written at the moment of the change, not reconstructed later. The “why” line is the one people skip and the one that saves you, because it converts a price movement into a decision with a cause attached.
Add a third element if the revision was requested rather than offered: who asked. There is a real difference between a discount you volunteered to close the deal and a reduction the client demanded in writing. When the same client comes back next year expecting the same treatment, you want to know which it was.
A useful test: could a colleague who has never spoken to this client read the change notes for v1 through v4 and explain, in one minute, how you got from the first number to the last one. If not, the notes are too thin.
Validity dates make revisions honest
Most quotes in Indian SMBs carry no expiry, or carry one nobody enforces. That is how a number from March gets waved at you in September.
Put a validity period on every version. Fifteen days, thirty days, whatever suits your input costs. If your material prices move with the market, say so on the document: prices valid for fifteen days, subject to revision on steel and copper.
Validity does two useful things. It gives you a clean, non-confrontational reason to reprice without appearing to renege. And it creates a natural deadline that moves stalled deals, which is worth more than the pricing protection.
When a quote expires, mark it Expired rather than leaving it Sent. A pipeline full of quotes that have been Sent for four months is not a pipeline, it is a graveyard with good lighting.
What to say when the client asks for the old price back
This conversation happens to everyone, and it goes badly when you improvise.
The client has v2 open, which was cheaper. You are on v4, which is not. He wants v2’s number and v4’s scope. Sometimes he genuinely does not realise those are different documents. Sometimes he realises perfectly well.
The answer is not to argue about who remembers what. It is to put the two versions side by side and let the difference speak. Something like this, adjusted to your own voice:
The 4.1 lakh figure was v2, issued on the 8th, valid for fifteen days. That version did not include the second site or the extended warranty, both of which you asked for on the 19th. Those two additions are the difference. Happy to go back to the v2 scope at the v2 price if the second site is genuinely out.
Three things are doing work in that reply. You have named the version and its date, so it is a document rather than a memory. You have attributed the change to the client’s own request, without accusing anyone. And you have offered the old price back, honestly, on the old scope. That last part is important. If you will not stand behind your earlier number at the earlier scope, you were not quoting, you were guessing.
If the price moved because your own costs moved rather than because scope changed, say that plainly too. “The v2 rate was based on our March material price. That has moved. Here is the current one.” Clients accept input cost movement far more readily than they accept vagueness.
All of this gets easier when the line items are stable enough to compare across versions. If v2 and v4 use different words for the same work, the comparison turns into an argument about definitions. That is one more reason to quote from a fixed line-item library with one unit per item, and to make sure the scope on the quote matches what the invoice will eventually say.
Approval on revisions, not just on the first quote
Most firms put an approval threshold on the original quote and then let revisions through unchecked. That is backwards. The first quote is usually at list price. The erosion happens in v3.
Apply your discount bands to the cumulative movement from v1, not to each step. A five per cent cut in v2 and another five in v3 is a ten per cent discount, and it should hit the same approval gate a single ten per cent cut would. Otherwise your team learns, quickly and quietly, to discount in small slices.
One threshold, one named approver, applied to the total gap between v1 and the current version. That is enough.
A definition of done for every revision
Before any new version leaves the building:
- Version number incremented, previous version marked Superseded
- Change note written: what changed, why, and who asked
- Validity date set on the new version
- Cumulative discount from v1 checked against the approval threshold
- The previous PDF still exists, unedited, where you can find it
- The client is told explicitly that this supersedes the earlier quote and which one
That last line matters more than it looks. “Please find revised quotation attached” leaves two live documents in the client’s inbox. “Attached is v3, which replaces the quotation dated the 8th” leaves one.
Start with the deals already open
Do not begin by rebuilding your quotation template. Begin with the quotes currently outstanding.
List every open quote. For each one, find the latest version actually sent, confirm it is the one the client has, and set a status and a validity date against it. You will almost certainly discover two or three where your team’s number and the client’s number are different. Fix those this week, before they become invoicing disputes.
Then apply the rules going forward. Never overwrite a sent quote. Increment the version. Write the two lines. Six weeks of that and the Tuesday phone call stops being a problem, because you will have the answer open on screen before the client finishes the sentence.
