Versions: An Argument for NEVER Marking a Document ‘Final’

Do you often need to pull old proposals, perhaps for a repeat client or similar project, to reference your past work? It’s not uncommon, and definitely a good idea to look at what you’ve already done before starting a new proposal. (Just remember that copying an old proposal is not a good idea.) When looking for the final versions of old proposals, do you sometimes find that you have multiple files marked ‘final’? Perhaps even a few marked ‘final-FINAL’? How do you know which one really is final? Sure, you could look at the most recent save date on a document, but that’s not always reliable. So let’s talk about why you should never save a document as ‘final’ and what you should do instead.

The Final ‘Final’ File

When I work with a new client, I request copies of recent similar proposals so that I can get a feel for their response style and scour those past proposals for client insights. I often receive files marked ‘final’ that are clearly not the final file; they might include notes to internal reviewers, markers for replacement pages, or be missing sections I know had to have been included in the actual final file.

As an outsider, this worries me. Here’s why:

Imagine you have been working on a proposal for weeks, slaving over it, perfecting it. It’s time for the final review. You export your PDF, naming the document ‘final’ for ‘final review’ before sending it to the team. The next day you pick up final edits and export your final document, saving it as ‘final-final’. As you start printing, someone on the team spots an error, so you make the correction, but print straight from the working file this time and don’t export a new ‘final-final’ PDF. The proposal goes out, you move on to the next one, and all is well.

Except it’s not, because anyone else who needs to access the final file won’t know which one it is. Someone else on the team might pull ‘final’ because they don’t see the rest of the file name in ‘final-final’ or they’ll pull ‘final-final’ but won’t realize that it’s different from the working file because of the last-minute correction. Whoever pulls that document might be using (or distributing) a flawed copy. How embarrassing would it be if the client requested a digital copy, and someone confidently sent the final review document?

Yikes.

Be honest – did you get lost in that muddle of ‘finals’ in the example? Because I did. Let’s save ourselves a few headaches, and potentially embarrassing situations, and stop marking documents ‘final’.

Make the Switch to ‘Versions’ Instead

Despite best-laid plans for pink and red team review drafts, my proposals often go through 6+ reviews. I usually expect iteration 3 or 4 will be the final version, but I never name a file final out of caution. Instead, I save versions. My drafts folder usually ends up looking like:

proposal-name-date_v1.pdf
proposal-name-date_v2.pdf
proposal-name-date_v3.pdf
proposal-name-date_v4.pdf

…and so on. You get the idea, right?

Using versions, I’m able to ensure I am always using the most recent file. It’s also easier to keep the team up to date and looking at the correct version of the proposal. No more principals hopping onto the server or going back through emails and editing an ancient draft! (For the most part – we can’t be responsible for the team not checking their most recent emails, can we?)

Of course, even versions can’t solve the problem of not exporting the ‘final’ PDF file after last-minute corrections to the working file. So be sure to always go back and save the true ‘final-final’ version of your proposal (just save it as a version though, okay?)