How to Name and Version a Document a Client Will Receive

The name of the thing you send is the only part of your work that gets read by everyone, including the people who never open it. It appears in the message, in the browser tab, in their downloads folder, and in the search they run four months later trying to find you. It is worth more than the fifteen seconds it usually gets.

Name it for their filing system, not yours

Your naming convention is optimised for a folder where every file is yours. Theirs is a folder where every file is from a different supplier. Those are opposite problems, and yours is the one that has to give.

A name that works in both places contains four things:

1. Who it is from. Your company. They have twelve of these.

2. What it is. Proposal, quote, scope, report — the noun they will search for.

3. What it is about. The project, in their words. Not your internal codename.

4. When. A date in ISO form — 2026-09-14 — because it sorts correctly in every file browser on earth and is unambiguous across countries.

Which gives you something like:

Northgate — Website Rebuild Proposal — 2026-09-14

Long, and deliberately so. The failure of a document name is never that it was too descriptive.

Four things to keep out of the name

• Your internal version number. “v3” tells a client there were two before this one and invites the question of what changed. Your revision history is your business.

• Anything ending in FINAL. It is never final, it will be followed by FINAL2, and both will be in their folder at the same time.

• Your internal codename. “Project Kingfisher” is meaningless to them and slightly alienating — it is a reminder that they are an entry in your system.

• The word “draft”, unless it is one. And if it is one, say so in the document too, because the name gets lost the moment it is forwarded as a link.

Versioning changes completely when you send a link

With attachments, versioning is a distribution problem: three people have three files and one of them is stale. With a link there is one document at one address, and what a reader opens is whatever is there at the moment they open it. Nothing is pinned to the moment you sent it, and a reader who already has it open keeps the copy they were given until they reload — so an edit reaches the next visit, not the current one.

That solves the fragmentation and creates a subtler problem in its place.

• The good half. You spot a typo, a wrong date or a broken figure an hour after sending, fix it, and every subsequent reader sees the corrected version. No apology email, no “please disregard the previous attachment”, no second file competing with the first.

• The dangerous half. Change something material and the person who read it last week and the person who reads it tomorrow have read two different documents — and nothing tells either of them so. When they compare notes in a meeting, they disagree about your proposal and neither knows why.

The discipline that fixes it

Three rules, and they cost almost nothing.

1. Put a version line in the document itself. A single line near the top — “Version 2 · 14 September 2026” — is the whole fix. Two readers who saw different documents can now discover that fact in one sentence instead of in an argument.

2. Draw the line at material change. Typos, formatting, a clearer sentence: change silently, no version bump. Price, scope, dates, terms, anything somebody could act on: bump the version and tell people.

3. Check whether anybody has read it before you change it. This is the move a tracked link makes available and a file on a disk never can. If nothing has been opened, edit freely — nobody has a stale copy because nobody has a copy. If it has been read, the edit needs a message with it.

That third rule is why “has it been opened yet” is a genuinely operational question rather than a curiosity — how you can know at all compares every method of answering it.

When to send a new link instead of editing the old one

Editing in place is right for corrections and wrong for renegotiations. Send a new document, at a new link, when any of these is true:

• The commercial terms changed — price, scope, schedule, payment.

• The old version has been read by people you cannot reach to tell.

• You will need to point at what you sent and when — a dispute, an audit, a formal process.

• Someone asked for a revised version. They are expecting an artefact; give them one.

And when you do, keep the old link alive for a while rather than killing it immediately. Somebody has it in a calendar invitation. A dead link at that moment costs you more than a slightly out-of-date one, and you can see whether it is still being used before you close it.

Where the title actually surfaces when you send a link

A link changes which of the places a name appears, and it is worth knowing exactly which, because the instinct from attachments is wrong in both directions.

• Not in the URL, and not in a preview. A Quixli share link is an opaque token, and the shared view is kept out of search engines on purpose. Your document’s title is not exposed to anything that has not been through the link — which matters, because “Northgate — Redundancy Programme Scope” is a sentence you would not want appearing in a chat channel unprompted.

• At the top of the document, and in the reader’s tab. Where it does the ordinary work of telling somebody what they are looking at.

• In the file name of any copy they take. A reader can export the document as a PDF, and the file they get is named after the document’s title. Whatever you called it is now the thing sitting in their downloads folder and, later, in their document system — which is the whole reason the naming rule above is about their filing system rather than yours.

Because there is no preview card doing the introducing, the sentence you write around the link is carrying that load instead — does a proposal need a cover page works through what that first impression should carry.

Naming discipline matters most when several people at one client have their own copy — how to send a proposal to several people at the same company is that case. And what a Quixli link records about each version’s readers is what makes rule three above possible.