A good review comment does three things in two sentences: names the exact moment (a pinned frame, not "around the middle"), describes the problem rather than prescribing the fix, and says why it matters. The twenty templates below are that anatomy, filled in for the situations that come up in every review round - copy them, adapt the brackets, and watch your revision rounds shrink. If your team is still leaving feedback by email attachment, the switch itself is covered in review link vs email attachment.
Structure and pacing
- Slow open: "The first 15 seconds restate what the title card already says - I start skipping here. Cut to the problem being solved at [0:12]."
- Pacing drag: "This section repeats the point from [1:30] - by [2:05] I want the next beat, not a second example. Could [2:05-2:40] compress to one example?"
- Missing beat: "After the reveal at [0:48] we jump straight to the CTA - I need one breath here for it to land. A two-second hold, not a new scene."
- Ending: "The video ends on logistics - return to the [subject] at [3:20] so the last image is the thing we are selling, then CTA."
Technical notes
- Audio: "Dialogue dips under the music from [1:12] to [1:30] - I lose two lines. Duck the bed ~4 dB under speech in that range."
- Exposure: "The interview at [0:34] is half a stop under against the b-roll around it - it reads as a different scene. Match and it will cut together."
- Focus: "At [2:17] the product softens for ~1s as the camera moves - if the source is sharp, re-check the export; if not, flag and I will approve a reshoot."
- Captions: "Caption at [1:45] reads 'their' for 'they're' - and the term at [2:30] should be [correct term], it teaches the wrong word otherwise."
Content accuracy
- Stale claim: "The pricing mentioned at [0:52] changed this month - current number is [X]. Pinning the exact moment so the fix is checkable."
- Unsupported claim: "'Fastest in the market' at [1:10] - we cannot substantiate that. Reframe to '[defensible claim]' or I need a source before this ships."
- Name/branding: "Product name at [0:15] is the old spelling - [correct]. Same check needed at [2:48]."
Brand, legal, and compliance
- Music rights: "Track at [0:20] is not cleared for paid social - need the license doc or a library replacement before this leaves review."
- Legal flag: "The comparison at [1:55] names a competitor - legal needs to see this frame specifically before approval. Tagging must-fix."
- Accessibility: "No captions anywhere in the cut - must-have for [platform/audience]. The captions workflow exists in the tool; this is a ship-blocker, not a preference."
Approvals and endings
- Approved: "Approved as v4 - shipping from this version. (Explicit, in the tool, so the record exists.)"
- Conditional: "Approve on fix of [must-tag #1] only. Everything else is could-tag and I will not re-review for it."
- Round closer: "All musts resolved in v3 - confirming approved. Notes beyond this point go to the next project, not this version."
Disagreements and priorities
Resolving a split decision: "We are split on the ending - resolved as: keep current cut. [Name] made the final call at [date]." A disagreement settled in the thread is a decision with a record; a disagreement settled in a hallway is next week's argument. Tagging priority: "Must: the [legal flag]. Should: the audio dip. Could: the transition style." Must/should/could tags let the editor spend the round where it pays - the etiquette behind these tags is in video feedback etiquette for clients.
The anatomy, one more time
Every template above compresses to one sentence shape: at [moment], [observable problem], because [consequence]. No mood adjectives ("make it pop"), no person-blame ("Sarah's section"), no fix-prescription when you can state the problem - the editor often has a cheaper fix than yours. And one comment per issue: five issues in one comment produce five half-fixes. The full round discipline these templates live inside is in video review best practices, and the editor-side handling of whatever arrives anyway is in how to receive client feedback.
FAQ
Should comments prescribe the fix?
Prefer not to. State the problem and the consequence; the editor owns the fix and often has a cheaper path to the same result. Prescribe only when you hold knowledge the editor lacks - the corrected stat, the cleared track, the legal constraint.
How long should a review comment be?
Two sentences is the sweet spot: the problem, the why. If a note needs a paragraph, it is usually two notes - split them - or a conversation, which belongs in a thread reply, not a single comment.
What about positive feedback?
Pin it too: "This transition at [1:22] is exactly the energy" tells the editor what register the rest should match, and it survives for the next project's editor in a way a meeting compliment never does.
Do these work for clients who are not video-savvy?
They are built for exactly that reviewer - every template names an observable thing at a pinned moment, no editing vocabulary required. The client-side habits that make this natural are in the etiquette guide, and the round-count math they enable is in how many revision rounds.