Client approval form template

What this is about

This is the shortest document in the review chain and the only one that closes something. Where the feedback sheet gathers opinions and gets worked through, the approval form asks a single binary question about a single file: released, or not. Its value shows up in the two situations everyone eventually meets — the campaign that goes live and then gets questioned internally, and the invoice that is disputed because someone recalls having reservations. Both are settled in seconds by a signed line naming the version, and by the sentence stating which uses the approval covers.

A template is the starting point, not the goal: once it has been filled in by hand twice, it is worth asking whether the document should come out of the plan instead.

What runs differently here

Where this differs from the general case:

• The exact version identifier and file name being approved, plus the date and time it was made available for review
• The name and function of the person approving, who must be someone entitled to bind the client, not the day-to-day contact by default
• The scope of the approval written out: which channels, which territories, which period and which language versions it covers
• The explicit exclusions — for example music rights, talent usage terms or legal clearance handled elsewhere — so the signature is not read wider than intended
• A conditional-approval option with a short list of remaining corrections, and the statement that no further review round follows once they are made

Step by step

This order gets you there fastest:

1. Send the version for approval only once the open feedback round is closed and its list has been worked through and returned.
2. Establish before you send who on the client side is entitled to approve, and put that name on the form rather than a distribution list.
3. State the file name and version identifier on the form exactly as delivered, including the date it was made available.
4. Write the scope of use in the form: channels, territories, period and language versions, phrased so someone outside the project understands it.
5. List the exclusions, especially anything whose clearance sits with a third party, so nobody treats the signature as a rights clearance.
6. Offer only three outcomes — approved, approved with the listed corrections, not approved — because anything else reopens the round.
7. File the signed form with the delivered master and the delivery specification, so version, approval and file live together.

Common pitfalls

What most often goes wrong in practice:

• Approval given as a message saying it looks great, which names no version and therefore approves whichever file anyone remembers
• The wrong signatory: the project contact approves, and the person who could actually decide sees the film after it is live
• Approval with a long list of remaining corrections, which is a feedback round wearing a signature
• No scope of use, so a film approved for a trade fair loop turns up as a paid advertisement six months later

With TillyGen

TillyGen keeps every version tied to the plan it came from, so the approval names a state of the project that can still be reconstructed later instead of a file sitting in a download folder.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.