1. What this lesson is for

Editing skill gets you hired; a calm revision process gets you rehired. In this lesson you set up a revision cycle with clear control points, deadlines and one person accountable for approval, so feedback turns into changes instead of chaos.

The module principle applies directly: predictable process builds client trust faster than flashy edits. A client who always knows what version they are looking at, what happens next and when, will forgive a lot.

2. The review cycle

Every project follows the same path. Your job is to make each arrow a deliberate step with a date, not an open-ended conversation.

3. Version naming and approval stages

Clients lose track of versions faster than you think. Put the version and stage in the file name and burn a small version label into the review export, so a screenshot alone tells you which cut they watched.

VERSION NAMING
<CLIENT>_<PROJECT>_v<N>_<STAGE>_<YYYYMMDD>.mp4

ACME_launch-teaser_v1_REVIEW_20260928.mp4    first cut, watermark "v1 REVIEW"
ACME_launch-teaser_v2_REVIEW_20261001.mp4    after round 1 feedback
ACME_launch-teaser_v3_APPROVED_20261003.mp4  signed off, no watermark
ACME_launch-teaser_v3_MASTER_20261003.mp4    delivered master

Rules: never reuse a number, never rename an old file, never send "final".

4. Feedback forms and timestamped comments

"Make it pop" is not feedback. Ask for comments tied to a timestamp, and give the client a form that nudges them towards specific, actionable notes.

FEEDBACK FORM - ACME_launch-teaser_v1_REVIEW
Reviewer name:            ______________
Are you the approver?     [ ] yes  [ ] no (approver: ________)
Watched on:               [ ] phone  [ ] laptop  [ ] TV

1. Does the video deliver the key message from the brief?  [ ] yes [ ] partly [ ] no
2. Timestamped notes (one note per line):
   MM:SS  - what you see/hear  - what you want instead
   00:04  - logo too small      - logo at least 1/3 of width
   00:12  - "fast setup" line   - say "setup in 5 minutes"
3. Anything that MUST change before approval?  ______________
4. Anything that is only a preference?         ______________

Deadline for notes: Tue 30 Sep, 17:00. Notes after the deadline move to the next round.

Then consolidate everything into one intake table - your single source of truth. Notes from email, chat and calls all end up here, or they do not exist.

5. Limiting revision rounds clearly

Put the number of included rounds in the quote, and define what a round is: one consolidated list of notes, from the approver, before the deadline. Anything that changes the brief is a scope change, not a revision, and is quoted separately.

REVISION LOG - ACME_launch-teaser
Included rounds: 2   Used: 2   Remaining: 0
Approver: J. Nowak

ROUND  DATE        FROM VER  TO VER  NOTES  DONE  DEFERRED  SCOPE CHANGES
1      2026-09-30  v1        v2      9      8     1 (music) -
2      2026-10-02  v2        v3      4      4     0         pricing screen (quoted, approved)

APPROVAL: "v3 approved for publication" - J. Nowak, email, 2026-10-03 10:42

6. Final delivery package and archive

After approval you deliver a predictable package. Agree the list in advance so the client knows what they get and for how long you keep the source files.

DELIVERY NOTE
Project: ACME launch teaser      Approved version: v3 (2026-10-03)
Files:   master 16:9, 9:16, 1:1, EN.srt, PL.srt, thumbnail, revision log
Link:    shared folder (available until 2026-11-03)
Archive: project and source media kept until 2027-10-03, then deleted
Further changes after delivery are quoted as a new job.

7. Checklist and debrief

• Scope confirmed and revision limit written in the quote.
• Approval owner and approval milestones defined before v1.
• Single source of truth for notes - no notes live only in chat or memory.
• Revision limits enforced; scope changes quoted and approved separately.
• Every approval captured in writing; archive policy applied after delivery.

Debrief prompts after every project:

• Which requests were ambiguous, and what question would have clarified them earlier?
• Where did scope creep appear, and did you catch it before or after doing the work?
• What will you add to the brief template so the same issue does not repeat?

8. Exercise

1. Pick a finished video and export it as v1_REVIEW with a visible version label.
2. Send it to a friend acting as the client, together with the feedback form above.
3. Consolidate their notes into the intake table, mark one note as a scope change, and send the table back for confirmation.
4. Produce v2, update the revision log and get written approval.
5. Assemble the delivery package with the handoff table and a delivery note.
6. Debrief: write three sentences answering the debrief prompts.

Further reading

• CapCut Help Center
• Frame.io - an example of timestamped video review
• Wikipedia - Scope creep
• Wikipedia - Version control