Most approval problems come from three questions nobody answered at kickoff. Who on the client side can say yes, how long each round gets, and what happens when someone wants a change after the yes.
When those stay open, the cut sits in someone’s inbox for a week. Two people approve different versions, and a change after delivery turns into an argument about who agreed to what.
An approval workflow answers them before the first round goes out. It fits on one page and goes to the client with the proposal.
In short
- Name one decision-maker on the client side and keep comment rights separate from approval rights.
- Run an internal review before every client round, so the client never sees what your team should have caught.
- Give every step a date, and pause your internal clock while the cut is with the client.
- Keep formal approval for the milestones and tie it to one version, so a later change is a new version with its own sign-off.
What an approval workflow covers
An approval workflow is the agreed path a cut takes from the edit suite to the final sign-off. It answers five questions:
- Who sees each version, and in what order. Usually your team first, then the client.
- Who comments and who decides. These are different lists.
- How long each step gets. In days, written in the proposal.
- Which status the video is in. Visible to everyone, without asking.
- What happens after the yes. Small fixes, new versions and what gets quoted.
Who approves: build the chain
Every chain has two layers, your team and the client’s. Each layer has people who comment and one person who decides.
| Step | Who | What they decide |
|---|---|---|
| Internal review | Producer, director or lead editor | Is this ready to show the client? |
| Client rounds | Client reviewers and the decision-maker | What changes in the next version |
| Final approval | The client’s decision-maker | This version is the one delivered |
The internal review is the step teams skip when they’re late, and it’s the one that keeps a typo in a lower third from becoming a client note. Someone who didn’t edit the video watches it once before it goes out.
On the client side, name one decision-maker at kickoff. Marketing, legal and the CEO can all comment, but one person settles contradictions and says the final yes. Our post on conflicting feedback covers what to agree when there are several stakeholders.
Keep comment rights separate from approval rights. A reviewer who can approve will sometimes approve by accident, and a forwarded link can put the decision in the hands of someone you’ve never met.
Approve milestones, not every cut
Formal approval belongs to the decisions that cost money to undo. On most client work that’s two points, the locked edit and the finished master.
Rounds in between end with notes or a go-ahead. “Structure approved, move on to the fine cut” is a decision, and it doesn’t need the same weight as the final sign-off. Our guide to picture lock covers how to confirm the locked edit.
Every approval refers to one version. “Approved” with no version number is how v4 gets delivered when the client signed off v3.
Deadlines for every step
Each step gets a date, and the proposal says what happens when it passes. Internal review is usually a day. Client rounds need longer, and the number is yours to negotiate.
Keep two dates on every project. One is the delivery date promised to the client. The other is your internal deadline, which should pause while the cut is with the client, so a slow review doesn’t eat your buffer.
When a client goes quiet, the problem is rarely the deadline itself. Our post on clients taking too long to approve covers how to follow up and what the contract should say.
Statuses everyone can read
Everyone should know where a video is without asking. A short set of statuses covers almost every project:
- In edit
- Internal review
- With the client
- Changes requested
- Approved
- Delivered
Each status has an owner who moves the video out of it. The editor moves it to internal review, the reviewer sends it to the client, and the client’s answer moves it on.
Don’t reuse “Approved” for an intermediate step. If the board says approved after the rough cut, someone will treat it as final.
When something changes after the yes
An approval is attached to the version that was approved. A change after that is a new version, and it goes back through review and gets its own sign-off.
Keep the approved version on record. If the client later says they never agreed to the new music, you can open the version they did approve and compare it with the one that went out. Our post on proof of client approval covers what that record should contain.
Write the policy into the proposal. A typo fix in a lower third is usually included. A change that moves a cut after lock, or a new requirement, gets a quote before anyone opens the timeline.
How this works in RecReview
In RecReview the chain starts on upload. With the Video Production preset, every new version goes straight into internal review.
Who can approve internally, send to the client and request changes is set by role in the workspace settings. By default that’s owners, admins and editors. A request for changes goes back to the editor, and you can reassign it, set a new due date and mark it urgent.
Sending to the client marks the task as waiting on the client. With the ready-made presets, the internal deadline pauses while the client has it, and the date promised to the client never moves on its own.
The client’s Approve and Request changes buttons appear once the version is sent. If your team has already uploaded a newer version, the client can still comment on the one they have, but can’t approve it.
On the client side, contact roles separate the decision from the comments. With them on, only the client’s Managers can approve, and Reviewers comment and request changes. With them off, which is the default, any identified contact can approve, and an anonymous visitor never can.
Approval is the final sign-off. It records who approved which version and when, sends the delivery email with the download link and, with the default automations, moves the task to Delivered. If the client approves while their side still has open comments, RecReview asks first.
When the yes comes by WhatsApp or in a meeting, someone on your team can log it on the version, along with the channel it came through.
A new version uploaded after delivery stays internal until you send it, so the client keeps seeing the version they approved while you work on the change. More on the client portal and what clients see there.
