The slowest part of client video work is rarely the editing. It is the three days where a cut sits in somebody's inbox while four people reply to each other about whether the logo is too big.

Approval is a process, and processes can be designed. This one keeps it to a link, a version number and one signature.

One link, one version, one approver

Three commitments, each of which removes a specific failure.

One link means the review lives in one place instead of across email, a messaging app, and somebody's notes from a call. A single URL that always shows the current version.

One version means everybody reviewing is looking at the same cut. The most common source of contradictory feedback is that one person is reviewing an old file that arrived as an attachment three days ago.

One approver means a named person whose yes is final. "The team will review" distributes the decision until nobody owns it, and feedback from four people arrives as four separate priorities that cannot all be satisfied.

Name the approver in the brief, and name a backup for when they are on leave. This costs one line and saves a week.

Timestamped comments beat paragraphs

A message that says "the middle feels slow" is a puzzle. A comment attached to second eleven saying "this pause is too long, and the caption is cut off on the right" is a task.

Any review tool that supports comments tied to a timecode is worth using; a shared video with comments, or even a document with the video embedded and a timecode in each line, works. What matters is that every note has a location.

The second benefit is consolidation. When feedback is anchored to timestamps, it naturally lands in one pass instead of trickling in over days, which is what keeps a revision within a single round.

Version numbering that survives

The scheme matters less than the rule that every delivery has a distinct, increasing number, and that the number appears in the file name and the message:

draft-01, draft-02, draft-03 for review cycles.
final-01 only when it has been approved.

Never send a file called final without a number. The second final arrives within a week, and then there are two finals and no way to tell which is which in a folder. Organising video projects covers the folder side of the same discipline.

Getting sign-off in writing

"Looks good, thanks" in a chat message is not approval, but it is close enough that people treat it as one until something goes wrong.

So ask for a specific form, briefly:

Happy to proceed? If yes, reply "approved for publication" and I will schedule it.

That single sentence converts a vague compliment into a record. It also gives the approver a moment to notice they have not actually checked the captions.

What approval should cover

An approval that only covers "the video" leaves several things unapproved, and those become the objections after publication. Ask for confirmation of four things together:

The cut itself.
The captions, including spelling of names and product terms.
Any on-screen claims, prices or dates.
The thumbnail or cover frame, if there is one.

Product names and prices are the highest-risk item and the cheapest to check. Put them in a list in the approval message rather than relying on the client to spot them in the video.

Handling late feedback

Feedback that arrives after the agreed date is a scheduling problem, and the honest response names the consequence rather than the fault:

I can fold this in, which moves delivery to Thursday. The original date still holds if we go with the current cut.

That is not a penalty. It is the schedule doing its job. Most clients accept the trade-off immediately, because the cost of the delay was invisible until someone said it out loud.

The final check before delivery

Before the file goes out, run the same four checks every time: plays on a phone, captions readable with the interface visible, audio levels consistent between sections, and every claim still matching what was approved.

The first two catch most embarrassments. The last one catches the expensive kind, where a price changed after the video was approved and nobody re-read the caption.

Changes after approval

Approval is a point in time, and requests that arrive after it are new work, not a continuation. The message that keeps this simple is one line: "That is a change to an approved cut, so it would be a new revision — I can do it by Friday."

Note what it does not do. It does not refuse, and it does not argue about whether the change matters. It prices the change in time and lets the client decide. In practice most post-approval requests either get dropped or become a paid variant, and both outcomes are better than silently absorbing them.

If the change is trivial — a typo in a caption — fix it and say you did. The goodwill from that is worth more than the two minutes, and it protects the line for the changes that are not trivial.

Tools, including the free option

Any tool that supports timecoded comments will do, and the free tier of most of them is enough for single-editor work. If the client will not learn a new tool, the fallback is a shared folder with the video plus a document of timestamped notes: both sides write in the same document, every note carries a timecode, and nothing lives in a chat thread.

What must not be the primary channel is a messaging app. Notes scroll away, get answered out of order, and cannot be reviewed as a set.

Multi-stakeholder clients

When four people need to give notes, the approver collects them. Not you.

Say it at kickoff: "I will take notes from you, consolidated, and treat them as the team's position." That single rule prevents the most common client-side failure, which is contradictory notes from people who have not spoken to each other, arriving separately, each presented as final.

If the client insists that everybody gives notes directly, consolidate them yourself and send back the resolved list for confirmation, marking the contradictions explicitly. It costs twenty minutes and saves a round.

When approval never comes

The deadline passes, the approver is silent, and the video sits. The wrong response is to keep waiting quietly and then deliver late.

The right one is a short, dated message with a default: "If I do not hear back by Thursday I will publish the current cut as approved, since it meets the brief." A default in writing converts silence into a decision, and most clients accept the framing because it protects their deadline too.

Do not publish without saying it first. The point is not to force a decision, but to make the consequence of not deciding visible while there is still time to change it.

Delivery itself has its own conventions — file names, formats, and what to keep — covered in delivering video files to clients.

A Client Approval Workflow That Ends the Email Thread