A Download Filename Policy for Repeat Quote Revisions

When a customer downloads a quote three times, the files often become 'quote.pdf', 'quote (1).pdf' and 'quote (2).pdf'. Nobody can tell which is current, and a name embedded in the filename may be seen by anyone who shares the device or the folder. This article proposes a filename policy as a conditional design workflow, not a description of existing behaviour.

Goals

A filename should answer three questions without opening the file: which quote, which revision, and roughly when. It should not reveal a customer name, a company or an address.

The proposed pattern

Quote-[reference]-r[revision]-[date].pdf

Or, in a readable form: the word 'quote', the quote reference, the letter r with a zero padded revision number, and a date in year month day order. Use only lowercase letters, digits and hyphens, so the name survives different systems.

The reference should itself be a code that does not encode personal data. If your reference includes a name, the policy fails before it starts, so check that first.

Revision filename examples

All examples are fictional.

quote-q4f7k29b-r01-20261102.pdf for the first issue. quote-q4f7k29b-r02-20261104.pdf for the second revision. quote-q4f7k29b-r03-20261104.pdf for a third revision on the same day.

The revision number, not the date, is the ordering signal. Dates can repeat; revision numbers should not.

Branching choices

Branch A: same file re-downloaded. If the customer downloads revision 2 twice without any change, keep the same filename. Browsers may add their own suffix, and the policy cannot control that, so note it rather than promise otherwise. Branch B: a draft or unsent state. Add 'draft' before the revision, for instance r02-draft, only if drafts can be downloaded at all. Branch C: a superseded revision. Keep its original name. Do not rename old files to mark them superseded, because the customer's copy is already on their device.

Collision checks

A collision means two different files could get the same name. Run these checks on paper before any build.

Check 1: can two revisions of one quote share a revision number? If yes, the numbering is wrong. Check 2: can two quotes share a reference? If yes, the references are wrong. Check 3: if revision numbers pass 99, does r100 sort after r99 in a file list? If not, widen the padding. Check 4: do two customers see the same name for different content? Only possible if references repeat across accounts, so confirm they do not. Check 5: is any character outside lowercase letters, digits and hyphens possible? Reject or replace it.

Hypothetical worked example

A fictional customer requests a quote, gets revision 1, asks to change a quantity, receives revision 2, then reverts and receives revision 3 with the original quantity. The files are r01, r02 and r03. Revision 3 matches revision 1 in content, but it gets its own number, since it is a new issue. The customer can sort the folder and the highest r number is the latest.

Stop conditions

Stop and revisit the policy if a filename would contain anything that identifies the customer, if two files could receive the same name, or if the revision number is derived from the date instead of being counted. Also stop if staff would have to rename files by hand to make the scheme work.

Acceptance checks

1. Ten sample downloads across three quotes produce no repeated names, and the check is recorded.
2. No sample name contains a personal name, company or address.
3. Sorting the sample names alphabetically puts revisions in numeric order.
4. The names open and display correctly on at least two different systems you can access.
5. Support staff can read a filename aloud and identify the quote and revision.

Finally, document the pattern in a single sentence that support and developers share. A policy that fits in one sentence is more likely to be followed consistently.

Sources