How to give video editing feedback someone can act on

Name the exact video version, point to the moment, describe what you observed and ask for one specific change. A useful editing note tells the recipient where to look and how to judge whether the issue is resolved.

“At 00:12 in r03, the caption covers the status label. Move it to a clear area without covering the next instruction” is more actionable than “The captions feel off.”

This guide focuses on the feedback note itself. Use the export naming guide to identify the artifact and the review checklist to decide whether a particular output is ready.

Identify the version before the problem

Start the feedback with the exact filename or the version identifier your review tool provides. If several variants exist, name the shape or other relevant variant too.

A timestamp without a version can be ambiguous. A cut removed from r02 may shift the same event to an earlier position in r03.

State whether your timestamps refer to the exported clip or the long source recording. Do not assume the editor will know which time system you used.

For sensitive projects, use the team's authorized review channel. Avoid attaching private footage, screenshots or account information to a public comment merely to explain the issue.

Write the observation before the solution

An observation describes what the reviewer can see or hear. A proposed solution describes how you think it could be fixed.

Observation: “The quiet reply is difficult to understand immediately after the host's question.”

Possible request: “Review the level change across that transition and preserve the guest's natural delivery.”

That note leaves room to diagnose a low voice, background noise or a poor edit boundary. “Raise all audio” assumes a cause before anyone has checked it.

For this particular problem, link the speaker-volume review guide. For text and picture that disagree with the speech, use aligning speech, captions and cuts.

Give one issue its own note

A paragraph that mixes captions, music, framing and the ending makes it easy for one request to disappear.

Separate the issues and give each a stable label, such as F01 and F02. Keep those labels when you discuss the next revision.

The label identifies the request; it does not prove the issue was fixed. Mark a note resolved only after reviewing the relevant new output.

If several moments share the same symptom, group them carefully and list the affected times. Do not ask for a global change from a single uncertain example.

Compare vague and useful feedback

The following examples are fictional. They describe invented clips and requests, not real customer work or completed tests.

Caption error

Vague: “Fix the subtitles.”

Useful: “F01, r03 at 00:08: the caption says ‘include archived rows,’ but the audible sentence says ‘do not include archived rows.’ Restore the missing negation and check the whole cue against the source.”

Success condition: The current output preserves the spoken meaning in the caption.

Framing problem

Vague: “Make it more mobile.”

Useful: “F02, r03 from 00:11 to 00:14: the status label needed to understand the result is outside the vertical crop. Show the label at a readable size while keeping the relevant control visible.”

Success condition: A viewer can see the action and the state it produces. This does not prescribe a specific effect or claim that a particular editor has it.

Incomplete ending

Vague: “It needs more energy.”

Useful: “F03, r03 at the end: the clip stops after the question and before the answer. Include the complete answer if it fits the intended clip, or choose a different self-contained moment.”

Success condition: The opening promise has an understandable payoff. More motion or louder music would not resolve this observation.

State the reason when it affects a tradeoff

A short reason helps the editor preserve your purpose while choosing a repair.

For example: “Keep the saved status readable because it proves the previous action completed” explains why that small label matters. Without the reason, the editor might preserve the attractive part of the screen and remove the evidence.

Distinguish necessary corrections from preferences. “The caption changes the instruction” is different from “I prefer a shorter opening pause.”

Use clear labels such as “must correct before delivery,” “preference” and “question.” Do not call every cosmetic preference urgent. If you are unsure what happened, ask for diagnosis rather than stating an unverified cause as fact.

Make a request that can be checked

Prefer an observable outcome over an open-ended adjective.

“Keep the complete qualification audible” gives the reviewer something to inspect. “Make it professional” does not define a finish line.

A useful request also preserves constraints. If you want captions moved, say which essential visuals must remain clear. If a cut is shortened, preserve the complete thought and natural speech.

Avoid impossible combinations such as removing all setup while expecting a new viewer to understand an unexplained reference. Ask which goal should take priority when the requirements conflict.

Handle conflicting comments explicitly

Two reviewers may request opposite changes. One asks for a shorter opening; another says the topic is unclear without the first sentence.

Keep both observations visible, name the conflict and ask for one clear decision about the intended audience and purpose. Do not silently apply whichever comment arrived last.

Once a decision is made, record it beside the affected request. This prevents the same disagreement from returning under a new filename.

This is about resolving the note. The broader question of who approves a team's final delivery belongs in the team's actual approval process.

Copy this revision note

• Request ID:
• Exact file or version:
• Timestamp basis: output or source:
• Time or range:
• Observation:
• Why it matters:
• Requested outcome:
• Constraints to preserve:
• Priority: necessary correction, preference or question:
• Response or decision:
• New output version reviewed:
• Status: open, clarified or resolved:

Send a small, organized set of notes after the review pass. If something affects privacy or permission, flag it clearly and hold the affected delivery rather than hiding it among cosmetic edits.

Review the response against the original request

When a new revision arrives, use the request ID to find the issue, then inspect the relevant moment in the named new file.

Check whether the observation is resolved and whether the repair introduced a nearby problem. A caption moved out of one label may now cover the next label.

If the request remains unresolved, update the same note with the new observation. Creating a duplicate request can make the editor think two unrelated tasks exist.

If the editor proposes a different repair, judge it against the stated outcome and constraints. An effective solution need not match your first imagined method.

Common questions

How precise should a timestamp be?

Precise enough to find the event. A short range and a description are often more useful than a very exact number with no context.

Should I include a screenshot?

A screenshot can clarify a visual collision when you are authorized to share it in the chosen channel. It cannot establish the sound or timing of a moving transition by itself.

Is “looks good” useful feedback?

It can be a courteous reaction, but it should not stand in for an exact approval record when a delivery decision matters.

What if I do not know how to fix the issue?

Describe the observation and the desired outcome. A good note can ask for diagnosis without inventing a technical cause.

Should every suggestion create a new export?

No. Clarify the request first. When media changes, identify the new output and review it; a discussion or delivery-note correction may not require a new render.

Keep the next revision focused

Use one file identity, one timestamp basis and one note per issue. Give the editor an outcome they can verify, then resolve each request against the actual new output.

Use the review field guide and first-clip walkthrough for the current product workflow, or explore Raptor Clip Studio.

AI-assisted guide by Raptor Clip Studio Editorial. The feedback examples are fictional.