Sourcing DeskKeep Samples and Quotes on One Drawing Version: A Sourcing Brief Revision Table
You control the specification version in a sourcing brief the same way you would control a contract draft: name one version, record every change to it in a single revision table, and require that each sample and each quotation states which version it was made to. Once two suppliers are working to different drawings, their prices and samples are no longer answers to the same question, and no amount of comparison will make them comparable.
Why version drift starts
The brief leaves you as a set of files. A drawing gets forwarded, a dimension gets corrected in a chat message, a screenshot replaces an attachment, and feedback on the first sample is given verbally and never written back into the drawing. Each of those creates a working version that nobody recorded.
The quotation then arrives priced to whichever version that supplier happened to hold: the first package, a later screenshot, or their own reading of it. The price line does not tell you which. This is a documentation problem, not a supplier-behaviour problem, and it is solvable on your side of the table.
The revision table
Keep one table, owned by you, and attach it to every outbound package. It is the reference both sides use to answer the question: which drawing are we actually talking about?
| Version ID | Issued on | What changed from the previous version | Files in this package | Sent to | Supersedes | Status |
|---|---|---|---|---|---|---|
How to fill it in:
- Version ID is short and yours to choose. Pick a naming pattern you can say out loud on a call, and use it everywhere: in file names, on the drawing sheet, in the email subject.
- What changed is written as a difference, not as a full re-description. The point is that anyone can see the delta without diffing two files.
- Files in this package lists every file, so a partial set is visible as a partial set.
- Supersedes names the version this one replaces. Nothing is quietly overwritten.
- Status records whether the version is a draft, issued, or retired. Avoid the word latest as an identifier; it is not a version.
- Issued on uses whatever date format your team already uses consistently.
A blank table is more useful than a worked one here, because your version names, file sets and supplier list are yours. The discipline is in keeping it, not in how it looks.
Rules worth writing into the brief
These are editorial suggestions for your own brief, not requirements imposed on anyone:
- Every file in a package carries the same version ID, in the file name and on the sheet itself.
- Each sample is labelled and photographed against the version ID it was built to.
- Each quotation states the version ID it was priced to and lists the files received.
- Feedback on a sample returns as a new version, not as an edit to the old one. The old version stays on the record.
- When you change one file, check the rest of the set for the same change, and re-issue the full set rather than one loose sheet.
- Retire versions explicitly. Say which version is dead, and to whom.
What to ask each supplier to confirm back
Put these in the brief as a short confirmation block, with space for written answers:
- Which version ID are you quoting to?
- Which files did you receive in that package, and what are those files called?
- Does the sample you are sending match the version you quoted, or an earlier one?
- Are any dimensions or finishes taken from a message or screenshot rather than from the issued files?
- Is there anything in the current version you cannot meet as written?
That last answer is a supplier statement you record; it still needs case-specific confirmation before you rely on it.
When two quotes arrive on different versions
Do not average them, rank them, or split the difference. Either re-issue the current version and ask both suppliers for a fresh quotation against it, or record the version difference in the table as the explicit reason the two are not comparable. Re-quoting costs time; comparing across versions costs you a wrong decision.
What a quality-management reference does and does not tell you
A supplier may mention ISO 9001 as context for how it runs its quality management system. The ISO 9001 official overview is the place to read what that standard covers. That reference is context about quality management. It is not evidence about this drawing, this sample or this quotation, and a brief review or screening outcome is not a certification and does not establish a supplier's capability for your part.
Keep commercial terms in their own column as well. Incoterms and payment terms describe carriage arrangements and how payment is made; they do not prove quality or confirm the specification. Separating them stops a freight or payment line from being mistaken for evidence about the drawing.
This is editorial guidance on how to write your own brief. It is not legal, customs or regulatory advice.
Your next action on this brief
Fill the revision table, name the version attached to every open sample and quotation, and mark an unknown version as unknown. Keep that record with the draft buyer brief. The on-site worksheet does not send it or arrange a review; the supplier and buyer still need to confirm the applicable revision for this case.