Proof of client approval: what to keep when a client signs off

What proof of client approval should hold: who decided, when, on which exact version, how and with what note, plus file fingerprints to match the files.

Gareth Thurlow 8 min read

A phone showing a review opened from an email. Tom Becker, the client, pins a comment on the homepage hero, “Logo a touch bigger?”, chooses Approve with changes and says what to change, and the request turns Approved with changes: Leo Ortiz has been told.

Three weeks after launch, the client calls. The brochure went to print with the old phone number, and they want to know who approved it. You know they did. Can you show it?

For most studios, the proof of client approval is an email that says "Looks great, go ahead". This article sets out what a better record holds, how to prove the approved file is the one you delivered, and where to keep it so it's there when someone asks.

Why "looks great, go ahead" isn't much of a record#

An approval email feels like proof until you need it. Then the gaps show:

  • Which file? The thread has three attachments across five messages. The reply could mean any of them.
  • Which version of that file? brochure-final.pdf was sent twice, and the second one had the new phone number.
  • Was it a decision? "Looks great" might be approval. It might be politeness before reading page four.
  • Who had the authority? The marketing assistant said yes. The marketing director hadn't seen it.
  • Where is it? In the account manager's inbox. They left in the spring.

None of this means your client is being difficult. A disagreement about approval is usually a genuine misunderstanding about which file was meant. A good record removes the room for it.

What a good approval record holds#

Whatever tool you use, a record you can rely on answers six questions on its own, without anyone's memory filling the gaps.

  1. Who decided. The named person, not "the client". If several people were asked, the record shows each of them and what each one said.
  2. When. The date and time, with the time zone, so "Tuesday afternoon" means the same thing in London and in New York.
  3. Which exact version. Not a file name, which anyone can reuse, but the specific files in the specific round that was approved.
  4. How they decided. In the app, or from a link in an email. It shows the decision was theirs and how it reached you.
  5. What they decided, and their note. Approved, approved with changes, or changes requested, and the words they wrote.
  6. What came before. Earlier versions, who asked for what, and what changed between them. The final yes makes more sense next to the rounds that led to it.

Two more things make the record stronger. The rule for the request, so it's clear whether one yes was enough or everyone had to agree. And who else was asked and hadn't decided, so nobody later claims their silence was approval.

Prove the file, not just the decision#

Even a perfect record of the decision leaves one question: is the file you delivered the file they approved? File names can't answer that. Someone can save over brochure-v4.pdf with a fix and the name stays the same.

A file fingerprint can. A SHA-256 fingerprint is a 64-character code worked out from every byte of a file. The same file always gives the same fingerprint. Change one pixel, one comma or one byte of metadata, and the fingerprint is completely different. Two different files giving the same one isn't a practical worry.

So if the record lists the fingerprint of each approved file, anyone can check a file against it later. You don't need special software:

  • On a Mac, open Terminal and run shasum -a 256 brochure-v4.pdf.
  • On Windows, open PowerShell and run Get-FileHash brochure-v4.pdf.
  • On Linux, run sha256sum brochure-v4.pdf.

Compare the result with the fingerprint in the record. If they match, it's the file that was approved. If they don't, something changed after sign-off, and you know to look.

Keep it with the job, not in an inbox#

A record that lives in one person's email leaves with them. Keep it with the work instead: on the job, next to the files, the brief and the conversation that led to the decision.

That way the record outlasts the people involved. In Skybase, a decision stands even if the person who made it later leaves the project, and a request's record can still be downloaded after its project is archived.

The sign-off record in Skybase#

In Skybase, approval requests belong to a job, and each approver makes one decision per version: Approve, Approve with changes or Request changes, the last two with a note. Each decision is recorded with who made it, when, and how: in Skybase or from the email link. A New version keeps the earlier ones and their decisions on the record.

When a request is settled, Download sign-off (PDF) on the request builds its sign-off record. Before that, the same button reads Download record (PDF). The PDF holds:

  • the request, its job and project, the rule, the due date and the outcome
  • everyone asked, whether they're on your team or the client's, and when they were added
  • every version: who added it, when, and what changed
  • every file in each version, with its type, size and SHA-256 fingerprint, printed in short groups so it's easy to compare by eye
  • every decision: who, which decision, when, how and their note

Times are shown in the reader's own time zone, with the zone named. Skybase works out each file's fingerprint when it's uploaded, so the record and the file can be checked against each other at any time.

Comments stay out. The decisions and their notes are the record, so a stray remark on a pin doesn't end up in a document you send to a client.

Your team can choose Team copy (PDF) or Client copy (PDF). If you use the optional team check before the client is asked, the team copy includes it, and the client copy says only whether it passed. Clients who sign in to Skybase can download their own copy too, so both sides can hold the same record.

A phone showing a review opened from an email. Tom Becker, the client, pins a comment on the homepage hero, “Logo a touch bigger?”, chooses Approve with changes and says what to change, and the request turns Approved with changes: Leo Ortiz has been told.

What this record is, and what it isn't#

Be clear with yourself and your clients about what a record like this does.

It's a record of decisions: who was asked, what they decided, when, and on which exact files. It's strong evidence of what happened, kept by the system where the decisions were made rather than pieced together from emails.

It isn't an electronic signature, and it doesn't turn an approval into a contract. If your work needs a signed agreement, such as a change to the scope, the fee or the terms, get one through the right route. And this article isn't legal advice. If you need to know how an approval record would stand up in a dispute where you work, ask a lawyer.

For day-to-day client work, though, the question is rarely legal. It's "which version did we agree?", and a good record answers that in a minute.

A worked example: Harbour Studio#

Take a small studio, say Harbour Studio, rebranding a client called Northwind. Harbour is made up: it's the example in Skybase's sample workspace.

"Brand guidelines v3" went through two rounds. On version 1, Tom Becker, Northwind's contact, chose Request changes: "Darker navy for print, please." Leo, a designer, added Deep Harbour (#0B2545) and uploaded version 2, saying what changed. Tom approved it.

A month later, Northwind's printer queries a colour and Tom's manager asks which guidelines were signed off. Leo opens the request and chooses Download sign-off (PDF), then Client copy (PDF). The record shows both versions, Tom's request for changes with his note, Leo's note on what changed, and Tom's approval of version 2, with the time and the zone.

Leo also checks the PDF the printer has. He runs shasum -a 256 brand-guidelines-v3.pdf on the printer's copy and compares it with the fingerprint for version 2 in the record. It matches, so the printer has the approved file, and the question becomes about the press, not the approval.

Nobody searched an inbox, and nobody had to remember anything.

A checklist for every sign-off#

  • The approver is a named person, and the request says whether everyone must approve or any one will do.
  • The decision is on the record with who, when, how and the note.
  • The approved version's files have fingerprints you can check.
  • The files you deliver match those fingerprints.
  • The record lives with the job, not in someone's inbox.
  • Anything that needs a signature, like a change to the scope or the fee, goes through a signed agreement.

If small fixes keep turning into extra rounds, approve with changes explains the middle answer and how it shows on the record. For files going to print, artwork approval software shows how sign-off works for print and packaging. Or see how approvals work from the first ask to the sign-off.

Written by

Gareth Thurlow

Founder, Skybase

Gareth founded Skybase to give agencies and client teams one place for client work, from the brief to the sign-off.