An approval is only worth something if you can point at it later. "They said yes on the call" is not a record; neither is a thumbs-up in a chat thread that has scrolled away. A usable approval names a person, a version, and a moment.
This article covers how approval works in VoiceDeck and gives you a short process to run on the next job.
What an approval is here
On the review surface, each file carries an Approve button. The reviewer presses it when they are happy with what they are looking at.
Three things are true about that action, and they are what make it a record rather than a gesture:
It is per person. Two reviewers on the same cut approve separately. The marketing manager's yes is not the brand lead's yes, and you can see which of them has responded.
It is per version. The approval is bound to the exact version on screen. Approving V1 says nothing about V2.
It is reversible while the round is live. The button is a toggle — a reviewer who approves and then spots something can press it again to withdraw. What you want is the state at the end of the round, not a race to the first click.
Approvals never carry forward
This is the rule that surprises people, and it is deliberate. When you upload a new version of a file, the approvals on the previous version stay attached to that previous version. They do not follow the file forward.
That means a changed cut always needs a fresh sign-off. It also means nobody can be told they approved something they never watched — the approval on the record is against the cut they actually saw. If a change is genuinely trivial, that is a conversation to have with the client, not a reason to inherit an old approval.
The same applies to a link you re-share. Revoking or re-issuing a link changes access only; it never touches the approvals already recorded.
Internal notes and client notes
Your team's comments are Internal by default and are not shown on a client link. A client's comments are visible to you and to them.
You can make an internal comment public when it should be part of the client conversation, and make a public one internal if it was posted in the wrong register. Keep the two apart deliberately: the approval record reads much better when the client-facing thread contains only what was actually said to the client.
Where the record lives
Each share builds a round on the project's Reviews tab. A round card shows who was asked, the date, how many comments came back, and the outcome — open, approved, or superseded by a later version. Opening the card gives you the read-only detail: the notes and the decisions as they stood.
The Activity tab holds the project's timeline, and each share link's row shows its settings, its view count, and whether it has been responded to. Between them you can answer "who approved which cut, and when" months after the job closed.
The template
Run this on the next job. It takes about five minutes of setup.
- Name the approver before you share. One person per deliverable who is allowed to say yes. Everyone else gives notes.
- Send one link per reviewer. Their comments and approvals then sit under their own name from the first click, instead of being untangled later.
- State what approval means in your message. "Approving locks picture; audio mix comes after" prevents the yes that was actually a maybe.
- Set an expiry if the round has a deadline. A link that closes on Friday is a quieter reminder than a chasing email.
- Do not treat silence as approval. If the button has not been pressed, the round is open. Ask.
- Re-share after every change. New version, new link message, new sign-off.
- Deliver from the same link. Once the approvals are in, deliver, and the client downloads the approved originals at the address they already know.
- Leave the project intact. Do not tidy away old versions or resolved comments. The record is the deliverable that outlives the job.